Open Stack

----- Original Message -----
> From: "Robert Collins" <robertc at robertcollins.net>
> To: "OpenStack Development Mailing List" <openstack-dev at lists.openstack.org>, openstack-operators at lists.openstack.org
> Sent: Thursday, February 13, 2014 4:27:20 PM
> Subject: [openstack-dev] [TripleO] consistency vs packages in TripleO
> 
> 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?

Let me restate the options the way I see it:

Option A is we do our job... by making it possible to install OpenStack using various distributions using a set of distro agnostic tools (TripleO).

Option B is we make our job easy by strong arming everyone into the same defaults of our "upstream" choosing.

Does option B look appealing? Perhaps at first glance. By taking away the differences it seems like we are making everyone's lives easier by "streamlining" our depoyment codebase. There is this one rub though: it isn't what users expect. Take /mnt/state for example. This isn't the normal place for things to live. Why not use the read only root mechanism some distributions already have and work with that instead. Or perhaps have /mnt/state as a backup solution which can be used if a mechanism doesn't exist or is faulty?

In the end I think option A is the way we have to go. Is it more work... maybe. But in the end users will like us for it. And there is always the case that by not reimplementing some of the tools and mechanisms which already exist in distros that this ends up being less work anyways. I do hope so...

As for the reference implementation part of A I do hope we choose it wisely and that as much as possible the distros take note of our choices.

Dan

> 
> -Robv
> 
> 
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>