[Openstack-devel] Bug#700620: Bug#700620: Rewriting the .ini parsing bit of openstack-pkg-tools

[Thomas Goirand]

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