Open Stack

Hi

Assuming I am interpreting your mail correctly, I think option A makes
vastly more sense, with one very specific provision I'd add. More on that
in a moment.

Option B, the idea that we would mangle a package-installed environment to
suit our desired layout, is not going to work out well for us at all.

Firstly, I think we'll find there are a ton of problems here (just thinking
about assuming that we can alter a system username, in the context of the
crazy things you can hook into libnss, makes me shiver).
Secondly, it is also going to cause a significant increase in
distro-specific manglery in our DIB elements, no? Right now, handling the
username case could be simplified if we recognised "ok, this is a thing
that can vary", abstracted them into environment variables and allowed the
distros to override them in their base OS element. That is not very much
code, it would simplify the elements from where we are today and the
documentation could be auto-generated to account for it, or made to refer
to the usernames in a way the operator can dereference locally. Maybe we
can't do something like that for every friction point we hit, but I'd wager
we could for most).

Back to the specific provision I mentioned for option A. Namely, put the
extra work you mention, on the distros. If they want to get their atypical
username layout into TripleO, ask them to provide a fork of our
documentation that accounts for it, and keep that up to date. If their
choice is do that, or have their support department maintain a fork of all
their openstack support material, because it might be wildly different if
the customer is using TripleO, I suspect they'd prefer to do a bit of work
on our docs.

I completely agree with your comment later in the thread that "our job is
to be the upstream installer", so I suggest we do our best to only focus on
upstream, but in a way that enables our downstreams to engage with our
element repositories, by shouldering most of the burdens of their
divergence from upstream.

For me, the absolute worst case scenario in any distro's adoption of
TripleO, is that they are unwilling to be part of the community that
maintains tripleo-image-elements, and instead have their own elements that
are streamlined for their OS, but lack our community's polish and don't
contribute back their features/fixes. I think option B would drive any
serious distro away from us purely on the grounds that it would be a
nightmare for them to support.

Cheers,

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