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

Jon Dowland jmtd at debian.org
Thu Apr 18 12:34:08 UTC 2013


I saw this bug and I got a bit concerned. 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 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. The complete novice will not
be deploying a cloud infrastructure. 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. 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.

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. 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?

More information about the Openstack-devel mailing list