Open Stack

On Mon, Aug 20, 2018 at 3:15 PM Eric Fried <openstack at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180820/05448d6d/attachment.html>