Open Stack

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 <aschultz at redhat.com> wrote:
> On Thu, Jan 5, 2017 at 10:25 AM, Michał Jastrzębski <inc007 at 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 <samuel at yaple.net> wrote:
>>> 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.
>>>
>>> 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
>>>
>>
>> __________________________________________________________________________
>> 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