[openstack-dev] [tc][kolla] Adding new deliverables

Doug Hellmann doug at doughellmann.com
Thu Jan 5 19:42:59 UTC 2017


Excerpts from Sam Yaple's message of 2017-01-05 18:22:54 +0000:
> On Thu, Jan 5, 2017 at 6:12 PM, Doug Hellmann <doug at doughellmann.com> wrote:
> 
> > Excerpts from Sam Yaple's message of 2017-01-05 17:02:35 +0000:
> > > On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley <fungi at yuggoth.org>
> > wrote:
> > >
> > > > On 2017-01-05 16:46:36 +0000 (+0000), Sam Yaple wrote:
> > > > [...]
> > > > > I do feel this is slightly different than whats described. Since it
> > is
> > > > not
> > > > > unrelated services, but rather, for lack of a better word, competing
> > > > > services. To my knowledge infra doesn't have several service doing
> > the
> > > > same
> > > > > job with different core teams (though I could be wrong).
> > > >
> > > > True, though I do find it an interesting point of view that helping
> > > > Kolla support multiple and diverse configuration management and
> > > > automation ecosystems is a "competition" rather than merely
> > > > extending the breadth of the project as a whole.
> > > >
> > >
> > > Yea I computer good, but I am no wordsmith. Perhaps 'friendly rivalry'? I
> > > expect these different deploy tools to bring new techniques that can then
> > > be reapplied to kolla-ansible and kolla-kubernetes to help out everyone.
> >
> > I'm still curious to understand why, if the teams building those
> > different things have little or no overlap in membership, they need to
> > be part of "kolla" and not just part of the larger OpenStack? Why build
> > a separate project hierarchy instead of keeping things flat?
> >
> > Do I misunderstand the situation?
> >
> > You absolutely do not misunderstand the situation. It is a very valid
> question, one to which I do not have a satisfying answer. I can say that it
> has been the intention since I started work on the ansible bits of kolla to
> have separate repos for the deployment parts. That grew to having several
> different deployment tools in the future and I don't think anyone really
> stopped to think that building this hierarchy isn't necessarily the right
> thing to do. It certainly isn't a required thing to do.
> 
> With the separation of ansible from the main kolla repo, the kolla repo now
> becomes a consumable much like the relationship keystone and glance.
> 
> The only advantage I can really think of at the moment is to reuse the
> Kolla name and community when starting a new project, but that may not be
> as advantageous as I initially thought. By my own admission, why do these
> other projects care about a different orchestration tool.
> 
> So in your estimation Doug, do you feel kolla-salt would be better served
> as a new project in it's own right? As well as future orchestration tools
> using Kolla container images?

I don't know enough about the situation to say for sure, and I'll
leave it up to the people involved, but I thought I should raise
the option as a way to ease up some of the friction.

Our team structure is really supposed to be organized around groups
of people rather than groups of things.  The fact that there's some
negotiation going on to decide who needs to (or gets to) have a say
in when new deliverables are added, with some people saying they
don't want to have to vote or that others shouldn't have a vote,
just makes it seem to me that we're trying to force a fit where it
would be simpler to establish separate teams.

There may be some common space for shared tools, and it sounds like
that's how things started out. But not maybe it's time to rethink
that?

Doug

> 
> Thanks,
> SamYaple
> 
> > Doug
> >
> > >
> > > Thanks,
> > > SamYaple
> > >
> > > > --
> > > > Jeremy Stanley
> > > >
> > > > ____________________________________________________________
> > ______________
> > > > OpenStack Development Mailing List (not for usage questions)
> > > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> > unsubscribe
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > >
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >



More information about the OpenStack-dev mailing list