<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 20, 2018 at 3:15 PM Eric Fried <openstack@fried.cc> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is great information, thanks Hongbin.<br>
<br>
If I'm understanding correctly, it sounds like Zun ultimately wants to<br>
be a peer of nova in terms of placement consumption. Using the resource<br>
information reported by nova, neutron, etc., you wish to be able to<br>
discover viable targets for a container deployment (GET<br>
/allocation_candidates) and claim resources to schedule to them (PUT<br>
/allocations/{uuid}). And you want to do it while Nova is doing the same<br>
for VMs, in the same cloud. Do I have that right?<br></blockquote><div><br></div><div>Yes, your interpretation is right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> * Is placement stable enough so that it won't break us often?<br>
<br>
Yes.<br>
<br>
> * If there is a breaking change in placement and we contribute a fix,<br>
> how fast the fix will be merged?<br>
> * If there is a feature request from our side and we contribute patches<br>
> to placement, will the patches be accepted?<br>
<br>
I believe this to be one of the main issues in the decision about<br>
independent governance. If placement remains under nova, it is more<br>
likely that fixes and features impacting the nova team would receive<br>
higher priority than those impacting zun.<br>
<br>
-efried<br>
<br>
> I express the Zun's point of view.<br>
> <br>
> Zun has a scheduler to schedule containers to nodes based on the<br>
> demanded and available compute resources (i.e. cpu, memory). Right now,<br>
> Zun's scheduler is independent of Nova so VMs and containers have to be<br>
> separated into two set of resource pools. One of the most demanding<br>
> features from our users (e.g. requested from Chinese UnionPay via<br>
> OpenStack Financial WG) is to have VMs and containers share the same set<br>
> of resource pool to maximize utilization. To satisfy this requirement,<br>
> Zun needs to know the current resource allocation that are made by<br>
> external services (i.e. Nova) so that we can take those information into<br>
> account when scheduling the containers. Adopting placement is a<br>
> straightforward and feasible approach to address that.<br>
> <br>
> As a summary, below are high-level requirements from Zun's perspective:<br>
> * Have VMs and containers multiplex into a pool of compute nodes.<br>
> * Make optimal scheduling decisions for containers based on information<br>
> (i.e. VM allocations) query from placement.<br>
> * Report container allocations to placement and hope external schedulers<br>
> can make optimal decisions.<br>
> <br>
> We haven't figured out the technical details yet. However, to look<br>
> forward, if Zun team decides to adopt placement, I would have the<br>
> following concerns:<br>
> * Is placement stable enough so that it won't break us often?<br>
> * If there is a breaking change in placement and we contribute a fix,<br>
> how fast the fix will be merged?<br>
> * If there is a feature request from our side and we contribute patches<br>
> to placement, will the patches be accepted?<br>
> <br>
> Regardless of whether placement is extracted or not, above are the<br>
> concerns that I mostly care about.<br>
> <br>
> Best regards,<br>
> Hongbin<br>
> <br>
> <br>
> <br>
> __________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>