<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 14, 2017 at 10:26 AM, James Slagle <span dir="ltr"><<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jul 14, 2017 at 12:16 PM, Fox, Kevin M <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>> wrote:<br>
> <a href="https://xkcd.com/927/" rel="noreferrer" target="_blank">https://xkcd.com/927/</a><br>
<br>
That's cute, but we aren't really trying to have competing standards.<br>
It's not really about competition between tools.<br>
<span class=""><br>
> I don't think adopting helm as a dependency adds more complexity then writing more new k8s object deployment tooling?<br>
<br>
</span>That depends, and will likely end up containing a fair amount of<br>
subjectivity. What we're trying to do is explore choices around<br>
tooling.<br>
<span class=""><br>
><br>
> There are efforts to make it easy to deploy kolla-kubernetes microservice charts using ansible for orchestration in kolla-kubernetes. See:<br>
> <a href="https://review.openstack.org/#/c/473588/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/473588/</a><br>
> What kolla-kubernetes brings to the table is a tested/shared base k8s object layer. Orchestration is done by ansible via TripleO, and the solutions already found/debugged to how to deploy OpenStack in containers on Kubernetes can be reused/shared.<br>
<br>
</span>That's good, and we'd like to reuse existing code and patterns. I<br>
admit to not being super famliliar with kolla-kubernetes. Are there<br>
reusable components without having to also use Helm?<br>
<span class=""><br>
> See for example:<br>
> <a href="https://github.com/tripleo-apb/ansible-role-k8s-keystone/blob/331f405bd3f7ad346d99e964538b5b27447a0ebf/provision-keystone-apb/tasks/main.yaml" rel="noreferrer" target="_blank">https://github.com/tripleo-<wbr>apb/ansible-role-k8s-keystone/<wbr>blob/<wbr>331f405bd3f7ad346d99e964538b5b<wbr>27447a0ebf/provision-keystone-<wbr>apb/tasks/main.yaml</a><br>
<br>
</span>Pretty sure that was just a POC/example.<br>
<span class=""><br>
><br>
> I don't see much by way of dealing with fernet token rotation. That was a tricky bit of code to get to work, but kolla-kubernetes has a solution to it. You can get it by: helm install kolla/keystone-fernet-rotate-<wbr>job.<br>
><br>
> We designed this layer to be shareable so we all can contribute to the commons rather then having every project reimplement their own and have to chase bugs across all the implementations. The deployment projects will be stronger together if we can share as much as possible.<br>
><br>
> Please reconsider. I'd be happy to talk with you more if you want.<br>
<br></span></blockquote><div>James,</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>Just to frame the conversation with a bit more context, I'm sure there<br>
are many individual features/bugs/special handling that TripleO and<br>
Kolla both do today that the other does not.<br>
<br></blockquote><div><br></div><div>I think what you are saying in a nutshell is that TripleO and Kolla compete.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
TripleO had about a 95% solution for deploying OpenStack when<br>
kolla-ansible did not exist and was started from scratch. But, kolla<br>
made a choice based around tooling, which I contend is perfectly valid<br>
given that we are creating deployment tools. Part of the individual<br>
value in each deployment project is the underlying tooling itself.<br>
<br></blockquote><div><br></div><div>I think what you are saying here is Kolla chose to compete on tooling.  I haven't really given it a lot of thought; I'd say all are technical choices made with Kolla had mostly to do with selecting wisely from the technical ecosystem.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think what TripleO is trying to do here is not immediately jump to a<br>
solution that uses Helm and explore what alternatives exist. Even if<br>
the project chooses not to use Helm I still see room for collaboration<br>
on code beneath the Helm/whatever layer.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>I believe it wise that you don't jump to any conclusion or solution that does or doesn't use Helm.  I'd encourage you to understand how Kubernetes works before making such technical choices.</div><div><br></div><div>All that said, there is clearly value in working together rather than apart.  To me, that is more important then the technical choices you are presented with.</div><div><br></div><div>Regards</div><div>-steve</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
--<br>
-- James Slagle<br>
--<br>
</font></span><div class="HOEnZb"><div class="h5"><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>