Open Stack

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

# 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.
 - documentation is then identical for all TripleO installs, except
the platform differences (as above - systemd on Fedora, upstart on
Ubuntu, Xen vs KVM)

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

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.

What say ye all?

-Robv


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud