On Fri, Feb 14, 2014 at 10:27:20AM +1300, Robert Collins 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.
-> 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 agree with what James already said here. It probably not TripleO's job to
document all that. A good documentation for the reference layout should be the
goal.
And currently the differences aren't all that big I think. And for some of them
we already have good solutions (like e.g. the os-svc-* tools). There is room
for improvement in handling of the differences for usernames, though :)
# 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.
Unless I am completely missunderstanding your proposal I think this would void
many of the reasons why people would choose to install from packages in the
first place.
- 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 am propably repeating much of what James already said already. But I think an
operator that makes the decision to do a package base Triplo installation does
so e.g. because he is familiar with the tools and conventions of the specific
distro/provider of the packages he choose. And probably wants TripleO to be
consistent with that. And yes, with the decision for packages, he decides to
differ from the reference layout.
I agree with the notions that admins have come to expect differences
from distro to distro. It's the case for any number of services.
I'd go beyond that and say you're going to have problems getting the
packages accepted/certified if they break the typical distro
conventions. There are guidelines that say where things like Python code
must live and packages may not even be accepted if they violate those.
The same is likely for the admins themselves, taking issue if the
packages don't match their expectation criteria for the distro.
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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
