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:
     o Cyborg will not create nested RPs. It shall apply the device
       traits to the compute node RP.
     o 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.
     o 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:
     o The operator needs to stop all running instances that use an
       accelerator.
     o The operator needs to run a script that removes the Cyborg
       traits and the inventory for Cyborg RCs from compute node RPs.
     o 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.

Regards,
Sundar
__________________________________________________________________________
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

Reply via email to