Open Stack

On Thursday, February 13, 2014 at 1:27 PM, 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'.
> 
> # 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.
> 
> 

I personally like B.  In the OpenStack Chef community, there has been quite a bit of excitement over the work that Craig Tracey has been doing with omnibus-openstack [1].  It is very similar to B, however, it builds a super package per distro, with all dependencies into a known location (e.g. /opt/openstack/).

Regardless of how B is ultimately implemented, I personally like the suggestion.

[1] https://github.com/craigtracey/omnibus-openstack



John
> 
> What say ye all?
> 
> -Robv
> 
> 
> -- 
> Robert Collins <rbtcollins at hp.com (mailto:rbtcollins at hp.com)>
> Distinguished Technologist
> HP Converged Cloud
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org (mailto:OpenStack-operators at lists.openstack.org)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140213/859ddb09/attachment.html>