On Thu, Jan 5, 2017 at 7:45 PM, Michał Jastrzębski <inc...@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 <sam...@yaple.net> wrote: > > 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 > > > > __________________________________________________________________________ > 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