[openstack-dev] [tc][kolla] Adding new deliverables
Sam Yaple
samuel at yaple.net
Thu Jan 5 18:22:54 UTC 2017
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170105/5254549a/attachment.html>
More information about the OpenStack-dev
mailing list