[OpenStack-docs] Debian installation guide for Juno

Thomas Goirand zigo at debian.org
Wed Nov 26 23:41:49 UTC 2014


I'm sorry that I missed the thread. Thanks to Andreas for poking me.

On 11/12/2014 10:23 AM, Matt Kassawara wrote:
> I'm seeing some bugs pop up for the Debian variant of the Juno
> installation guide that merely add to the list of existing open bugs
> from prior releases.

I may have missed them. I'm also doing the packaging in Debian alone
(for the moment), which keeps me really busy, so it's expected that I
don't *see* all.

Could you point to them so I have a look? If you see some, please make
sure to add me in the loop, and I'll do my best do work on them.

> Considering the bugs and installation testing
> status page [1], I don't see any attempts to test and/or maintain this
> variant.

Well, first I wasn't aware of that page. But I can already mark some of
the items as ok. For example, I can assert that these are ok:
- identity
- image service
- dashboard
- compute

I'd have to run through the instruction for compute and network, to make
sure that it just work. I've already simplified the Neutron default
setup to make it closer to the install-guide, so that there's less
things to edit. I did also the same for the compute part.

There's sill issues to tackle for the Neutron part, I know that.

However, the fact that nobody worked on marking the items as checked is
a very bad metric to tell if the Debian install-guide should go away.

> The Debian packages use debconf, a configuration system that
> requires un-translatable screen shots to configure services.

The debconf system is fully translatable, and that's the whole point of
it. I do have a lot of translations in many packages already. For
example, just for nova, I have:
- cs.po
- da.po
- de.po
- es.po
- fr.po
- gl.po
- it.po
- ja.po
- nl.po
- pl.po
- pt_BR.po
- pt.po
- ru.po
- sk.po
- sv.po
- zh_CN.po

That's 16 translations!!!

> However,
> some items still require manually editing configuration files. Also,
> Debian receives minimal readership compared to other distributions
> which reduces the return on investment to maintain a system different
> from any other distribution.

Since I've done all the work for Debian in the install-guide (including
screenshots, and all), it's only up to me to evaluate if it's a good
return on the time I'm spending. And I would like to continue doing that
work. For those who did the review, I think they were ok doing them, or
at least, they didn't complain too much about it (thanks Andreas, Tom
and others).

> I brought this issue up several weeks
> ago and thought we wanted to pursue disabling debconf to make Debian
> mostly follow Ubuntu and therefore easier to maintain.

No, I don't want to do this. I'm also very bothered by the fact this
topic comes back often, as if it was a huge issue that Debian and Ubuntu
things were different. It's not, and it only reflects reality.

What if I proposed to remove the SUSE doc on that ground? How would
Andreas feel? Probably (and rightly) very bad... Well, I feel very bad
with your proposal as well.

That there is less people involved in OpenStack upstream using Debian is
a fact I can agree with, but we do have some users, and they are very
happy to read the Debian version of the official doc (I had some
feedback on it). I am happy to provide them a good doc, and that it is
in the official site.

BTW, we aren't doing a kind of competition, are we? It's a normal thing
to give enough room for Debian in the install-guide. That's part of the
"big tent" model which was discussed at large, and I don't think it is
correct to just try to erase all of the work that was done in the docs,
just because you want to make it uniform with Ubuntu. Debian and Ubuntu
are different. Let me give you some hints here.

See this:

http://docs.openstack.org/juno/install-guide/install/apt-debian/content/glance-install.html

Then see this:
http://docs.openstack.org/juno/install-guide/install/apt/content/glance-install.html

Then tell me which of the 2 is the most easy, and which one newbies will
want to read.

Clearly, just doing "apt-get install glance", responding to a few
prompts, and that's it, is a lot more easy than all of the 10 shell
commands and the 7 config file editions that you have to do manually in
Ubuntu. It is normal that I would like to see the Debconf mode
documented, as it is also something I am proudly providing to Debian
users, which I think is an advantage over Ubuntu. I do not want the docs
to hide this.

Then another thing. In the doc for Ubuntu, there is:

"You need to install the required packages. For now, sahara doesn't have
packages for Ubuntu. Documentation will be updated once the packages are
available. The rest of this document assumes that you have the sahara
service packages installed on the system."

But in Debian, I did the work, and there are packages for Sahara. How
would you then write this? Display both cases for Ubuntu and Debian in
the same doc? This doesn't feel the right thing to do.

Another example. In Ubuntu, we see this:
http://docs.openstack.org/juno/install-guide/install/apt/content/ch_nova.html

See the section about VNC setup. Well, in Debian, the default is SPICE,
because I think it's so much nicer, and also, there's a unique
"nova-consoleproxy" package instead of 3 for Ubuntu, which holds all of
the nova console stuff.

All together, if we were going *backward* (yes, that's a step backward
that you are proposing, since it was merged before with lots of "Note:"
stuff, which then lead to a specific guide for Debian) we would end up
with lots of "NOTES:" specific about Debian, polluting the Ubuntu doc.
This is what pushed the doc team to make a clear cut, and have
a separate Debian guide.

So going back to the mess we had before, I don't agree...

> Any alternative
> installation processes using debconf and/or automation would reside
> outside of the official installation guide.

I don't see why. Debconf is completely part of Debian and the Debian
packages for OpenStack I wrote. Pushing it out is, for me, not an
option, and I don't see any valid reason to do so.

> Did we reach an agreement?

Clearly, no. I spent a large amount of time to do the work, reviewers
too, and I don't want it to go away, back to what it was 2 years ago.

On 11/18/2014 11:25 PM, Jeremy Stanley wrote:
> On 2014-11-18 13:42:37 +0000 (+0000), Phil Hopkins wrote:
>> I agree that we should not use debconf to make this install guide
>> similar to the Ubuntu guide.
>
> I worry the problem you're going to encounter there is that Debian's
> packages _do_ use debconf to prompt the sysadmin for configuration
> choices, database setup, et cetera. I suppose the install guide
> could override it to non-interactive and then show how to go back
> and perform all the same configuration and setup tasks, but that
> seems like it's counter to how Debian consumers are expected to make
> use of those packages.

There's that, and also the fact that, even with the non-interactive mode
activated, there's sill a lot of differences that you will find when
using Debian.

On 11/26/2014 04:51 PM, Jason Bishop wrote:
> Hi Andreas, I wonder if it is feasible to rely more on pre-seed files
> in the docs.  If the docs described the pre-seed config options then
> the maybe the rest would more closely resemble the ubuntu docs.
> Speaking personally, i'm a debian openstack user but i have edited
> files rather than debconf so far.

I wanted to write more about preseeding, but I've been told that this
was out of the scope of the install guide, so I gave up.

I'd like to have a bit more freedom for the Debian specific part, and
talk about the "openstack-deploy" package, which contains a preseed
library. If this doesn't fit the install-guide, I can understand, though
I haven't been told were to put that part in docs.openstack.org. And no,
this is *not* about a "magic install button", but about documenting the
existing packages available and providing a way for users to write
automation themselves, using the available interface. But anyway, let's
not restart that discussion *now*. :)

Cheers,

Thomas Goirand (zigo)




More information about the OpenStack-docs mailing list