<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 5, 2017 at 5:56 PM, Alex Schultz <span dir="ltr"><<a href="mailto:aschultz@redhat.com" target="_blank">aschultz@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jan 5, 2017 at 10:25 AM, Michał Jastrzębski <<a href="mailto:inc007@gmail.com">inc007@gmail.com</a>> wrote:<br>
> Ad kolla-ansible core team +2ing new deliverable,I agree with Sam,<br>
> there is no reason in my mind for kolla-ansible/k8s core team to vote<br>
> on accepting new deliverable. I think this should be lightweight and<br>
> easy, we should allow experimentation (after all, kolla itself went<br>
> through few fail iterations before ansible).<br>
><br>
> Ad disconnect, I think we all are interested in other orch tools more<br>
> or less, but it's more about "who should allow new one to be added",<br>
> and that requires more than interest as might potentially block adding<br>
> new deliverable. Avoiding this disconnect is exactly why I'd like to<br>
> keep all deliverable team under one Kolla umbrealla, keep everyone in<br>
> same community so they can make use of each others experience (that<br>
> would also mean, that kolla-puppet is what I'd like to see rather than<br>
> puppet-kolla:)).<br>
><br>
<br>
</span>I mean it depends on what a proposed 'kolla-puppet' does. If it's<br>
like puppet-tripleo, which falls under the TripleO umbrella and not<br>
Puppet OpenStack because it configures more than just a single<br>
'openstack' related service then that would make sense. Since<br>
puppet-tripleo a way of deploying all things OpenStack it lives in the<br>
TripleO world. But I don't necessarily agree that kolla-puppet should<br>
exist over puppet-kolla if it just configures 'kolla'. I would like<br>
to see more cross group collaboration with the deployment tool groups<br>
and not keeping things to themselves. As for the intricacies of the<br>
specific deployment tooling, because we already have patterns and<br>
plenty of tooling for deploying OpenStack related services in our<br>
other 40 or so modules I think the Puppet OpenStack community might be<br>
better suited to provide review feedback than say the Kolla group when<br>
it comes to puppet specific questions and best practices. And<br>
speaking as the Puppet PTL there would not be anything stopping us<br>
from having Kolla cores also be cores on puppet-kolla.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>SamYaple</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think its important to focus on the sense of OpenStack community<br>
building (not just Kolla community) and spreading knowledge I think it<br>
would be better not to try and keep everything to yourself if there's<br>
already a group of people in the community who specialize in a<br>
specific thing. As an aside, I'd honestly like to see more<br>
contribution by the upstream projects into the puppet-* world because<br>
I think it's important for people to understand how the software they<br>
right actually gets consumed.<br>
<br>
Thanks,<br>
-Alex<br>
<div class="HOEnZb"><div class="h5"><br>
> Ad multi-deployment-tool friendly rivalry, it is meant to extend<br>
> breadth of the project indeed, but let's face it, religious wars are<br>
> real (and vim is better than emacs.);) I don't thing problem would be<br>
> ill intent tho, I could easily predict problem being rather in "I<br>
> don't have time to look at this review queue" sort. Stalling reviews<br>
> can kill lots of potentially great changes.<br>
><br>
><br>
> On 5 January 2017 at 09:02, Sam Yaple <<a href="mailto:samuel@yaple.net">samuel@yaple.net</a>> wrote:<br>
>> On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br>
>>><br>
>>> On 2017-01-05 16:46:36 +0000 (+0000), Sam Yaple wrote:<br>
>>> [...]<br>
>>> > I do feel this is slightly different than whats described. Since it is<br>
>>> > not<br>
>>> > unrelated services, but rather, for lack of a better word, competing<br>
>>> > services. To my knowledge infra doesn't have several service doing the<br>
>>> > same<br>
>>> > job with different core teams (though I could be wrong).<br>
>>><br>
>>> True, though I do find it an interesting point of view that helping<br>
>>> Kolla support multiple and diverse configuration management and<br>
>>> automation ecosystems is a "competition" rather than merely<br>
>>> extending the breadth of the project as a whole.<br>
>><br>
>><br>
>> Yea I computer good, but I am no wordsmith. Perhaps 'friendly rivalry'? I<br>
>> expect these different deploy tools to bring new techniques that can then be<br>
>> reapplied to kolla-ansible and kolla-kubernetes to help out everyone.<br>
>><br>
>> Thanks,<br>
>> SamYaple<br>
>>><br>
>>> --<br>
>>> Jeremy Stanley<br>
>>><br>
>>> ______________________________<wbr>______________________________<wbr>______________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>