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

2013-04-18 Thread Jon Dowland
Hi,

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?


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



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

2013-03-19 Thread Julien Danjou
On Tue, Mar 19 2013, Thomas Goirand wrote:

 Who's problem then?

I don't know -- I'm not sure it's a even problem. Maybe dpkg's problem?

 I thought like you first. Then I realized that we have no choice but to
 implement something anyway, because the upstream library doesn't have a
 feature to actually write the configuration, it only can read it.

That's a good point indeed. Still, I think it'd be better to contribute
to oslo.config and add write support, which could even be useful to
others, than hack something in Debian's corner.

 Well, if we're writing some debconf stuff, it is so it can be used. I
 don't believe it is reasonable to say bha... people are going to
 preseed anyway, so why should we care. I do care!

 Also, I believe that my final solution, based on regular expression, is
 easy to change if there was any trouble with the parsing. The fact that
 I use a unique logic to both read and write values also helps
 maintainability.

As I said, I think you're wrong, but the decision is up to you anyway.
:-)

-- 
Julien Danjou
// Free Software hacker / freelance consultant
// http://julien.danjou.info


pgpCwMFI2IsjY.pgp
Description: PGP signature