Hi Robert, > 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.
Somehow I miss between your suggestions of option #A and #B the option #C, which started the whole discussion ;-) The whole discussion started on service usernames really. I don't really see the problem with that though, you're logging in as root and all you do is running systemctl start <service>. if that drops privileges to user "foo" or to user "bar" is really something that can be abstracted away. > # A > - we have a reference layout - install from OpenStack git / pypi > releases; this is what we will gate on, and can document. I assume that you mean this with the "from source" install. I don't think that you really need to document each individual path or the like. Most of the "support install from packages" changes were adding symlinks to client libraries to /usr/local/bin, aka $PATH. As long as all the binaries that you're as an operator to expect to call are in $PATH, I see nothing wrong with just documenting the binary to be available. I also think that the average OpenStack operator is able to ignore the problem that if the documentation says "/usr/local/bin/foo" and the binary is "/usr/bin/foo". I strongly believe most of them will not even notice. This is something that can be tested btw, and used to "certify" documentation against reality, be it install from source or packages. > -> 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'. Shouldn't that be part of the normal OpenStack Operations Guide? I don't see how TripleO needs to reinvent general OpenStack documentation? The existing documentation already covers most of the platform differences. > # 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. Which is done anyway already (by relinking stuff to /mnt/state). > - documentation is then identical for all TripleO installs, except > the platform differences (as above - systemd on Fedora, upstart on > Ubuntu, Xen vs KVM) I think there is nothing wrong with requiring the documentation of differences being updated as part of such changes being introduced. > 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. Isn't that what the DIB elements do? you build a media with "nova" element, and whatever platform you're building on, it will get you nova up and running? Why would you need to document which user the "nova" element runs under? This is an implementation detail. In my opinion this boils down to: Tests for the documentation. If we document that you can start a service by running "systemctl start foobar", then there gotta be a test for it. What the code does to launch the service when "systemctl start foobar" is run is an implementation detail, and if it requires running user "bar" instead of user "foo" then so be it. Installing from packages is not as bad as you might think. It brings down image building time to less than half the time you need from source, and you can apply patches that fix *your* problem on *your* platform. I understand the idea of Continuous Deployment, but it doesn't mean that the one patch you need to have in your system for something to work isn't hanging in an upstream review for 3 months or more. It also allows distributors to provide services on top of OpenStack, something that pays the pay checks of some of the people in the community. Greetings, Dirk _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
