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

Jesse Pretorius jesse.pretorius at gmail.com
Fri Feb 14 17:57:13 UTC 2014

On 14 February 2014 17:57, Jay Dobies <jason.dobies at redhat.com> wrote:

> I am propably repeating much of what James already said already. But I
>> think an
>> operator that makes the decision to do a package base Triplo installation
>> does
>> so e.g. because he is familiar with the tools and conventions of the
>> specific
>> distro/provider of the packages he choose. And probably wants TripleO to
>> be
>> consistent with that. And yes, with the decision for packages, he decides
>> to
>> differ from the reference layout.
> I agree with the notions that admins have come to expect differences from
> distro to distro. It's the case for any number of services.
> I'd go beyond that and say you're going to have problems getting the
> packages accepted/certified if they break the typical distro conventions.
> There are guidelines that say where things like Python code must live and
> packages may not even be accepted if they violate those.
> The same is likely for the admins themselves, taking issue if the packages
> don't match their expectation criteria for the distro.

As a deployer, agreed. Distro's have their conventions and administrators
get used to those conventions.

As an alternative to trying to get distro packagers to conform to what you
want, how about the part-way compromise of requesting that they at least
symbolically lync the standard convention for the project... that way it's
the best of both worlds.

Also, if a distro is going off the project standard then it really should
be the responsibility of the distro parties to participate in the
maintenance of the documentation. Obviously this can't be forced, but it
can be encouraged.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140214/023e267a/attachment.html>

More information about the OpenStack-operators mailing list