Open Stack

Hi Robert,

> So far:
>  - some packages use different usernames
>  - some put things in different places (and all of them use different
> places to the bare metal ephemeral device layout which requires
> /mnt/).
>  - possibly more in future.

Somehow I miss between your suggestions of option #A and #B the option
#C, which started the whole discussion ;-)

The whole discussion started on service usernames really. I don't
really see the problem with that though, you're logging in as root and
all you do is running systemctl start <service>. if that drops
privileges to user "foo" or to user "bar" is really something that can
be abstracted away.

> # A
>  - we have a reference layout - install from OpenStack git / pypi
> releases; this is what we will gate on, and can document.

I assume that you mean this with the "from source" install. I don't
think that you really need to document each individual path or the
like. Most of the "support install from packages" changes were adding
symlinks to client libraries to /usr/local/bin, aka $PATH. As long as
all the binaries that you're as an operator to expect to call are in
$PATH, I see nothing wrong with just documenting the binary to be
available. I also think that the average OpenStack operator is able to
ignore the problem that if the documentation says "/usr/local/bin/foo"
and the binary is "/usr/bin/foo". I strongly believe most of them will
not even notice.

This is something that can be tested btw, and used to "certify"
documentation against reality, be it install from source or packages.

>  -> we need multiple manuals describing how to operate and diagnose
> issues in such a deployment, which is a matrix that overlays platform
> differences the user selects like 'Fedora' and 'Xen'.

Shouldn't that be part of the normal OpenStack Operations Guide? I
don't see how TripleO needs to reinvent general OpenStack
documentation? The existing documentation already covers most of the
platform differences.

> # B
>  - we have one layout, with one set of install paths, usernames
>  - package installs vs source installs make no difference - we coerce
> the package into reference upstream shape as part of installing it.

Which is done anyway already (by relinking stuff to /mnt/state).

>  - documentation is then identical for all TripleO installs, except
> the platform differences (as above - systemd on Fedora, upstart on
> Ubuntu, Xen vs KVM)

I think there is nothing wrong with requiring the documentation of
differences being updated
as part of such changes being introduced.

> I see this much like the way Nova abstracts out trivial Hypervisor
> differences to let you 'nova boot' anywhere, that we should be hiding
> these incidental (vs fundamental capability) differences.

Isn't that what the DIB elements do? you build a media with "nova"
element, and whatever platform you're building on, it will get you
nova up and running? Why would you need to document which user the
"nova" element runs under? This is an implementation detail.

In my opinion this boils down to: Tests for the documentation. If we
document that you can start a service
by running "systemctl start foobar", then there gotta be a test for
it. What the code does to launch the service when "systemctl start
foobar" is run is an implementation detail, and if it requires running
user "bar" instead of user "foo" then so be it.

Installing from packages is not as bad as you might think. It brings
down image building time to less than half the time you need from
source, and you can apply patches that fix *your* problem on *your*
platform. I understand the idea of Continuous Deployment, but it
doesn't mean that the one patch you need to have in your system for
something to work isn't hanging in an upstream review for 3 months or
more. It also allows distributors to provide services on top of
OpenStack, something that pays the pay checks of some of the people in
the community.



Greetings,
Dirk