Open Stack

On Thu, Jan 5, 2017 at 7:42 PM, Doug Hellmann <doug at doughellmann.com> wrote:

> 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?
>
> This is definitely the case. Shared tooling. In the case of kolla-k8s and
kolla-ansible sharing the configs, this has broken kolla-k8s many times.
Perhaps the right decision long term is identifying all the needed pieces
that Kolla would be sharing and centralizing them rather than building this
Kolla hierarchy of projects forcing Kolla more into what resembles a
benevolent dictator model for all underlying deployment projects.

Thanks,
SamYaple

> 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
> > >
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170105/be492902/attachment.html>