I like the idea of B, but realistically I don't see it ever happening. Their packages are already done and working with things in different places. It would not be possible to change the existing package sets to move things without breaking existing systems. Even if they wanted to. They usually don't want to because they want to follow their standard for file system layout. usually for good reason. /opt is a very not distro thing. Super packages are also very not distro. You might as well just have a tarball for /opt/openstack if your doing a super package sort of thing. Then you can further the argument and say if you are just throwing everyting in /opt/openstack, why not just image the whole thing in the first place and distribute that? No, I think it is its probably going to end up having to be A.
Now, with A, Its possible that, like most other upstreams, you just provide a reference platform and the distro folks patch it into a shape that works for them, and the end users just get everything from the distro. It really just depends on how much work you want to do, and how much you want the distro's to do customization wise. One argument made for B is a sysadmin can switch distro's with ease and still find everything in the same place. My experience is that its more likely that system admins tend to stick with a single distro, and its more intuitive if the packages follow the distro standard so that things are easy to find by the distro's standard. Rather then have to look up in a manual, you know where to look already. You could also come to a middle ground and provide some scripts that are in the path on any distro and smooth out the differences if needed. Thanks, Kevin ________________________________ From: John Dewey [j...@dewey.ws] Sent: Thursday, February 13, 2014 3:48 PM To: Robert Collins Cc: OpenStack Development Mailing List; openstack-operat...@lists.openstack.org Subject: Re: [Openstack-operators] [TripleO] consistency vs packages in TripleO 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
