Open Stack

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