Open Stack

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