[Openstack-operators] [TripleO] consistency vs packages in TripleO

Fox, Kevin M Kevin.Fox at pnnl.gov
Fri Feb 14 01:06:38 UTC 2014


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 [john at dewey.ws]
Sent: Thursday, February 13, 2014 3:48 PM
To: Robert Collins
Cc: OpenStack Development Mailing List; openstack-operators at 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 <rbtcollins at hp.com<mailto:rbtcollins at hp.com>>
Distinguished Technologist
HP Converged Cloud

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140214/d521976d/attachment.html>


More information about the OpenStack-operators mailing list