<div dir="ltr">Hi Arkady,<div><br></div><div>Thanks for your interest in Cyborg project :) I would like to point out that when we initiated the project there are two specific use cases we want to cover: the accelerators attached locally (via PCIe or other bus type) or remotely (via Ethernet or other fabric type). </div><div><br></div><div>For the latter one, it is clear that its life cycle is independent from the server (like block device managed by Cinder). For the former one however, its life cycle is not dependent on server for all kinds of accelerators either. For example we already have PCIe based AI accelerator cards or Smart NICs that could be power on/off when the server is on all the time.</div><div><br></div><div>Therefore it is not a good idea to move all the life cycle management part into Ironic for the above mentioned reasons. Ironic integration is very important for the standalone usage of Cyborg for Kubernetes, Envoy (TLS acceleration) and others alike.</div><div><br></div><div>Hope this answers your question :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 4, 2020 at 5:23 AM <<a href="mailto:Arkady.Kanevsky@dell.com">Arkady.Kanevsky@dell.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_7177957148533436767WordSection1">
<p class="MsoNormal"><span style="font-size:20pt">Fellow Open Stackers,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">I have been thinking  on how to handle SmartNICs, GPUs, FPGA handling across different projects within OpenStack with Cyborg taking a leading role in it.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">Cyborg is important project and address accelerator devices that are part of the server and potentially switches and storage.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">It is address 3 different use cases and users there are all grouped into single project.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt"><u></u> <u></u></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="gmail-m_7177957148533436767MsoListParagraph" style="margin-left:0in"><span style="font-size:20pt">Application user need to program a portion of the device under management, like GPU, or SmartNIC for that app usage. Having a common way to do it across
 different device families and across different vendor is very important. And that has to be done every time a VM is deploy that need usage of a device. That is tied with VM scheduling.<u></u><u></u></span></li><li class="gmail-m_7177957148533436767MsoListParagraph" style="margin-left:0in"><span style="font-size:20pt">Administrator need to program the whole device for specific usage. That covers the scenario when device can only support single tenant or single use
 case. That is done once during OpenStack deployment but may need reprogramming to configure device for different usage. May or may not require reboot of the server.<u></u><u></u></span></li><li class="gmail-m_7177957148533436767MsoListParagraph" style="margin-left:0in"><span style="font-size:20pt">Administrator need to setup device for its use, like burning specific FW on it. This is typically done as part of server life-cycle event.<u></u><u></u></span></li></ol>
<p class="MsoNormal"><span style="font-size:20pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">The first 2 cases cover application life cycle of device usage.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">The last one covers device life cycle independently how it is used.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">Managing life cycle of devices is Ironic responsibility, One cannot and should not manage lifecycle of server components independently. Managing server devices outside server management violates customer service
 agreements with server vendors and breaks server support agreements.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">Nova and Neutron are getting info about all devices and their capabilities from Ironic; that they use for scheduling. We should avoid creating new project for every new component of the server and modify nova
 and neuron for each new device. (the same will also apply to cinder and manila if smart devices used in its data/control path on a server).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">Finally we want Cyborg to be able to be used in standalone capacity, say for Kubernetes.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">Thus, I propose that Cyborg cover use cases 1 & 2, and Ironic would cover use case 3.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">Thus, move all device Life-cycle code from Cyborg to Ironic.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">Concentrate Cyborg of fulfilling the first 2 use cases.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">Simplify integration with Nova and Neutron for using these accelerators to use existing Ironic mechanism for it.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">Create idempotent calls for use case 1 so Nova and Neutron can use it as part of VM deployment to ensure that devices are programmed for VM under scheduling need.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">Create idempotent call(s) for use case 2 for TripleO to setup device for single accelerator usage of a node.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">[Propose similar model for CNI integration.]<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">Let the discussion start!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:20pt">Thanks.,<br>
Arkady<u></u><u></u></span></p>
</div>
</div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Zhipeng (Howard) Huang</div><div dir="ltr"><br></div><div dir="ltr">Principle Engineer</div><div>OpenStack, Kubernetes, CNCF, LF Edge, ONNX, Kubeflow, OpenSDS, Open Service Broker API, OCP, Hyperledger, ETSI, SNIA, DMTF, W3C</div><div dir="ltr"><br></div></div></div></div></div></div></div></div>