[openstack-dev] [Cyborg] [Nova] Backup plan without nested RPs
Stephen Finucane
sfinucan at redhat.com
Tue Jun 5 12:50:52 UTC 2018
On Mon, 2018-06-04 at 10:49 -0700, Nadathur, Sundar wrote:
> Hi,
>
> Cyborg needs to create RCs and traits for accelerators. The
> original plan was to do that with nested RPs. To avoid rushing
> the
> Nova developers, I had proposed that Cyborg could start by
> applying
> the traits to the compute node RP, and accept the resulting
> caveats
> for Rocky, till we get nested RP support. That proposal did not
> find
> many takers, and Cyborg has essentially been in waiting mode.
>
>
>
> Since it is June already, and there is a risk of not delivering
> anything meaningful in Rocky, I am reviving my older proposal,
> which
> is summarized as below:
>
>
> Cyborg shall create the RCs and traits as per spec
> (https://review.openstack.org/#/c/554717/), both in Rocky and
> beyond. Only the RPs will change post-Rocky.
>
>
> In Rocky:
>
> Cyborg will not create nested RPs. It shall apply the device
> traits to the compute node RP.
> Cyborg will document the resulting caveat, i.e., all devices
> in the same host should have the same traits. In
> particular,
> we cannot have a GPU and a FPGA, or 2 FPGAs of different
> types, in the same host.
> Cyborg will document that upgrades to post-Rocky releases
> will require operator intervention (as described below).
>
>
>
> For upgrade to post-Rocky world with nested RPs:
>
> The operator needs to stop all running instances that use an
> accelerator.
> The operator needs to run a script that removes the Cyborg
> traits and the inventory for Cyborg RCs from compute node
> RPs.
> The operator can then perform the upgrade. The new Cyborg
> agent/driver(s) shall created nested RPs and publish
> inventory/traits as specified.
>
>
> IMHO, it is acceptable for Cyborg to do this because it is new
> and we can set expectations for the (lack of) upgrade plan. The
> alternative is that potentially no meaningful use cases get
> addressed in Rocky for Cyborg.
>
>
>
> Please LMK what you think.
I thought nested resource providers were already supported by
placement? To the best of my knowledge, what is not supported is virt
drivers using these to report NUMA topologies but I doubt that affects
you. The placement guys will need to weigh in on this as I could be
missing something but it sounds like you can start using this
functionality right now.
Stephen
>
>
> Regards,
>
> Sundar
>
>
>
> _____________________________________________________________________
> _____OpenStack Development Mailing List (not for usage
> questions)Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribehttp://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/20180605/7edac5f8/attachment.html>
More information about the OpenStack-dev
mailing list