On 04/18/2013 08:34 PM, Jon Dowland wrote: > Hi, > > I saw this bug and I got a bit concerned.
We used to use python ObjConfig, but it's not compatible with Openstack .ini files... > I'm a likely user of the > openstack packages in Debian — well I/we could be, if they fit our > needs — but I'm really worried that they are going to be vastly > over-engineered. In a way it reminds me of the exim4 packages: the > situation is not entirely analogous, since exim4 is installed for > all Debian users, and the debconf harness does a good job of > simplifying the complex job of configuring exim4 for the complete > novice. But as soon as you want to actually deploy a real mailserver, > the debconf stuff gets in the way, so much so that everyone I know > who runs exim4 as a mailserver on Debian quickly overrides the > debconf stuff altogether. I don't think what I did is over-engineered. If you wish to do big deployments, you would use something like puppet anyway, and use DEBIAN_FRONTEND=noninteractive. That's not a problem at all. The company who paid for my Debian work on Openstack uses that, and they are pretty happy with it. > I don't want to see the same situation in Debian. Let's not fall > into the trap of thinking that the openstack packages need to be > simplified for the complete novice. They do, if it doesn't go on the way of advanced users, which I think is the case. > The complete novice will not > be deploying a cloud infrastructure. Probably not, though everyone is a novice at some point, and some helpers are here to make it easy to discover the packages. Also, it is possible to use preseeding, which is a nice way to automate things. Last, this way it is also possible to guess some values (like "my_ip" for example with nova) so that you don't have to care about it at all. > There's no point in writing > large, complex postinst scripts, debconf configuration etc. to try > and avoid the sysadmin from editing a text file, if they are > inevitably going to have to edit the text file anyway. They wont. On a large cloud, either you use preseeding, or you use puppet. I can't see anyone editing configuration files by hand for hundreds of nodes. > History has > shown that you just introduce an order of magnitude of complexity, > a load of expertise needed to properly drive openstack in Debian > which will not be transferrable or useful to any other context, and > things which will get in the way for people who are used to > openstack elsewhere and are caught out by Debian-specific hand > holding. And so either people will have to work around your harness, > or use 3rd party openstack packages, or (worse) avoid Debian as a > serious platform for this stuff altogether. Quite not. One of the very good point of having preseeding and automation is that I can do tests setups very fast, and check that everyone is working as expected. I don't think it will increase the chances of having problems, if I run functional tests like the tempest suite (which is on my todo atm). > I really think Julien is right re the debconf sequencing stuff you > seem to be worried about. As a user, if I'm installing openstack by > hand, then I have no problem if the debconf questions come in two > lumps. Well, that part is fixed. So yeah, I don't have to worry at all about it anymore! :) > It's quite likely some of your dependencies will force this > situation anyway, outside of your control. If I've mastered deployment > and I'm rolling out more openstack nodes, I will definitely be using > debconf preseeding or post-facto fixups via puppet, there's no way > I'd do any more than the first one (as a learning experience) by > hand and surely anyone else who is looking at deploying a cloud > infrastructure would do the same? Yes, that is what I expect. And this is also the point (eg: using preseeding, so that you have proven-to-be-working scripts). Also, if we don't have anything to configure the db access, then it means that you would have to do all sorts of things by hand (like nova-manage db sync and the like). This is also very nice to be able to avoid that. I don't see any other way to be able to do that. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
