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

Sam Yaple samuel at yaple.net
Thu Jan 5 20:06:49 UTC 2017


On Thu, Jan 5, 2017 at 7:45 PM, Michał Jastrzębski <inc007 at gmail.com> wrote:

> I think total separation of projects would require much larger
> discussion in community. Currently we agreed on having kolla-ansible
> and kolla-k8s to be deliverables under kolla umbrella from historical
> reasons. Also I don't agree that there is "little or no overlap" in
> teams, in fact there is ton of overlap, just not 100%. Many
> contributors (myself included) jump between deliverables today.
>
> Having single Kolla umbrella has practical benefits which I would hate
> to lose quite frankly. One of which would be that Kolla is being
> evaluated by lot of different companies, and having full separation
> between projects would make navigation of a landscape harder. Another
> reason is single community which we value - there is no full
> separation even between kolla-ansible and kolla-k8s (ansible still
> generates config files for k8s for example), and further separation of
> projects would hurt cooperation, and I don't think we've hit situation
> when it's necessary. I'm not ready to have this discussion yet, and
> I'm personally quite opposed to this.
>
> If kolla-salt would like to be first completely separate project,
> there is nothing we can (or want) to do to stop it, but I wouldn't
> like to see this being pushed. Having special beast isn't great, and
> moving kolla-ansible and kolla-k8s out of kolla umbrella is revolution
> I don't want to rush. I'd rather figure out process to accept
> kolla-salt (and following projects) to kolla umbrella and have this
> discussion later, when we actually hit community scale issues.
>

I don't think moving kolla-ansible or kolla-k8s out of the kolla namespace
was being suggested. If I implied that, it was not intended. That said,
with Doug's comments, I am not sure it makes sense to continue building a
Kolla deployment hierarchy. I would ask what the benefit of having
kolla-salt or kolla-puppet would be?

It is just a point that hasn't been discussed or considered up until now.
We had all just assumed kolla-salt and kolla-puppet and kolla-chef would be
a thing, but would there be a benefit to sitting under the kolla namespace?
I am not sure what those benefits are.

Thanks,
SamYaple


> Cheers,
> Michal
>
>
> On 5 January 2017 at 10:22, Sam Yaple <samuel at yaple.net> wrote:
> > 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?
> >
> > 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
> >
>
> __________________________________________________________________________
> 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/e849a785/attachment.html>


More information about the OpenStack-dev mailing list