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