[Openstack-operators] [openstack-dev] [TripleO] consistency vs packages in TripleO
matt at nycresistor.com
Fri Feb 14 03:32:42 UTC 2014
For many people in enterprise git / pypi deployments are non starters. We
use real package management systems with real signed packages for a bunch
of policy and architectural reasons. So anyone who is under the mistaken
impression that pypi especially will be a usable deployment model in the
real world let me disabuse you of that notion right now.
On Thu, Feb 13, 2014 at 8:08 PM, James Slagle <james.slagle at gmail.com>wrote:
> On Thu, Feb 13, 2014 at 4:27 PM, Robert Collins
> <robertc at 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-operators mailing list
> OpenStack-operators at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators