<div dir="ltr">Hi<div class="gmail_extra">
</div><div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>Chris</div></div>