Oh you misunderstood good sir;) kolla-puppet is similar to tripleo - it's would set up whole OpenStack using kolla containers deployed by puppet manifests. I agree, if it would only install kolla - that should go to openstack puppet, but kolla is a deployment tool.
On 5 January 2017 at 09:56, 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. > > 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