Open Stack

Hi Matt,

I have the feeling I'm repeating myself and that the discussion is
stuck. But since you're repeating the same points of argumentation, then
probably I need to say things again, in a better way so that you
understand my view. I hope this one mail will be more clear.

On 12/02/2014 12:50 AM, Matt Kassawara wrote:
> In reality, no one should deploy OpenStack manually in a production
> environment.

I believe your vision here, is blurred because you're too much of an
insider. This seems to be a common view within the OpenStack upstream
community.

But I don't share this view. Simply I saw, in a lot of cases, some
Debian users doing manual deployment for production. I also helped on
IRC many times.

It is not truth that a typical OpenStack users will do a lot of
deployment. Many times, I saw operators doing one, maybe 2 deployment,
and that's it. And they don't go through 1/ doing a manual deployment to
see if/how they can do it, and 2/ switch to some chef/puppet automation.
In reality, some administrators will just need "a cloud", heard about
OpenStack, and do a single deployment in a data center.

This happens a lot, you just don't hear about these users. And for these
users, it's my duty, as a package maintainer, to make it possible, and
as easy as possible, to do manual deployment. I believe that what I did
in the Debian packages helps a lot to achieve it. But without the
install-guide, I think it's impossible for a newbie to ever deploy
OpenStack successfully.

> For example, creating the SQL
> database, populating keystone, and configuring keystone access applies
> to almost every service and occurs prior to other configuration steps.

But even if you know how to do it, the above tasks are error prone. Even
with the automation, one must know what he does. Though at least, simple
mistakes with the service endpoint URL or the MySQL access rights wont
happen.

> After installing OpenStack using one of the minimal example
> architectures, people can reference other documentation to improve
> redundancy and performance of their environment. Only after people build
> a stable, scalable, repeatable environment should they look at automation.

It depends. If the automation hides what one does when the knowledge is
needed, yes, I agree. But if it is only a helper which doesn't hide what
its doing, or if the user actually *never* need to know what is
happening behind, I think it's fine to use automation directly. IMO,
neither the Debian doc or the Debian packages are hiding anything
anyway. If you have this feeling, please open a bug and assign me to it,
and I'll do my best to fix it.

> Currently, all distributions in the installation guide except Debian
> follow this mantra.

It is my view that there is no such difference as you pretend. Even in
Debian, you have to understand which wire goes where. The only thing is,
you wont have to *ever* know how to do "glance-manage db_sync", or even
"neutron-db-manage --config-file /etc/neutron/neutron.conf upgrade head"
if the user decides to use the automation. And frankly, I don't see why
you wouldn't choose to make your life more difficult.

The same way, I don't think a normal human can remember all the endpoint
URLs. It's important to know what an endpoint is, but once you know,
it's better to have the package to remember that the URL is
http://<ip>:35357/v2.0 for keystone or http://<ip>:8004/v1/%(tenant_id)s
for heat.

It's also faster to just dpkg-reconfigure heat-api than it would be to
manually type the keystone CLI commands. I did this many times.

Last, it's also so much better to have the package remember that the
service type for Sahara is "data_processing", so that Horizon can find
it, and you cannot do a mistake.

All that, in Debian, you *never* have to remember it. Never. Ever...
It's nice if you know, or have somewhere in the doc to read what the
endpoint should look like (in the appendix for example), but that's it.

So yes, of course, Debian doesn't follow this "mantra" as you wrote,
because Debian users don't ever have to remember all of the OpenStack
inconsistency which I wrote above. It is a good thing. And it is also a
good thing that Debian users who are OpenStack newbies can focus only on
things which maters: understand what RabbitMQ is for, or what API
endpoint are for, rather than actually bother with having the URL for
them rightly entered in the command line.

> Consistency among the other distributions allows the
> small number of contributors and testers to reuse code, reduce code
> complexity, and release new versions in a timely manner.

Reducing code complexity can also be done by the distribution. This
isn't something that only chef and puppet can provide.

> Furthermore,
> contributors and testers can easily implement changes to a particular
> OpenStack configuration file for the other distributions. However,
> similar changes for Debian require specifically installing and testing
> the Debian packages.

I don't understand why you are writing this.

> If a particular package doesn't already implement
> changes to the OpenStack configuration file, contributors must open a
> bug in another repository and wait for a patch or patch it themselves
> which requires additional skills and a completely different build and
> test environment.

I don't understand this bit either. Could you try again? :)

> Finally, updating the Debian procedures requires
> taking screen shots of Debconf that don't easily translate into other
> languages.

First, I've been doing it all alone, and I haven't seen anyone adding
screenshot. Second, the bits which are automated (except a few
exception) are all only in the specific debconf chapter. Last, we
haven't *ever* required anyone to take such screenshots, and we haven't
run into such issues when updating the doc. This is FUD.

> Why perform all of these extra steps to maintain the
> installation guide for one distribution?

Why do you care if I'm the one maintaining it anyway? And if it is about
patch review, I don't remember seeing you approving or commenting any of
my patches.

> I think we can resolve many of these issues by disabling Debconf in the
> installation guide and pointing people to supplemental documentation if
> they prefer to use it.

1/ I don't think we have any issue.

2/ Debconf is there, and we should document it.

3/ I do not have time to maintain things in another document (or are you
volunteering yourself to do the work?).

4/ Even if you switch to non-interactive mode, debconf will still be
there. For example, a valid "core_plugin" value will be set by the
neutron-common postinst script, and therefore, there will still be some
Debian specific things to write. You wont achieve the "let's simplify
things and remove Debian stuff from the install-guide" this way.

5/ The debconf part is only a *small* part of the install guides,
generally only the "install the service" part, and I generally don't
touch the other sections.

Thomas Goirand (zigo)