Open Stack

On Thu, Feb 13, 2014 at 4:27 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> So progressing with the 'and folk that want to use packages can' arc,
> we're running into some friction.
>
> I've copied -operators in on this because its very relevant IMO to operators :)
>
> 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.
>
> Now, obviously its a 'small matter of code' to deal with this, but the
> impact on ops folk isn't so small. There are basically two routes that
> I can see:
>
> # A
>  - we have a reference layout - install from OpenStack git / pypi
> releases; this is what we will gate on, and can document.
>  - and then each distro (both flavor of Linux and also possibly things
> like Fuel that distribution OpenStack) is different - install on X,
> get some delta vs reference.

So far I think the delta is: service name and user account names. You
mention install paths below, but I'll reply to that there.

For service names, I think we already have a solution with the
os-svc-* tools. We're going to need tools like those anyway just to
account for system service name differences. We might as well tell
people to use them for the OpenStack services too.

For user account names, we don't have a great solution for this yet.

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

I think the delta is rather small, and I don't think that it's
necessarily TripleO's job to document it all. We have the reference
layout and that's what should be documented well. People who choose to
use packages know that they're doing so. In fact they are likely doing
so b/c they want the defined and consistent patterns they're used to.
They don't want every OpenStack service running in its own virtualenv
with dependencies duplicated across them. That's why they're using to
choose packages. They've deviated from the reference, that's Ok IMO.

> # B
>  - we have one layout, with one set of install paths, usernames

I'm actually not clear what you mean by install paths. Do you mean the
execution path to get stuff installed? Or where stuff ends up on the
actual filesystem?

Assuming you mean the latter, e.g., moving files that were installed
by a package under /opt/stack so the package install is the same as
the source install, I think that's a bit counter-intuitive to one of
the reasons people might be using packages to begin with.

Like I mentioned, one of the reasons that people  want to use packages
is for the consistent patterns they provide.  Moving python code out
from underneath site-packages so that it's all under /opt/stack even
for a packaged install makes the documentation worse IMO. We'd have to
document everything we've done to change the package, b/c we've undone
what people expect. That goes against the principle of least surprise,
b/c people who use packages, are expecting (and I suspect wanting)
stuff to end up where the package puts it.

>  - package installs vs source installs make no difference - we coerce
> the package into reference upstream shape as part of installing it.

We could document the reference and it would apply to everything. But,
I don't think the problem is solved. We would need to add
documentation for stuff like:
- your package manager is now going to complain about this set of
things, which you are safe to ignore
- your package dependencies aren't going to be reported correctly
- probably more

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

If we didn't do B, I think the documentation is still mostly
identical. IMO, it's not up to TripleO to document how rpm's install
OpenStack or how debs install OpenStack, or how Fuel does it.

> B seems much more useful to our ops users - less subtly wrong docs, we
> avoid bugs where tools we write upstream make bad assumptions,
> experience operating a TripleO deployed OpenStack is more widely
> applicable (applies to all such installs, not just those that happened
> to use the same package source).

Personally, I think B is much less useful to operators. But, I'm not
actually an operator :-).

However, if I were, and I used TripleO with package based installs,
and TripleO moved everything around and undid much of what the package
was laying down, I would find that extremely frustrating and not
useful at all.

Keep in mind I'm not talking about doing configuration changes, which
I think are well within the scope of stuff TripleO should do. But most
(if not all) package managers allow and support configuration changes
to config files without complaining.

All that being said, assuming if we go with "A", I think we could
likely come up with some more elegant solutions to account for some of
the differences in the package and source installs. It's mostly
procedural at the moment handled by if/else's. I'm sure we could come
up with something a bit more declarative to minimize the pain.

In fact, you're pretty much going to need the same code to exist
whether we go with A or B, it's just whether that code accounts for
the differences that exist, or attempts to reconcile them. Either way,
we have to express the differences.

-- 
-- James Slagle
--