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 <rbtcoll...@hp.com (mailto:rbtcoll...@hp.com)> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > (mailto:openstack-operat...@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev