On Thu, Feb 13, 2014 at 4:27 PM, Robert Collins <robe...@robertcollins.net> 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.
So far I think the delta is: service name and user account names. You mention install paths below, but I'll reply to that there. For service names, I think we already have a solution with the os-svc-* tools. We're going to need tools like those anyway just to account for system service name differences. We might as well tell people to use them for the OpenStack services too. For user account names, we don't have a great solution for this yet. > -> 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'. I think the delta is rather small, and I don't think that it's necessarily TripleO's job to document it all. We have the reference layout and that's what should be documented well. People who choose to use packages know that they're doing so. In fact they are likely doing so b/c they want the defined and consistent patterns they're used to. They don't want every OpenStack service running in its own virtualenv with dependencies duplicated across them. That's why they're using to choose packages. They've deviated from the reference, that's Ok IMO. > # B > - we have one layout, with one set of install paths, usernames I'm actually not clear what you mean by install paths. Do you mean the execution path to get stuff installed? Or where stuff ends up on the actual filesystem? Assuming you mean the latter, e.g., moving files that were installed by a package under /opt/stack so the package install is the same as the source install, I think that's a bit counter-intuitive to one of the reasons people might be using packages to begin with. Like I mentioned, one of the reasons that people want to use packages is for the consistent patterns they provide. Moving python code out from underneath site-packages so that it's all under /opt/stack even for a packaged install makes the documentation worse IMO. We'd have to document everything we've done to change the package, b/c we've undone what people expect. That goes against the principle of least surprise, b/c people who use packages, are expecting (and I suspect wanting) stuff to end up where the package puts it. > - package installs vs source installs make no difference - we coerce > the package into reference upstream shape as part of installing it. We could document the reference and it would apply to everything. But, I don't think the problem is solved. We would need to add documentation for stuff like: - your package manager is now going to complain about this set of things, which you are safe to ignore - your package dependencies aren't going to be reported correctly - probably more > - documentation is then identical for all TripleO installs, except > the platform differences (as above - systemd on Fedora, upstart on > Ubuntu, Xen vs KVM) If we didn't do B, I think the documentation is still mostly identical. IMO, it's not up to TripleO to document how rpm's install OpenStack or how debs install OpenStack, or how Fuel does it. > 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). Personally, I think B is much less useful to operators. But, I'm not actually an operator :-). However, if I were, and I used TripleO with package based installs, and TripleO moved everything around and undid much of what the package was laying down, I would find that extremely frustrating and not useful at all. Keep in mind I'm not talking about doing configuration changes, which I think are well within the scope of stuff TripleO should do. But most (if not all) package managers allow and support configuration changes to config files without complaining. All that being said, assuming if we go with "A", I think we could likely come up with some more elegant solutions to account for some of the differences in the package and source installs. It's mostly procedural at the moment handled by if/else's. I'm sure we could come up with something a bit more declarative to minimize the pain. In fact, you're pretty much going to need the same code to exist whether we go with A or B, it's just whether that code accounts for the differences that exist, or attempts to reconcile them. Either way, we have to express the differences. -- -- James Slagle -- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
