On Thu, Jan 5, 2017 at 6:12 PM, Doug Hellmann <d...@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 <fu...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
