On Thu, Jan 5, 2017 at 5:56 PM, Alex Schultz <aschu...@redhat.com> wrote:
> On Thu, Jan 5, 2017 at 10:25 AM, Michał Jastrzębski <inc...@gmail.com> > wrote: > > Ad kolla-ansible core team +2ing new deliverable,I agree with Sam, > > there is no reason in my mind for kolla-ansible/k8s core team to vote > > on accepting new deliverable. I think this should be lightweight and > > easy, we should allow experimentation (after all, kolla itself went > > through few fail iterations before ansible). > > > > Ad disconnect, I think we all are interested in other orch tools more > > or less, but it's more about "who should allow new one to be added", > > and that requires more than interest as might potentially block adding > > new deliverable. Avoiding this disconnect is exactly why I'd like to > > keep all deliverable team under one Kolla umbrealla, keep everyone in > > same community so they can make use of each others experience (that > > would also mean, that kolla-puppet is what I'd like to see rather than > > puppet-kolla:)). > > > > I mean it depends on what a proposed 'kolla-puppet' does. If it's > like puppet-tripleo, which falls under the TripleO umbrella and not > Puppet OpenStack because it configures more than just a single > 'openstack' related service then that would make sense. Since > puppet-tripleo a way of deploying all things OpenStack it lives in the > TripleO world. But I don't necessarily agree that kolla-puppet should > exist over puppet-kolla if it just configures 'kolla'. I would like > to see more cross group collaboration with the deployment tool groups > and not keeping things to themselves. As for the intricacies of the > specific deployment tooling, because we already have patterns and > plenty of tooling for deploying OpenStack related services in our > other 40 or so modules I think the Puppet OpenStack community might be > better suited to provide review feedback than say the Kolla group when > it comes to puppet specific questions and best practices. And > speaking as the Puppet PTL there would not be anything stopping us > from having Kolla cores also be cores on puppet-kolla. > These are good points. I don't know which way I lean on this subject at the moment. But I would mention that kolla-ansible doesn't exist under openstack-ansible-kolla. And kolla-salt (should that become a thing) isn't openstack-salt-kolla. Just because there is an openstack project that uses a orchestration tool doesn't mean only one such project can exist. Nor that all approaches would be the same, even if the end goal is the same (deploy openstack). So I am going to remain neutral on this point and say what you are saying is reasonable, though on the other hand it may not be compatible in some situations. Thanks, SamYaple I think its important to focus on the sense of OpenStack community > building (not just Kolla community) and spreading knowledge I think it > would be better not to try and keep everything to yourself if there's > already a group of people in the community who specialize in a > specific thing. As an aside, I'd honestly like to see more > contribution by the upstream projects into the puppet-* world because > I think it's important for people to understand how the software they > right actually gets consumed. > > Thanks, > -Alex > > > Ad multi-deployment-tool friendly rivalry, it is meant to extend > > breadth of the project indeed, but let's face it, religious wars are > > real (and vim is better than emacs.);) I don't thing problem would be > > ill intent tho, I could easily predict problem being rather in "I > > don't have time to look at this review queue" sort. Stalling reviews > > can kill lots of potentially great changes. > > > > > > On 5 January 2017 at 09:02, Sam Yaple <sam...@yaple.net> wrote: > >> 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. > >> > >> 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