<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-06-22 18:59 GMT+03:00 Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My $0.02.<br>
<br>
That view of dependencies is why Kubernetes development is outpacing OpenStacks and some users are leaving IMO. Not trying to be mean here but trying to shine some light on this issue.<br>
<br>
Kubernetes at its core has essentially something kind of equivalent to keystone (k8s rbac), nova (container mgmt), cinder (pv/pvc/storageclasses), heat with convergence (deployments/daemonsets/etc), barbican (secrets), designate (kube-dns), and octavia (kube-proxy,svc,ingress) in one unit. Ops dont have to work hard to get all of it, users can assume its all there, and devs don't have many silo's to cross to implement features that touch multiple pieces.<br>
<br>
This core functionality being combined has allowed them to land features that are really important to users but has proven difficult for OpenStack to do because of the silo's. OpenStack's general pattern has been, stand up a new service for new feature, then no one wants to depend on it so its ignored and each silo reimplements a lesser version of it themselves.<br>
<br></blockquote><div><br>Totally agree<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The OpenStack commons then continues to suffer.<br>
<br>
We need to stop this destructive cycle.<br>
<br>
OpenStack needs to figure out how to increase its commons. Both internally and externally. etcd as a common service was a step in the right direction.<br>
<br>
I think k8s needs to be another common service all the others can rely on. That could greatly simplify the rest of the OpenStack projects as a lot of its functionality no longer has to be implemented in each project.<br>
<br>
We also need a way to break down the silo walls and allow more cross project collaboration for features. I fear the new push for letting projects run standalone will make this worse, not better, further fracturing OpenStack.<br>
<span class=""><br>
Thanks,<br>
Kevin<br>
______________________________<wbr>__________<br>
From: Thierry Carrez [<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>]<br>
</span>Sent: Thursday, June 22, 2017 12:58 AM<br>
<span class="im HOEnZb">To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove<br>
<br>
</span><div class="HOEnZb"><div class="h5">Fox, Kevin M wrote:<br>
> [...]<br>
> If you build a Tessmaster clone just to do mariadb, then you share nothing with the other communities and have to reinvent the wheel, yet again. Operators load increases because the tool doesn't function like other tools.<br>
><br>
> If you rely on a container orchestration engine that's already cross cloud that can be easily deployed by user or cloud operator, and fill in the gaps with what Trove wants to support, easy management of db's, you get to reuse a lot of the commons and the users slight increase in investment in dealing with the bit of extra plumbing in there allows other things to also be easily added to their cluster. Its very rare that a user would need to deploy/manage only a database. The net load on the operator decreases, not increases.<br>
<br>
I think the user-side tool could totally deploy on Kubernetes clusters<br>
-- if that was the only possible target that would make it a Kubernetes<br>
tool more than an open infrastructure tool, but that's definitely a<br>
possibility. I'm not sure work is needed there though, there are already<br>
tools (or charts) doing that ?<br>
<br>
For a server-side approach where you want to provide a DB-provisioning<br>
API, I fear that making the functionality depend on K8s would make<br>
TroveV2/Hoard would not only depend on Heat and Nova, but also depend on<br>
something that would deploy a Kubernetes cluster (Magnum?), which would<br>
likely hurt its adoption (and reusability in simpler setups). Since<br>
databases would just work perfectly well in VMs, it feels like a<br>
gratuitous dependency addition ?<br>
<br>
We generally need to be very careful about creating dependencies between<br>
OpenStack projects. On one side there are base services (like Keystone)<br>
that we said it was alright to depend on, but depending on anything else<br>
is likely to reduce adoption. Magnum adoption suffers from its<br>
dependency on Heat. If Heat starts depending on Zaqar, we make the<br>
problem worse. I understand it's a hard trade-off: you want to reuse<br>
functionality rather than reinvent it in every project... we just need<br>
to recognize the cost of doing that.<br>
<br>
--<br>
Thierry Carrez (ttx)<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><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Best regards,<br>Andrey Kurilin.<br></div></div>
</div></div>