<!doctype html>
<html lang="en">
<head>
<title>nova-wallaby-ptg</title>
<meta name="generator" content="Etherpad">
<meta name="author" content="Etherpad">
<meta name="changedby" content="Etherpad">
<meta charset="utf-8">
<style>
* {
font-family: arial, sans-serif;
font-size: 13px;
line-height: 17px;
}
ul.indent {
list-style-type: none;
}
ol {
list-style-type: none;
padding-left: 0;
}
body > ol {
counter-reset: first second third fourth fifth sixth seventh eighth ninth tenth eleventh twelfth thirteenth fourteenth fifteenth sixteenth;
}
ol > li:before {
content: counter(first) ". ";
counter-increment: first;
}
ol > ol > li:before {
content: counter(first) "." counter(second) ". ";
counter-increment: second;
}
ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) ". ";
counter-increment: third;
}
ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) ". ";
counter-increment: fourth;
}
ol > ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) "." counter(fifth) ". ";
counter-increment: fifth;
}
ol > ol > ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) "." counter(fifth) "." counter(sixth) ". ";
counter-increment: sixth;
}
ol > ol > ol > ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) "." counter(fifth) "." counter(sixth) "." counter(seventh) ". ";
counter-increment: seventh;
}
ol > ol > ol > ol > ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) "." counter(fifth) "." counter(sixth) "." counter(seventh) "." counter(eighth) ". ";
counter-increment: eighth;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) "." counter(fifth) "." counter(sixth) "." counter(seventh) "." counter(eighth) "." counter(ninth) ". ";
counter-increment: ninth;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) "." counter(fifth) "." counter(sixth) "." counter(seventh) "." counter(eighth) "." counter(ninth) "." counter(tenth) ". ";
counter-increment: tenth;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) "." counter(fifth) "." counter(sixth) "." counter(seventh) "." counter(eighth) "." counter(ninth) "." counter(tenth) "." counter(eleventh) " ";
counter-increment: eleventh;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) "." counter(fifth) "." counter(sixth) "." counter(seventh) "." counter(eighth) "." counter(ninth) "." counter(tenth) "." counter(eleventh) "" counter(twelfth) ". ";
counter-increment: twelfth;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) "." counter(fifth) "." counter(sixth) "." counter(seventh) "." counter(eighth) "." counter(ninth) "." counter(tenth) "." counter(eleventh) "" counter(twelfth) "." counter(thirteenth) ". ";
counter-increment: thirteenth;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) "." counter(fifth) "." counter(sixth) "." counter(seventh) "." counter(eighth) "." counter(ninth) "." counter(tenth) "." counter(eleventh) "" counter(twelfth) "." counter(thirteenth) "." counter(fourteenth) ". ";
counter-increment: fourteenth;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) "." counter(fifth) "." counter(sixth) "." counter(seventh) "." counter(eighth) "." counter(ninth) "." counter(tenth) "." counter(eleventh) "" counter(twelfth) "." counter(thirteenth) "." counter(fourteenth) "." counter(fifteenth) ". ";
counter-increment: fifteenth;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > li:before {
content: counter(first) "." counter(second) "." counter(third) "." counter(fourth) "." counter(fifth) "." counter(sixth) "." counter(seventh) "." counter(eighth) "." counter(ninth) "." counter(tenth) "." counter(eleventh) "" counter(twelfth) "." counter(thirteenth) "." counter(fourteenth) "." counter(fifteenth) "." counter(sixteenth) ". ";
counter-increment: sixteenth;
}
ol {
text-indent: 0px;
}
ol > ol {
text-indent: 10px;
}
ol > ol > ol {
text-indent: 20px;
}
ol > ol > ol > ol {
text-indent: 30px;
}
ol > ol > ol > ol > ol {
text-indent: 40px;
}
ol > ol > ol > ol > ol > ol {
text-indent: 50px;
}
ol > ol > ol > ol > ol > ol > ol {
text-indent: 60px;
}
ol > ol > ol > ol > ol > ol > ol > ol {
text-indent: 70px;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol {
text-indent: 80px;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol {
text-indent: 90px;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol {
text-indent: 100px;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol {
text-indent: 110px;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol {
text-indent: 120px;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol {
text-indent: 130px;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol {
text-indent: 140px;
}
ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol > ol {
text-indent: 150px;
}
</style>
</head>
<body>
*Nova Wallaby virtual PTG<br>*DO NOT USE TRANSLATION TOOLS IN THIS ETHERPAD!!!! (ノ ゜Д゜)ノ c┻━┻<br>*不要在这个ETHERPAD中使用翻译工具！<br><strong>To translate this etherpad, please follow these easy instructions:</strong><br>1. Look in the above toolbar and click the '</>' ("Share this pad") button<br>2. Click the "Read only" checkbox at the top of the dialog box<br>3. Copy the URL that appears in the "Link" box<br>4. Open that URL in a new browser tab or window<br>5. Use your translation tools of choice in the new window<br>Thank you!<br><br><strong>要翻译此etherpad，请按照以下简单说明进行操作：</strong><br>1.查看上面的工具栏，然后单击“ </>”（“共享此记事本”）按钮<br>2.单击对话框顶部的“只读”复选框<br>3.复制出现在“链接”框中的URL<br>4.在新的浏览器标签或窗口中打开该URL<br>5.在新窗口中使用您选择的翻译工具<br>谢谢！<br><br>people/colours:<br><ul class="indent"><li>gibi</ul> sean-k-mooney/and this<br> stephenfin<br> lyarwood<br> bauzas<br> johnthetubaguy<br> brinzhang<br> xinranwang<br> kashyapc<br> aarents<br> gmann<br><br><br>*Schedule<br>October 26 - 30<br><br><strong>Every time is in UTC</strong><br><br><strong>28th Oct (Wednesday):</strong><br><ul class="bullet"><li>13:00 - 14:00: Nova-Cyborg cross project session</li><li>14:00 - 15:00: Nova-Neutron cross project session</ul><strong>29th Oct (Thrusday)</strong><br><ul class="bullet"><li>13:00 - 17:00 Nova PTG</ul><strong>30th Oct (Friday)</strong><br><ul class="bullet"><li>13:00 - 17:00 Nova PTG</ul><br>We will use the Liberty Zoom room for the sessions:<br><ul class="bullet"><li><a href="http://ptg.openstack.org/ptg.html" rel="noreferrer noopener">http://ptg.openstack.org/ptg.html</a></li><li><a href="https://www.openstack.org/ptg/rooms/liberty" rel="noreferrer noopener">https://www.openstack.org/ptg/rooms/liberty</a></ul><br>*PTG Topics<br>*Nova-Cyborg cross project<br><br><ul class="bullet"><li>(xinranwang, yumeng) SmartNIC: SRIOV nic support in nova, neutron and cyborg,<ul class="bullet"><li>spec: <a href="https://review.opendev.org/#/c/742785/" rel="noreferrer noopener">https://review.opendev.org/#/c/742785/</a></li><li>(Yongli He) POC: <a href="https://review.opendev.org/#/q/topic:bp/sriov-smartnic-support+(status:open+OR+status:merged)" rel="noreferrer noopener">https://review.opendev.org/#/q/topic:bp/sriov-smartnic-support+(status:open+OR+status:merged)</a><ul class="bullet"><li>This POC patch set make discuss more specific and make obscure filed exposed. It does not imply design decision,</ul></li></ul></li></ul><ul class="indent"><li><ul class="indent"><li><ul class="indent"><li>and does not mean It's favorited.</ul></li></ul></li></ul><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li>There is a simple changes log in nova patch's commit message.</ul><li>this isnt really a good tilte by the way its not really about sriov nic supprot and more about smartnic support<ul class="bullet"><li>(alex) this spec seems more focus on SRIOV-Nic, smartnic is futhur step in the future.</ul><li>(gibi): Does nova need to know that a neutron port is backed by a SmartNIC? After reading the spec it seems that SmartNIC for nova is just a PCI backed neutron port with a (non bandwidth related) resource request.<ul class="bullet"><li>(xinranwang) nova should retrieve device profile name from neutorn port back_end field, and put them into resource request, in neutron.py file.</li><li>Yes, For Nova, this spec is only a pci deivce managed by Cyborg. And smartnic andvanced feature is handled by Cyborg. </li><li>I would be happier not to have a specific implementation for these kind of neutron ports. The resource request of the cyboorg device could come from the neutron port directly. However after the binding, the PCI info needs to come from cyborg anyhow. :/</li><li>（yongli）exactly, we could not elimated all interaction with cyborg. (gibi): yeah I have to accept this.</li><li>general speaking, is it ok?</li><li><strong>AGREED</strong>: overall direction seems OK</ul></li></ul></li></ul><br><ul class="bullet"><li><ul class="bullet"><li>Opens:<ul class="bullet"><li>co-exist with neutron bandwidth qos feature.<ul class="bullet"><li>keep the config file consistent between neutron qos and cyborg (the "<strong>pysical_network</strong>" traits and RP)<ul class="bullet"><li>(gibi): this is not qos specific. The physical network - backing device mapping is defined both in neutron and nova even without qos is configured<ul class="bullet"><li>neutron: [sriov_nic]/physical_device_mappings</li><li>nova: [pci]/passthrough_whitelist <-- during the discussion I relaized that this is irrelevant for SmartNICs case</ul></li></ul><li>let neutron report phynets traits anyway, need figure out how looks like the rp tree structure.</li><li>(yongli)Which way prefer? (change neutron or use config file)</li><li><strong>AGREED</strong>: cyborg will have a physnet configuration</li><li>To avoid representing the same physical device twice (once by neutron sriov nic agent and once by cyborg) we can try to move the QoS config and inventory reporting of SmartNIC to cyborg</ul></li></ul></li></ul></li></ul><br><br><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li>(Yongli)do we need a new vnic?<ul class="bullet"><li>seems we don't need new one. we support only "direct" (direct passthough), and it's toltally identical to PCI passthrough.</li><li>Agree?-1</li><li>(sean-k-mooney): there already is one vnic_type="smart-nic"</li><li><a href="https://github.com/openstack/neutron-lib/blob/52a75a02a204e1bcd5b9be6c9f13effa0380eaeb/neutron_lib/api/definitions/portbindings.py#L119" rel="noreferrer noopener">https://github.com/openstack/neutron-lib/blob/52a75a02a204e1bcd5b9be6c9f13effa0380eaeb/neutron_lib/api/definitions/portbindings.py#L119</a><ul class="bullet"><li>nova don't know this type?</ul><li>direct is tied into lots of complciated logic i would prefer not to reuse it for cyborg and keep direct for pci devices manged by nova in the pci tracker.</li><li>spcifically i do ot want to have to rework this logic that create a pci request spec for all neutron sriov vnic types <a href="https://github.com/openstack/nova/blob/a83001a903c50143afe2957be6ca72a6e3b884f5/nova/network/neutron.py#L2121-L2146" rel="noreferrer noopener">https://github.com/openstack/nova/blob/a83001a903c50143afe2957be6ca72a6e3b884f5/nova/network/neutron.py#L2121-L2146</a><ul class="bullet"><li>based on what we learned from POC , we don't need to change "pci request" logic. (fix me)</li><li>we would if the pci request filter is enabled since the host wont have any pci devices in the nova database but that code will create a pci request.</li><li>vnic types are cheap and it will make the support explict which is likely better in the long term. (gibi): +1 for explicitness</ul><li><strong>AGREED</strong>:<ul class="bullet"><li>vnic_type=direct triggers the nova PCI tracker codepath. We don't want to trigger that for cyborg SmartNICs</li><li>vnic_type=smartnic is already used for Ironic-> do not reuse it</li><li>so we need a new vnic_type for cyborg SmartNICs. Bikeshed on the naming in the spec (e.g. accelerator, device_profile)</ul></li></ul><li>(gibi): UX questions:<ul class="bullet"><li>Will neutron reject port creation with an invalid cyborg device profile? Or only nova will detect that the device profile stored in the neutron port is invalid (e.g. not exists in cyborg)?</ul></li></ul></li></ul></li></ul><ul class="indent"><li><ul class="indent"><li><ul class="indent"><li><ul class="indent"><li>(yongli) This is an open, in POC, only nova sense this kind of error. must have?</ul></li></ul></li></ul></li></ul><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li>Does the device profile in the neutron port changeable after port create? only for unbound port?</li><li>(yongli) seems the simplest choice is not allow to change, if want to do that, delete and create a new one.</li><li>Will the implementation support attaching / detaching a port that has device profile? If not, then we need to explicitly reject it.</li><li>(yongli) not going to support this right now(out of scope for this spec). so there should be an explicitly reject , yes.</ul><li></ul></li></ul></li></ul><br><ul class="bullet"><li>Nova-cyborg integration: VGPU support (Yumeng, Brin, Wenping)<ul class="bullet"><li>nova-libvirt-support: (Brin, wenping)nova side spec: <a href="https://review.opendev.org/#/c/750116/" rel="noreferrer noopener">https://review.opendev.org/#/c/750116/</a><ul class="bullet"><li>(Yumeng)changes in nova side mainly lies in the libvirt driver process, which include:<ul class="bullet"><li>1. when spawning a vm with vGPU, the UUID of a mdev device was passed to libvirt driver by acc_info, then the libvirt driver create a mdev with that given UUID and later writes the UUID into instance's XML.</li><li>2. we should make sure that the new mdev support does not conflict with current mdev management process. <ul class="bullet"><li>maybe we can avoid such conclict by defining a new tag mdev_tags in spawn( ) and then use it where necessary.</li><li>the enumerate values of mdev_tags could be ("COMPUTE", "ACCELERATOR"), "COMPUTE" is the default value, which means mdev is managed by nova, "ACCELERATOR" means mdev is managed by cyborg</ul><li>3. extend _guest_add_accel_pci_devices to support both pci devices and mdev devices</ul></li></ul><li> (Yumeng) cyborg-driver-support: cyborg-side spec <a href="https://review.opendev.org/758925" rel="noreferrer noopener">https://review.opendev.org/758925</a><ul class="bullet"><li>changes in cyborg side mainly lies in nvidia driver side, which should include:<ul class="bullet"><li>1. cyborg support configuring vgpu_type for each device in cyborg.conf</li><li>2. driver should distinguish whether the device is a pas-through GPU or virtulized GPU, and then generate resource_class(RC)<ul class="bullet"><li>driver can distinguish by the existence of "/sys/bus/pci/devices/{PCI_ADDRESS}/mdev_supported_types". If the path exists, it is a virtulized GPU, otherise it is a pas-through GPU.</ul><li>3.generate traits：<ul class="bullet"><li>We need to define the traits format. Is this format ok? CUSTOM_<VENDOR_NAME>_<PRODUCT_ID>_<Virtual_GPU_Type>?<ul class="bullet"><li>cyborg traits: OWNER_CYBORG_CUSTOM_GPU_NVIDIA_1EB8_T41B</li><li>nova traits: OWNER_NOVA_CUSTOM_GPU_NVIDIA\OWNER_NOVA_CUSTOM_GPU_1EB8</ul><li>The traits will be reported to both cyborg-db and placement and will be used in device_profile when requesting an accelerator and in nova scheduler, what format of Virtual_GPU_Type should we use? <ul class="bullet"><li>should we directly use the vgpu_type which was set in cyborg.conf eg. nvidia-223 or we need to do a map to T4-1B? <a href="https://docs.nvidia.com/grid/latest/pdf/grid-vgpu-user-guide.pdf" rel="noreferrer noopener">https://docs.nvidia.com/grid/latest/pdf/grid-vgpu-user-guide.pdf</a></li><li>traits example: CUSTOM_NVIDIA_1EB8_T4_1B or CUSTOM_NVIDIA_1EB8_nvidia-223 ?</ul></li></ul><li>4. generate device, deployable, controlpath_id, attach_handle objects<ul class="bullet"><li>GPU device </ul></li></ul></li></ul></li></ul></li></ul><ul class="indent"><li><ul class="indent"><li><ul class="indent"><li><ul class="indent"><li><ul class="indent"><li> | |</li><li> | deployable ---> resource_provider</li><li> | |</li><li>vgpus attach_handles ---> allocations</ul></li></ul></li></ul></li></ul></li></ul><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li></ul></li></ul><li>(bauzas) We need more details about :<ul class="bullet"><li>the Placement Resource Providers modeling<ul class="bullet"><li>for example. 1 GPU device with 4 vGPUs, will report 1 resource provider with 4 in the inventory</li><li>Q: will the new GPU resource provider have the compute node as its parent?</li><li>Yes</li><li>observation: same as vgpu, except cyborg owns the resource provider</li><li>Current Nova documentation for mdevs : <a href="https://docs.openstack.org/nova/latest/admin/virtual-gpu.html" rel="noreferrer noopener">https://docs.openstack.org/nova/latest/admin/virtual-gpu.html</a></ul><li>how to make sure that Cyborg mdevs won't be used by the mdev management we have in nova<ul class="bullet"><li>add mdev_tag to confirm where is the mdev request from, if </li><li> ah_types_set = {arq['attach_handle_type'] for arq in accel_info} contains "MDEV", then it is from cyborg(make sure need to check this gpu is not managed by nova)</li><li>Observation: if nova and cyborg conflict you just get "resource in use" errors<ul class="bullet"><li>Does it mean we can enabled the same vgpu_type in nova.conf and cyborg.conf at the same time ?</ul><li>... its worse, Nova needs to know not to create mdev devices when its cyborg?</ul><li>how the libvirt spawn() will not use the mdev management if needed</ul></li></ul></li></ul></li></ul><br><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li>(gibi): flavor based VGPU resource should be allocated from the nova managed RP. While device profile based VGPU resource should be allocated from the cyborg managed RP. <ul class="bullet"><li><ul class="bullet"><li>use owner (nova, cyborg) trait in Placement when the inventory is reported<ul class="bullet"><li>e.g. OWNER_NOVA, OWNER_CYBORG this would be a new namepace in os-traits</li><li>this is similar to consumer type (instance, migration). Neither consumer types no RP types (or owners, or factories) are exists in placement today</li><li>thanks forgot the name(consumer type)</li><li><strong>AGREED</strong>: use OWNER_* traits</ul><li>include the owner trait in the allocation candidate query</li><li>libvirt driver should only create MDEVs if the allocation is for a nova managed RP.</ul></li></ul></li></ul></li></ul></li></ul><br><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li><strong>NEXT STEPS:</strong> detail out the needed nova changes in the spec</ul></li></ul></li></ul><ul class="indent"><li><ul class="indent"><li><ul class="indent"><li></ul></li></ul></li></ul><br>*Nova-Neutron cross project<br><br><ul class="bullet"><li>(bauzas): the status of the scheduler support for routed network+1<ul class="bullet"><li>spec: <a href="https://review.opendev.org/733703" rel="noreferrer noopener">https://review.opendev.org/733703</a> </li><li>we will continue working on this in Wallaby</li><li><strong>Future work</strong>: to provide the routed network information via the port resource_request. Bauzas has no bandwidth for make this happen so<strong> it can be taken over by other developers</strong><ul class="bullet"><li>see Alternative section in <a href="https://review.opendev.org/#/c/733703/6/specs/victoria/approved/routed-networks-scheduling.rst@87" rel="noreferrer noopener">https://review.opendev.org/#/c/733703/6/specs/victoria/approved/routed-networks-scheduling.rst@87</a></li><li>ping bauzas on #openstack-nova if you are interested<ul class="bullet"><li>mlavalle's employer is interested on this. We will follow up with bauzas</ul></li></ul></li></ul></li></ul><br><ul class="bullet"><li>(sean-k-mooney) nova support for neutron port NUMA affinity<ul class="bullet"><li>basically this is a follow up to the vm wide pci nume affinity image and flavor extra spec.</li><li>neutron has been enhanced to add a new property to the neutron port that is the numa affinity policy that should be applied</li><li>this would allow requireing strict numa affinity for sriov ports while disabling affintiy for say the management interface.</li><li>this would also allow you to opt out of numa aware vswitch which today enforces trict numa affiinity for all vms on the host if its configured.</li><li>the nova changes are basically as follows:<ul class="bullet"><li>extend the nova.network.model.vif object to store the numa affinity policy.</li><li>extend the nova neutorn model to populate that wehn we buidl the port form the neutron responce.</li><li>check the numa affinity policy fo porst as part of the scudling process and propagate it to the exising numa affinity code for sriov inteface and numa vswitches.</li><li>optionally allow a default affinity policy to be set for numa vswichs in teh nova.conf other then strict. this would allow you to configure the feature so that the info is avaiable to nova to scdule on but not enforce affintiy unless asked.</ul><li>TODO(sean-k-mooney): file a spec for this assuming we have agreement<ul class="bullet"><li>the optional default affinity policy for numa vswitch is one of the design point i want to get imput on but we could leave that to the spec too</ul><li>Neutron code: <a href="https://review.opendev.org/#/q/topic:bug/1886798+(status:open+OR+status:merged)" rel="noreferrer noopener">https://review.opendev.org/#/q/topic:bug/1886798+(status:open+OR+status:merged)</a></li><li><strong>AGREED</strong>: lets have a small spec in nova about it. But overall direction seems OK.</ul></li></ul><br><ul class="bullet"><li>(sean-k-mooney): vhost-vdpa support in nova/neutron via ml2/ovs and libvirt.</li><li><a href="https://review.opendev.org/#/q/topic:vhost-vdpa+(status:open+OR+status:merged)" rel="noreferrer noopener">https://review.opendev.org/#/q/topic:vhost-vdpa+(status:open+OR+status:merged)</a><ul class="bullet"><li>neutron changes: <ul class="bullet"><li>new vnic_type=vdpa (neutron lib)</li><li><a href="https://review.opendev.org/#/c/760043/" rel="noreferrer noopener">https://review.opendev.org/#/c/760043/</a></li><li>add support to neutron l2 agent for vnic_type= vdpa (neutron)<ul class="bullet"><li>this really should just be in the a tiny change to the ml2 driver similar to <a href="https://github.com/intel-orchestration-software/networking-vhost-vfio/blob/master/networking_vhost_vfio/neutron/ml2/driver/mech_ovs_vhost_vfio.py" rel="noreferrer noopener">https://github.com/intel-orchestration-software/networking-vhost-vfio/blob/master/networking_vhost_vfio/neutron/ml2/driver/mech_ovs_vhost_vfio.py</a></li><li>the vdpa vnic type just tells nova that instead of adding a VF directly to a vm we should instead select a vdpa device</li><li>neutron will configure the ovs port as any other port.<ul class="bullet"><li>(ralonsoh) same as an OVS normal port? or do we need to add the L1 operations as with smartnic ports? --> HW offload ports (like OVS normal ports)</ul><li><a href="https://review.opendev.org/#/c/760047/1" rel="noreferrer noopener">https://review.opendev.org/#/c/760047/1</a></ul><li><strong>AGREED:</strong> looks OK from Neutron side</ul><li>nova changes<ul class="bullet"><li>the libvirt driver needs to support generating the libvirt interface xml</li><li>the libvirt driver need to track vdpa devices and their assotion to VFs.<ul class="bullet"><li>this can use the reouces infrastucture added for PMEM or it can extend the pci tracker code with a new device type type_vdpa.</li><li>adding a new device type to the pci tracker is the prefered option as its the smallest change and will alows use to block requeting vdpa device via pci aliases which is always incorrect to do.</li><li>this simple amount to marking something as type-vdpa when it reports the vdpa capablity here: <a href="https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7062" rel="noreferrer noopener">https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7062</a></ul><li>the libvirt xml requires that we specify the /dev/* device path in the xml as a result we need to modify this on live migration so we need to extend the migration_data object as we did for sriov and numa migration.</li><li>eventually nova shoudl report these vdpa resouce to plamcent after pci device are tracked in placement.</li><li>initally nova will just report a new trait hw_vhost_vdpa for all host that have pci devevices with the vdpa capablity.</li><li>this will be automatically added with a placement prefilter to and vms with a vdpa type port. (note at like other sriov like interface, ports will have to be precreated with vnic type vdpa before booting the vm with those ports)</li><li>as the vdpa device are assocated with VFs transitivly that gives them a numa affinity. the inital support could be done without numa affintiy and that can be added later without</li><li>to much effort, just reuse the affinity policies for neutorn port or the flavor to contol it.</li><li>over all the nova changes will be very similar to <a href="https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/netronome-smartnic-enablement.html" rel="noreferrer noopener">https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/netronome-smartnic-enablement.html</a></li><li>the only real delta between vhost-vdpa and virtio forwarder from a nova perspective is that in the hardware nativly speaks the virtio packet format so no user space applciation is required to do the translation and the kernel provides a vhost backed for it via the new vhsot_vdpa module.</ul><li>future work<ul class="bullet"><li>numa<ul class="bullet"><li>as with virtio-forwarder and sriov numa affintiy can be enabled via numa affinity fo the VF</li><li>technically vdpa device do not have to be associated with VFs they can be implemted purly in software.</li><li>as an intilal implemantnion we could levage the numa affinity of the vf when usign the sriov nic agent as the ml2 driver</li><li>for other backend that do not leave sriov we can look at numa affinity when they exist.</ul><li>placement<ul class="bullet"><li>we could track vdpa device in placment without numa affinity or generic pci passthough devices in placment.</li><li>just like vGPUs we would add a nested RP for vdpa devices and create an invetory of them.</li><li>we could create 1 rp per parent PF device so that we can use traits to model physnets.</ul><li>ovs-dpdk<ul class="bullet"><li>ovs-dpdk support is out of scope at this time. it can be added in the future if support for vdpa is added without modifying neutorn by simply looking at the datapath type in the port bindings to determin if its dpdk or kernel ovs.</ul><li>linuxbridge<ul class="bullet"><li>in theory adding the vf repsentor to a linux bridge is all that is require however at this no vendor has implemented that yet.</li><li>os-vif would handel adding the vif on nova behalf but the linux bridge plug would have to be enhanced to do this.</li><li>there is no documentaiton on usign vdpa with linux bridge but im told it shoudl just work in the future.</li><li>on the neutron side it woudl jsut have to accpet the vdpa vnic_type type in the ml2 driver but that is currenlty out of scope.</ul><li>sriov-nic-agent<ul class="bullet"><li>at present vdpa can only be used with melonox nics in switchdev mode. in that mode they cannot be managed correctly with the sriov-nic agent so this is out of scope.</li><li>future nics form other vendor might support non switchdev mode but until that happens ovs is the only contol plane that we can enable.</ul></li></ul><li><strong>AGREED:</strong><ul class="bullet"><li>Go with the PCI tracker based solution to gain the NUMA affinity support for free</li><li>Add the minimal placement interaction; the capability trait</li><li>Discuss moving PCI tracking to Placement separately</li><li>We need a nova spec</ul></li></ul></li></ul><br><ul class="bullet"><li>Discussion around port flavor / default vnic_type on a neutron network<ul class="bullet"><li>similar to network qos policy that is the default qos policy of the ports created on that network</li><li>=> johnthetubaguy + mlavalle to continue discussing</li><li><strong>NEXT STEP: </strong>John to draft a spec</ul></li></ul><br><br>*Nova PTG topics<br><br>*<strong>Wednesday (28th ) 15:10 UTC - 16:59 UTC - dev process and team related topics</strong><br><br><ul class="bullet"><li>(gibi): Victoria retrospective<ul class="bullet"><li>What went well?<ul class="bullet"><li>We closed 9 bp out of the 16 approved, this is 56% completion rate</li><li>I think the runway process helped focusing on the almost done bps +1<ul class="bullet"><li>(gibi): bauzas suggested to optionaly you can put your name to a runway slot item to indicate you will review it. </ul><li>We managed to push down the number of untriaged bugs and also kept the low number during the last couple months+1000 +1<ul class="bullet"><li>We have a lot of stale stuff in launchpad, we can try to look at them during W.<ul class="bullet"><li>E.g. Move bugs in fix commited to fix release state</li><li>E.g. in progress bugs without open patches</li><li>Incomplete bugs expire automatically</li><li>Check bug in progress without any tag</ul></li></ul><li>No API microversion in Victoria :). <ul class="bullet"><li>Or DB migrations (though that one's not new)</ul></li></ul><li>What should we do differently?<ul class="bullet"><li>johnthetubaguy: my time management/availability has got terrible again :'( working on that...</li><li>lyarwood: Create more ER queries & LP bugs when CI issues are encountered, less blind rechecks! +1<ul class="bullet"><li>(stephenfin) I can do this but I have no idea how /o\ Something for our docs?<ul class="bullet"><li>lyarwood: <a href="https://docs.openstack.org/infra/elastic-recheck/" rel="noreferrer noopener">https://docs.openstack.org/infra/elastic-recheck/</a> yeah we should point to this somewhere if we don't already.<ul class="bullet"><li>TIL <a href="https://docs.openstack.org/infra/elastic-recheck/readme.html#running-queries-locally" rel="noreferrer noopener">https://docs.openstack.org/infra/elastic-recheck/readme.html#running-queries-locally</a></ul><li>gmann: <a href="https://docs.openstack.org/infra/elastic-recheck/readme.html#queries" rel="noreferrer noopener">https://docs.openstack.org/infra/elastic-recheck/readme.html#queries</a> . Also to note or to ask help - elastic-recheck is maintained by TripleO maintainer under opendev now.</li><li><a href="https://docs.openstack.org/neutron/pike/contributor/policies/gerrit-recheck.html" rel="noreferrer noopener">https://docs.openstack.org/neutron/pike/contributor/policies/gerrit-recheck.html</a></li><li><a href="http://status.openstack.org/elastic-recheck/data/integrated_gate.html" rel="noreferrer noopener">http://status.openstack.org/elastic-recheck/data/integrated_gate.html</a></li><li><u>unclassified rate </u><a href="http://status.openstack.org/elastic-recheck/data/others.html" rel="noreferrer noopener"><u>http://status.openstack.org/elastic-recheck/data/others.html</u></a> </ul><li>=> Let's report critical bugs for intermittent gate failures.</li><li>=> lyarwood will document this.</ul><li>(stephenfin) Interaction with placement probably needs to grow again (there's a topic for that later)</li><li>(stephenfin) As always, growing our core list would be nice, though that's easier said than done :)</ul><li>Any other feedback</ul></li></ul><br><ul class="bullet"><li>(lyarwood) CODEOWNERS<ul class="bullet"><li>Do we want to codify <a href="https://wiki.openstack.org/wiki/Nova/BugTriage" rel="noreferrer noopener">https://wiki.openstack.org/wiki/Nova/BugTriage</a> in the tree somehow so interested devs can be found and even automatically added to reviews?</li><li>While this was introduced as a a platform specific thing it does appear we could use tooling locally to query the file<ul class="bullet"><li><a href="https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners" rel="noreferrer noopener">https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners</a></li><li><a href="https://docs.gitlab.com/ee/user/project/code_owners.html" rel="noreferrer noopener">https://docs.gitlab.com/ee/user/project/code_owners.html</a></li><li><a href="https://metacpan.org/pod/distribution/App-Codeowners/bin/git-codeowners" rel="noreferrer noopener">https://metacpan.org/pod/distribution/App-Codeowners/bin/git-codeowners</a></ul><li>(gibi): the table on the wiki is pretty outdated and also I feel that we not really following the process described on that wiki. So I support rethinking of our bug triage process as whole and automate what we can. But please do not codify the current table in git as that only increase the confusion</li><li><a href="https://wiki.openstack.org/wiki/Nova/BugTriage#Tag_Owner_List" rel="noreferrer noopener">https://wiki.openstack.org/wiki/Nova/BugTriage#Tag_Owner_List</a> this is what i normally look at not the CODEOWNERS</li><li>We already have the MAINTAINERS file pointing to this wikipage <a href="https://github.com/openstack/nova/blob/master/MAINTAINERS" rel="noreferrer noopener">https://github.com/openstack/nova/blob/master/MAINTAINERS</a><ul class="bullet"><li>pointing to <a href="https://wiki.openstack.org/wiki/Nova#Developer_Contacts" rel="noreferrer noopener">https://wiki.openstack.org/wiki/Nova#Developer_Contacts</a></li><li>so that is a thrid location </li><li>deleting really old pages on the wiki is probably another "we should do that eventually" task</ul><li>this too? -<a href="https://wiki.openstack.org/wiki/Nova#Developer_Contacts" rel="noreferrer noopener">https://wiki.openstack.org/wiki/Nova#Developer_Contacts</a></li><li>(gibi): PTL guide can be extended with an extra step to trigger an update of the list at the beginning of every release</li><li><strong>NEXT STEP:</strong><ul class="bullet"><li>lyarwood will propose the initial list in gerrit</li><li>gibi will propose a PTL guide update the list regurarly</ul></li></ul></li></ul><br><ul class="bullet"><li>(stephenfin) Do we still need release candidates?<ul class="bullet"><li>(bauzas) The alternative being <a href="https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary" rel="noreferrer noopener">https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary</a></li><li>I personally tend to give credits to the existing which allows us to focus more on bugs during the RC period</li><li>(gibi): I think cycle-with-intermediary also require a release around RC1 so we would not get rid of the RC<ul class="bullet"><li>(gmann) yeah at least one release for the cycle.</ul><li>(gibi): I like the fact that we feature freeze at M3 and slow down landing code close to RC1. This makes it possible to re-focus my time on bugs and incoming spec reviews instead of the code reviews.</li><li>(gibi): This RC period went pretty smooth, we did not detected any fresh regression that needed imediate action and an RC2. If we can keep this track record then I can be convinced that we can land more code after RC1 but before the relase on master branch.</li><li><strong>AGREED: </strong><ul class="bullet"><li>Keep the current model</li><li>What not to merge to master between RC1 and final release:<ul class="bullet"><li>Massive changes (e.g. refactors) that makes bugfix backporting hard due to conflicts</ul></li></ul></li></ul></li></ul><br><ul class="bullet"><li>(gibi): Placement project is now without PTL<ul class="bullet"><li>projects: placement, osc-placement, os-traits, os-resource-class</li><li><a href="https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml#L2296-L2328" rel="noreferrer noopener">https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml#L2296-L2328</a></li><li>brinzhang volunteerd to take the release liaison role in the DPL process but to make DPL happen we need 2 more volunteers</li><li><a href="http://lists.openstack.org/pipermail/openstack-discuss/2020-October/017927.html" rel="noreferrer noopener">http://lists.openstack.org/pipermail/openstack-discuss/2020-October/017927.html</a><ul class="bullet"><li>what is a TaCT SIG liaison ? Oh, just -infra ? yeah it is infra I think<ul class="bullet"><li>yes. Infra team is converted to this SIG in Ussuri. -<a href="https://review.opendev.org/#/c/721621/" rel="noreferrer noopener">https://review.opendev.org/#/c/721621/</a></ul></li></ul><li>Do we have volunteers? If not, then should we switch back Placement under Nova governance?<ul class="bullet"><li>(gmann) for long term this seems good option otherwise we may end up checking for liaisons every cycle. and we can check if any other release model make tasks easy than current one.</ul><li><strong>AGREED:</strong><ul class="bullet"><li>Keep the gerrit groups separate</li><li>If no volunteers until Friday then we gibi will propose the project change patch and announce it on the ML</ul></li></ul></li></ul><br><ul class="bullet"><li>(bauzas) Deprecate os-hypervisors API<ul class="bullet"><li>Are we on par with osc-placement ?</li><li>What signal do we care for the API deprecation ?</li><li>bauzas to spec up<ul class="bullet"><li>(gibi) There is a related spec form Stephen <a href="https://review.opendev.org/#/c/755109/" rel="noreferrer noopener">https://review.opendev.org/#/c/755109/</a> Add modernize-os-hypervisors-api spec </ul><li>(sean-k-mooney) hyperviors api<ul class="bullet"><li>in most case i think you can get more correct info form placement</li><li>can we deprecate it in W and remove it in X+<ul class="bullet"><li>(stephenfin) +1 to deprecation at least, +0 to removal for now unless it saves us a lot</ul><li>(stephenfin) What are the gaps? What can it give us that placement can't? Can we close those gaps, if any? +1</ul><li>Horizon depends on os-hypervisors to show capacity to the admin<ul class="bullet"><li>cpu, ram, disk without overallocation</li><li>horizon could use the old microversion</ul><li>os-hosts APIs are previously deprecated in favor of os-hypervisors API - <a href="https://github.com/openstack/nova/blob/master/api-ref/source/os-hosts.inc" rel="noreferrer noopener">https://github.com/openstack/nova/blob/master/api-ref/source/os-hosts.inc</a></li><li>The current_workload is the number of tasks the hypervisor is responsible for. This will be equal or greater than the number of active VMs on the system (it can be greater when VMs are being deleted and the hypervisor is still cleaning up).<ul class="bullet"><li>that is what we say in the current api ref</ul><li><strong>AGREED:</strong><ul class="bullet"><li>Sanitize the os-hypervisor API in the proposed microversion</li><li>Add a placement CLI command that list all the info from placement in one shot</ul></li></ul></li></ul><br>*<br>*<strong>Thursday (29th) 13:00 UTC - 15:00 UTC - deprecations</strong><br>*<br><ul class="bullet"><li>(stephenfin) Tech debt/simplification<ul class="bullet"><li>Would like to continue the vein of reducing nova's KLOC because nova has too many dark, rarely explored corners that make things harder to parse, particularly for a smaller maintenance team</ul></li></ul><br><ul class="bullet"><li>(sean-k-mooney) devname support in pci passthough list<ul class="bullet"><li>i wanted to remvoe it in trian but it sill causes issues when you do OS upgrades or firmware updates</li><li>could we deprecate it in W with the replacment bting just usign the pci adress or vendor id/produt id instead.</li><li>devname also only works for nics unlike the other options.</li><li>installer could be extended to translate the devname to the pci adress to provide an upgrade path and they can then support that for as long as they like.</li><li>(stephenfin) I started on this <a href="https://review.opendev.org/#/c/670585/" rel="noreferrer noopener">https://review.opendev.org/#/c/670585/</a> Based on that discussion it seems we should bring this up with deployment frameworks?</li><li><strong>AGREED</strong>:<ul class="bullet"><li>Deprecate devname support with a bugreport and a big warning at nova-compute startup</li><li>Remove the support later</ul></li></ul></li></ul><br><ul class="bullet"><li><s>(stephenfin) DB migrations < Ussuri</s><ul class="bullet"><li><s>These take a not-insignificant amount of time to test and deploy and their presence seems particularly egregious for things we don't even support anymore</s></li><li><s>Removal means folding the individual migrations into the initial migration.</s></li><li><s>Would also allow us to remove a number of nova-manage commands.</s></li><li><s>Can we switch to alembic like everyone else? zzzeek says it's "way better" (TM)</s><ul class="bullet"><li><s>(melwitt): There were discussions in the past around this and reasons not to move to alembic, we need to dig up the history on it to consider in a new discussion.</s><ul class="bullet"><li><s>Nevermind, I couldn't find anything.</s></ul></li></ul></li></ul></li></ul><br><ul class="bullet"><li>(stephenfin) Move to alembic<ul class="bullet"><li>We have limited DB migration to Train and no API DB migrations since Stein (iirc); if we were ever going to do this, now (post-cleanup) would be the time</li><li>Any reason not to, if it wasn't crazy complex?<ul class="bullet"><li>Backports would have to be rewritten, but they're exceptionally rare, particularly when we're not actually making DB changes</ul><li>sqlalchemy-migrate is not maintained. Alembic is maintained.<ul class="bullet"><li>well, <a href="https://opendev.org/x/sqlalchemy-migrate" rel="noreferrer noopener">https://opendev.org/x/sqlalchemy-migrate</a> is around , last patch merged 1 year ago<ul class="bullet"><li>yeah, that's not maintained either :)</ul></li></ul><li>(stephenfin) johnthetubaguy says there might be some issues with online/offline migrations, probably just need to make sure we can add new columns and FKs OK</li><li><strong>AGREED</strong>:<ul class="bullet"><li>make a spec defining the upgrade path from sqlalchemy-migrate to alembic</li><li>stephenfin will do a PoC patch with a complicated migration (index, FK)</ul></li></ul></li></ul><br><ul class="bullet"><li>(stephenfin) Support for schedulers != filter_scheduler<ul class="bullet"><li>We deprecated this support in Ussuri. Would simplify a lot of our code paths if we knew we could rely on placement being present. Will require removing that safe_connect decorator but efried had patches started for this<ul class="bullet"><li>(melwitt): I notice the @safe_connect decorator also swallows ks_exc.ConnectFailure so that's likely one of many reasons it'd be good to remove it.</ul><li>we have required plamcement for nova to function for several releases. the compute agents require it to function now so we can remove the checks from placment even if we allow the schduler to be plugable.</li><li>with that said yes i woudl be +1 on simplicfation</li><li><strong>AGREED:</strong><ul class="bullet"><li>Kill it</ul></li></ul></li></ul><br><ul class="bullet"><li>(stephenfin) Shadow tables+1<ul class="bullet"><li>Does anyone rely on these? Could we make them optional or remove them entirely?</li><li>i woudl really like to see them gone and soft delete in general too.</li><li>(melwitt): FWIW they have helped me identify bugs around archive (example: <a href="https://review.opendev.org/757656)" rel="noreferrer noopener">https://review.opendev.org/757656)</a> so if soft-delete exists, then archive exists, and the shadow tables are helpful in debugging archive issues. So from my perspective, removing them should coincide with removal of soft-delete.+1 i had put soft delete and shadow tables together in my head but i guess they are seperate. i do think soft-delete should be considerd for removal or deprecation too.</li><li>local delete realy on marking something deleted</li><li>archive can be changed to not moving data to the shadow tables but just pruging the deleted rows from the db<ul class="bullet"><li>(melwitt): Can already do this via 'nova-manage db archive_deleted_rows --purge' (though again, it helps me debug when users don't do that ;) )</ul><li>Do see if this make moving to alembic easier</li><li><strong>AGREED:</strong><ul class="bullet"><li>removing the shadow tables needs deployer discussions. Send mail to ML</li><li>rediscuss this at the next PTG</ul></li></ul></li></ul><br><ul class="bullet"><li>(stephenfin) RPC version bump<ul class="bullet"><li>Would allow us to remove a *lot* of hairy, complex code</li><li>Q: Are there disadvantages to this?</ul></li></ul><br><ul class="bullet"><li>(gibi) Remove code that guard against old, not supported compute versions<ul class="bullet"><li>One way is to bump Compute RPC API to 6.0 in Wallaby<ul class="bullet"><li>Was discussed in the Victoria PTG <a href="https://etherpad.opendev.org/p/nova-victoria-ptg" rel="noreferrer noopener">https://etherpad.opendev.org/p/nova-victoria-ptg</a> Line 424</li><li>I had not make much progress during V<ul class="bullet"><li>bauzas can help on writing this up</ul><li><strong>AGREED:</strong><ul class="bullet"><li>we can do it</li><li>bauzas will do it</ul></li></ul><li>Other way is to pervent starting services that are older than nova version N-1<ul class="bullet"><li>Patch is up <a href="https://review.opendev.org/#/c/738482/" rel="noreferrer noopener">https://review.opendev.org/#/c/738482/</a></li><li>This would allow merging a cleanup like <a href="https://review.opendev.org/#/c/735570/" rel="noreferrer noopener">https://review.opendev.org/#/c/735570/</a></li><li><strong>AGREED:</strong><ul class="bullet"><li>Direction is OK</li><li>Backport a version of the patch that _warns_ at compute startup instead of crash<ul class="bullet"><li>(stephenfin) This is similar to the "don't allow live migration with pinned CPUs" change which we also backported</ul><li>Upgrade check to warn if there is N-1 still running</ul></li></ul><li><a href="https://review.opendev.org/#/c/751642/6/nova/virt/libvirt/driver.py@1604" rel="noreferrer noopener">https://review.opendev.org/#/c/751642/6/nova/virt/libvirt/driver.py@1604</a> this is an example of a change that does not change the rpc version but will break n-2 depending on when we delete the fallback</ul></li></ul><br><ul class="bullet"><li>(sean-k-mooney): virtio-memory balloon.<ul class="bullet"><li>nova only uses the virtio memory balloon to collect metric to send to ceilomiter.</li><li>nova/libvirt used to allow turning if off by disabling the memory metrics collection but libvirt started addign the ballon device by default at some point</li><li>can we just remove it entirely or disable it by default and provide a way to opt in.</li><li>keeping it add guest overhead in the form of qemu needing to periodicly update it swith stats on the guest memroy usage.</li><li>nova does not actully configure the ballon to auto deflate on host OOM so it provide no benifit in that edgecase</li><li>to use actul automaitc memory balloning you need to write an external agent to activly mange the guest memory , over used to have once call MOM(memory over commit manger) <a href="https://github.com/oVirt/mom" rel="noreferrer noopener">https://github.com/oVirt/mom</a> </li><li>but that is not actully supported even in ovirt based products so i dont know of any valid usage of the ballon other then for ceilometer metics.</li><li><a href="https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.mem_stats_period_seconds" rel="noreferrer noopener">https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.mem_stats_period_seconds</a></li><li><strong>AGREED:</strong><ul class="bullet"><li>turn virtio-memory balloon off by default, option to turn it on</li><li>when its on, always do auto deflate, to help those wanting to overcommit loads of memory</li><li>DOCS: be clear operators on how to help avoid OOM kill, i.e. have swap</li><li>have a specless bp</ul></li></ul></li></ul><br><ul class="bullet"><li>(stephenfin) Remove the old nova-network-related parameters from various APIs<ul class="bullet"><li>eg. The 'security_groups' field in the 'POST /servers' API (currently a no-op)<ul class="bullet"><li>isnt it used for the default security group of nova created ports ? e.g. if you use --network and nova creates the ports.<ul class="bullet"><li>(stephenfin) Nope, we validate in the API, build up security group objects...and then ignore it entirely if using neutron.<ul class="bullet"><li><a href="https://github.com/openstack/nova/blob/3dbb6c18a58ce42ea515b8ca71e69b0b438ef268/nova/compute/api.py#L430-L450" rel="noreferrer noopener">https://github.com/openstack/nova/blob/3dbb6c18a58ce42ea515b8ca71e69b0b438ef268/nova/compute/api.py#L430-L450</a><ul class="bullet"><li><a href="https://github.com/openstack/nova/blob/3dbb6c18a58ce42ea515b8ca71e69b0b438ef268/nova/network/security_group_api.py#L55-L78" rel="noreferrer noopener">https://github.com/openstack/nova/blob/3dbb6c18a58ce42ea515b8ca71e69b0b438ef268/nova/network/security_group_api.py#L55-L78</a></ul><li><a href="https://github.com/openstack/nova/blob/3dbb6c18a58ce42ea515b8ca71e69b0b438ef268/nova/compute/api.py#L1925-L1928" rel="noreferrer noopener">https://github.com/openstack/nova/blob/3dbb6c18a58ce42ea515b8ca71e69b0b438ef268/nova/compute/api.py#L1925-L1928</a></li><li>(gmann) yes, it query neutron for requested sec group but do not use that at all. cannot trace it now in code, but need to check and test.</li><li>i dont think we ever docuemnted that</li><li>(stephenfin) Actually, I'm not certain that this is the case after all. amotoki suggests otherwise <a href="https://review.opendev.org/#/c/757581/2/openstackclient/compute/v2/server.py@650" rel="noreferrer noopener">https://review.opendev.org/#/c/757581/2/openstackclient/compute/v2/server.py@650</a></li><li>(johnthetubaguy) Prettry sure I use that and it worked, or really I mean I think horizon does :/</ul></li></ul></li></ul><li><strong>AGREED:</strong><ul class="bullet"><li>nothing to remove now</li><li>re-discuss it when new items collected for removal</ul></li></ul></li></ul><br><ul class="bullet"><li>(gmann): Deprecation warnings for Policy<ul class="bullet"><li><a href="https://bugs.launchpad.net/nova/+bug/1900451" rel="noreferrer noopener">https://bugs.launchpad.net/nova/+bug/1900451</a></li><li>We have disabled the policy warnings for default value changed - <a href="https://github.com/openstack/nova/blob/a83001a903c50143afe2957be6ca72a6e3b884f5/nova/policy.py#L106-L112" rel="noreferrer noopener">https://github.com/openstack/nova/blob/a83001a903c50143afe2957be6ca72a6e3b884f5/nova/policy.py#L106-L112</a></li><li>But other policy warning for name change etc are not disabled by default. It is disabled for tests where each test initialize the policy.</li><li>Also scope_types warnings are logged if enforce_scope is not enabled and resigtered rule is scoped. </li><li>should we disable it all by default for nova-manage or where ever policy can be initialized in nova code? +1</li><li>or keep it enabled but switchable via config option?</li><li><a href="https://github.com/openstack/nova/blob/master/nova/config.py#L35-L54" rel="noreferrer noopener">https://github.com/openstack/nova/blob/master/nova/config.py#L35-L54</a> could wirte filter(drop them) or transform (change level)</li><li><strong>AGREED:</strong><ul class="bullet"><li>do not emit these messages until the deployer can do something about them</li><li>this is a code impact on oslo.policy</ul></li></ul></li></ul><br><br>*<strong>Any other business</strong><br><br><ul class="bullet"><li>(tbarron/gouthamr/manila contributors) VirtIO-FS <ul class="bullet"><li>Please consider scheduling this on <strong>Thursday</strong>(15:00-17:00 UTC) since the rest of the times coincide with openstack manila PTG discussions :)</li><li>Feature: <a href="https://virtio-fs.gitlab.io/" rel="noreferrer noopener">https://virtio-fs.gitlab.io/</a></li><li>Concept: Looking to discuss the possibility of exposing shared directories to VMs with the nova team </li><li>startup etherpad: <a href="https://etherpad.opendev.org/p/nova-manila-virtio-fs-support-vptg-october-2020" rel="noreferrer noopener">https://etherpad.opendev.org/p/nova-manila-virtio-fs-support-vptg-october-2020</a></li><li>demo of manual remote mount to staging dir on fedora33 host and exposing to alpine guest via virtiofs: <a href="https://asciinema.org/a/IZ7UrhwspxBN63XsOl9JrTcUX?speed=1.5" rel="noreferrer noopener">https://asciinema.org/a/IZ7UrhwspxBN63XsOl9JrTcUX?speed=1.5</a></li><li>johnthetubaguy: I remember we deffered this in the past, but I think its because vsock wasn't ready/stable. I like this more than I used to, now I have an HPC hat. Currently I get around not having this by telling people to use K8s, but the networking is *hard* and partly broken really (for the CephFS case). Basically I like this so I don't have to push CephFS through neutron routers.</li><li>johnthetubaguy: I think this has to be a separate kind of attachment to Cinder, but "similar", its an FS not a block<ul class="bullet"><li>(sean-k-mooney): yes i discussed this with tbarron a littel on irc before and the idea was to have a share attach/detach like cinder but for manila shares host mounting the shares and exposing them to the guest via virtio-fs +1, I think we almost agreed on this direction before? maybe :)</li><li>one advantage to this approch is that the guest now would have an abstration over the backend sotarge layer. e.g. nfs or cephfs are normaliased to virtio-fs in teh guest allowing windows to use both as it just looks liek a virtio-fs share. Right, guest doesn't need to know about remote FS protocols, install client packages, get auth keys, etc.<ul class="bullet"><li>yeah, I need this for Lustre really, as that is even more terrible with version problems</ul><li>cloud-provider openstack could support this new approach<ul class="bullet"><li>yeah, we have manila-csi in CPO now and would extend it and make sure that attaching shares works in that context. CPO will basically just call into OpenStack services but will be an important use case to be accomodated in new APIs.</ul></li></ul><li>supperted since QEMU 5.0, and libvirt 6.2. Nova's next min is QEMU 4.2, libvirt 6.0.0<ul class="bullet"><li>UCA support ?<ul class="bullet"><li>not currently we the victoia branch just has the 20.04 version we would need 20.10's packages</li><li>we can use fedora 33 if we needed</li><li>we only need the newer libvirt the qemu version will be fine on 20.04</li><li>i coudl update <a href="https://opendev.org/x/devstack-plugin-libvirt-qemu/src/branch/master/devstack" rel="noreferrer noopener">https://opendev.org/x/devstack-plugin-libvirt-qemu/src/branch/master/devstack</a> to provide this too. it comples libvirt and qemu form source but i have not updated in a year or two so need to add 20.04 support.</ul><li>apparently alpine can be a possible guest in the gate where this works<ul class="bullet"><li>well we dont have that in the gate yet but its a topic that came up with opendev</li><li><a href="https://review.opendev.org/#/q/status:open+project:openstack/diskimage-builder+branch:master+topic:alpine" rel="noreferrer noopener">https://review.opendev.org/#/q/status:open+project:openstack/diskimage-builder+branch:master+topic:alpine</a></li><li>i started trying to add alpine supprot to diskimage-builder the only issue i have right now it getting the initramfs to work but i might try rebasing it to the iso instead fo the chroot tar to see if that fixes it.</li><li>note that using alpine is just to get a new kernel in the guest but alpine is very small and well mainatined.</li><li>FWIW for my alpine quest I just downloaded the latest ISO from <a href="https://alpinelinux.org/downloads" rel="noreferrer noopener">https://alpinelinux.org/downloads</a> and followed <a href="https://wiki.alpinelinux.org/wiki/Qemu" rel="noreferrer noopener">https://wiki.alpinelinux.org/wiki/Qemu</a> to make a qcow2, then virt-install, virsh-edit, etc.</ul></li></ul><li>Claims performance is good now, and I think we tested this for kata: <a href="https://www.stackhpc.com/images/IO-Performance-of-Kata-Containers-TheNewStack.pdf" rel="noreferrer noopener">https://www.stackhpc.com/images/IO-Performance-of-Kata-Containers-TheNewStack.pdf</a></li><li>We are mostly discussing on having another full API support exactly like we have with BDMs plus a new os-something library as a common lib between Manila and us. That's a massive effort, we absolutely need testing and baby steps.+1+1+1</li><li>How to stage the addition of this, so we make progress?<ul class="bullet"><li>API: we can first add adding a share to a running VM, but second thing, changing the create server API?<ul class="bullet"><li>Params:<ul class="bullet"><li>tag</li><li>manilla share uuid</li><li>read vs readwrite</ul><li>key initial bits are ensure we add the tag in metadata</li><li>... but we add the API last</li><li>add simple API first</ul><li>Q:os-brick style attachment<ul class="bullet"><li>is there an agent on the hypervisor or not?</li><li>NOTE: we can only depend on released libs!</li><li>ganesha nfs in manila does bits of this</li><li>ACTION: agree details in spec</ul><li>API in manila that Nova talks to to get the attachment details<ul class="bullet"><li>is there anything new we need? Maybe not I guess?</li><li>Ideally something the os-brick style replacement can deal with</ul><li>Q: how much does "nova" have to do, vs os-brick like thing, vs libvirt<ul class="bullet"><li>system calls for running the virtio-fsd agent, who would be responsible of them ?<ul class="bullet"><li>lyarwood: I was about to ask this earlier, FWIW it isn't listed in the libvirt docs as something the caller would worry about.<ul class="bullet"><li><a href="https://libvirt.org/kbase/virtiofs.html" rel="noreferrer noopener">https://libvirt.org/kbase/virtiofs.html</a></ul></li></ul></li></ul><li>Testability<ul class="bullet"><li>needs to run in the gate.. seems possible</ul><li>Upgrades<ul class="bullet"><li>Should we wait for the whole cloud to be up to date ?</li><li>yes, usual service version checks for this one</ul><li>johnthetubaguy:<ul class="bullet"><li>I should say, this excites me, I will see if we can work on it from StackHPC, but likely my time to help review it is the most I offer right now</li><li>... I want to add lustre support using this, medium term, not got anyone to pay us to do that yet+1</ul></li></ul><li><strong>AGREED</strong><ul class="bullet"><li>its in scope, its a new API for attaching a share to a running VM<ul class="bullet"><li>Do the POST /servers API extension later</ul><li>you can find shares via tags</li><li>share concepts with volume mount.. but not we hate loads of that :)</li><li>it is a multi cycle work</li><li>First spec deals with a bite size step forward, proposed usecase being a fs attach/detach to a running instance</ul></li></ul></li></ul><br><ul class="bullet"><li>(gmann) Allow system admin to create server for other projects<ul class="bullet"><li>Context: With API new policy and scope_type, many API operation became system scoped like hypervisor info, host info etc.<ul class="bullet"><li>Create server is project level API and default policy is PROJECT_MEMBER and in code, request context's project_id is used to create server for.<ul class="bullet"><li><a href="https://github.com/openstack/nova/blob/7dcc4cfea7da2ef1163e0a65618cb784f5159c6d/nova/compute/api.py#L1055" rel="noreferrer noopener">https://github.com/openstack/nova/blob/7dcc4cfea7da2ef1163e0a65618cb784f5159c6d/nova/compute/api.py#L1055</a></ul><li>But in create server request we do have some system level request parameter like force server on particular hosta nd that is controlled by separate policy 'os_compute_api:servers:create:forced_host'</ul></li></ul></li></ul><ul class="indent"><li><ul class="indent"><li><ul class="indent"><li><ul class="indent"><li>- <a href="https://opendev.org/openstack/nova/src/commit/a83001a903c50143afe2957be6ca72a6e3b884f5/nova/policies/servers.py#L179" rel="noreferrer noopener">https://opendev.org/openstack/nova/src/commit/a83001a903c50143afe2957be6ca72a6e3b884f5/nova/policies/servers.py#L179</a></ul></li></ul></li></ul></li></ul><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li>Other example than force_host are creating server with zero disk flavor, attach the external networks, request destination.</ul><li> which is default to PROJECT_ADMIN for now because there is no way for system level users to create server request ( TODO in above link ^^)</ul><li>To allow system level roles to request to create server for other projects with system level request parameter, we need to allow project_id as one of the request parameter<ul class="bullet"><li>(melwitt): Just an idle comment, disappointed to know we need this ... I had thought that scope types would work in combination with the credential project/user so that we still use the project_id and user_id from the RequestContext like we normally do.<ul class="bullet"><li>Yeah with access control (say to allow server with zero disk flavor) it works but for things like force_host they need to get host info and pass in request.<ul class="bullet"><li>Yeah when I first commented I didn't realize it was just for getting host info via a separate API. it makes sense to me (and I thought it was intended) that if a user needs to do this it is expected that they have the appropriate role (and use system token) to query for the host list and then when they want to boot the server, they do that with a project scoped token. IMHO it feels like it's working as intended today.<ul class="bullet"><li>For this special case yes but if we want to have a complete isloation between system level token and project level then it does not. Means a single user need to have system level token to perform project level operation which they can use to get other project info :)<ul class="bullet"><li>Right, I honestly thought that was the point of all of the policy and scope types work, to carve up the API permissions/access to need system or project token, then the appropriate roles. And that lumping them together was the old way and what we were trying to get away from. Just my perspective. Like johnthetubaguy said, we "could" do it but it can get confusing in a similar way it was confusing with the legacy admin model. And I'm not sure it's a good idea.</ul></li></ul></li></ul></li></ul></li></ul><li>and API will create server for requested project_id if any instead of contextproject_id, if no project_id is requested then use context's project_id like it is currently.<ul class="bullet"><li>Or make project_id mandatory in request body so that each user need to explicitly mentioned the project they want to create server for even it is their own project itself ?</ul><li>This way we can make 'os_compute_api:servers:create:forced_host' policy to be default to system_admin. Eek. We should rather kill this horrible hack. Its super needed :'( I know, that's the difference between a wish and the reality. Oh, just tbc, I was speaking of the semantics with the AZ field that is hacky, not the fact to ask for a target if you're admin, which sounds a reasonable usecase.true, the az syntax is mad.</li><li>This change need microversion as we need to modify the request body.</li><li>neutron advanced thing <a href="https://github.com/openstack/neutron/blob/master/neutron/policy.py#L43" rel="noreferrer noopener">https://github.com/openstack/neutron/blob/master/neutron/policy.py#L43</a> "context_is_advsvc"</li><li>slightly wacky idea is that if you use tenant isolation with aggreate and you are a project amin you could list the host for your project only as a project admin.</li><li>in general however i dont think project admins shoudl be able to list hosts.</li><li>(melwitt): (after the discussion) it seems to me that the way it works today is the model we were trying to get to with the policy changes and scope types, that you need to request the appropriate token per API to carry out the actions you need and that you need to be given appropriate roles along with that. If we start rolling things together, wouldn't that put us backward more toward what we originally had with the global admin concept?</li><li><strong>AGREED:</strong><ul class="bullet"><li>Document it better how to do the above use case today.</li><li>Gather information from the users of the new policy system and rediscuss this use case based on that</ul></li></ul></li></ul><br><ul class="bullet"><li>(lyarwood) Image and flavor defined ephemeral storage encryption<ul class="bullet"><li><ul class="bullet"><li><a href="https://review.opendev.org/#/c/752284/" rel="noreferrer noopener">https://review.opendev.org/#/c/752284/</a><ul class="bullet"><li>tl;dr Introduce image properties, flavor extra_specs and configurables to bring Nova's ephemeral storage encryption in-line with the UX of Cinder's volume encryption using encrypted volume types.<ul class="bullet"><li><a href="https://docs.openstack.org/cinder/latest/configuration/block-storage/volume-encryption.html" rel="noreferrer noopener">https://docs.openstack.org/cinder/latest/configuration/block-storage/volume-encryption.html</a></ul><li>The spec also suggests the use of compute traits and a pre-filter when initially scheduling instances.</li><li>The alternative or possible followup in a future release would be to expand the block_device_mapping_v2 API to handle this directly instead.</li><li>The libvirt virt driver implementation will need an additional spec, I'm currently blocked on some internal debt around we transform API bdms into BlockDeviceMappings into driver BDMs before finally into block_info within the driver.</li><li>Open Questions:<ul class="bullet"><li>Does this require a microversion to indicate support for the new flavors and extra specs? I'm assuming yes as was the case with BFV rescue etc.</li><li>Was that to just advertise its available, not restrict its use?</li><li>normally we dont bump microversion for extra specs or image properties so i would assume no+1+1</ul><li>Enabled / Disabled config, but only works with LVM<ul class="bullet"><li>flavor: explicitly enable or disable?</ul><li><a href="https://github.com/openstack/nova/blob/master/nova/compute/api.py#L585-L609" rel="noreferrer noopener">https://github.com/openstack/nova/blob/master/nova/compute/api.py#L585-L609</a> we do the validate in _validate_flavor_image_nostatus</li><li>Idea: metadata report if you disks are encrypted or not</li><li>(Luzi) There is currently ongoing work for Image encryption in Glance, they do have some encryption metadata: <a href="https://specs.openstack.org/openstack/cinder-specs/specs/wallaby/image-encryption.html#proposed-change" rel="noreferrer noopener">https://specs.openstack.org/openstack/cinder-specs/specs/wallaby/image-encryption.html#proposed-change</a></li><li><strong>AGREED</strong>:<ul class="bullet"><li>No microversion bump is needed<ul class="bullet"><li>but a validator should be added to 'nova.api.validation.extra_specs.hw'</ul><li>add encryption to metadata for ephemeral disks so users can confirm if their disks are actually encrypted at rest.<ul class="bullet"><li>I assume we should also do this for encrypted volumes as well?+1</li><li>you can look at the Image encryption in Glance for an example</ul><li>Deprecate the old config param</ul></li></ul></li></ul></li></ul></li></ul><br><ul class="bullet"><li>(lyarwood) Device detach improvements<ul class="bullet"><li>(gibi): Do we talk about both volume and interface detach?<ul class="bullet"><li>(lyarwood): Yes this would cover both disks and interfaces.</ul><li>API<ul class="bullet"><li>Reject requests to detach devices from instances on down computes<ul class="bullet"><li>Recent examples of async (cast) APIs that have started to do this</li><li>johnthetubaguy: should we do this for all operations, similar to the task check decorator we have?<ul class="bullet"><li>Except delete<ul class="bullet"><li>(melwitt): +1, and we "guarantee" we will delete it later via the periodic reap task in nova-compute so from a general perspective we are accurately deleting async as communicated to the user via the 204</li><li>history: I think this is because people should avoid getting billed for things they don't want, regardless of if its possible to complete the request right away<ul class="bullet"><li>Yeah, totally agree delete should never be blocked (for many reasons).+1</ul></li></ul></li></ul><li><strong>AGREED</strong>:<ul class="bullet"><li>reject the operation with a vague error message to prevent a leak</ul></li></ul><li>For volumes introduce a force-detach admin only action to allow operators to detach volumes from down computes<ul class="bullet"><li>Call c-api to delete the attachment moving the volume to available</li><li><strong>AGREED:</strong><ul class="bullet"><li>do it</ul></li></ul></li></ul><li>libvirt<ul class="bullet"><li>Switch to using libvirt events<ul class="bullet"><li>(lyarwood) Nope, I'm talking about actual libvirt events for device detach, this isn't related to block jobs and their associated QEMU events that n-cpu shouldn't be waiting on either IMHO. We should only care about events directly from libvirt. — ah-ha, okay, separate topic - the below QEMU BLOCK_ events thing; I left it for the record)<ul class="bullet"><li>Specifically the following device detached events from libvirt:<ul class="bullet"><li>VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED</li><li>VIR_DOMAIN_EVENT_ID_DEVICE_REMOVAL_FAILED<- retry only on failed</li><li><a href="https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainEventID" rel="noreferrer noopener">https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainEventID</a></ul><li>WIP code I posted during the Focal detach issue <a href="https://review.opendev.org/#/c/749929/" rel="noreferrer noopener">https://review.opendev.org/#/c/749929/</a> this just wires up some logging of the events.</li><li>The idea here would be to remove the retry loops that hit the undefined QEMU behaviour when we send overlapping requeststo detach.</ul><li><strong>AGREED:</strong><ul class="bullet"><li>do it</ul><li>[SKIP - not for Wallaby] (kashyapc) - the below QEMU events are a separate topic to Lee's "libvirt events"; leaving the below here for the record — I'll file a separate Blueprint for the record<ul class="bullet"><li><s>tl;dr -- Switching to these "events" are largely to avoid race conditions for long-running block device operations like blockCopy(), blockCommit(), etc that Nova runs into sometimes</s></li><li><s>Some available events to 'listen for': BLOCK_IO_ERROR; BLOCK_JOB_{CANCELLED, COMPLETED, ERROR, READY}</s></li><li><s>Note: Switching to this event infrastructure may involve non-trivial reworking of existing code might be required, brand new unit tests, and probably more. But it solves some flaky race condition problems</s></li><li><s>Additional info: for others normally don't dwell in this area. FWIW, in the past I did a small "dissection" of where these events come into picture while debugging a Gate problem: </s><a href="http://lists.openstack.org/pipermail/openstack-dev/2016-October/105158.html" rel="noreferrer noopener"><s>http://lists.openstack.org/pipermail/openstack-dev/2016-October/105158.html</s></a></ul></li></ul></li></ul></li></ul></li></ul><br>*We stopped here on Thursday<br><br><ul class="bullet"><li>(sean-k-mooney): add a server recreate API<ul class="bullet"><li>Example:<ul class="bullet"><li>openstack server recreate --image <image-id> --flavor <flavor-id> <server></ul><li>recreate is a data and port/resouce preserving move opertion by default</li><li>image and flavor would be optional</li><li>if neither image or flavor are passed then recreate consults the schduler for a new host that is compatiable with the latest state fo the image metadta and flavor extra specs instead of the embeded copy<ul class="bullet"><li><s>so this is a cold migrate </s>the new thing is updating the image metadata if that was updated since the boot</ul><li>if image is passed recreate is a rebuild that is allowed to change resouce useage/numa toplogy since it is a move operations and can/likely will change host.<ul class="bullet"><li>this is a new case</ul><li>if flavor is passed recreate is a resize that auto confrims. <ul class="bullet"><li>this is negotiably but i think we sho<s>the</s>uld not have to manually confirm resizes or migration today so i would prefer not to intoduce that requirement to recreate</li><li>i would prefer to eventully remove resize verify and explict confrim/revert form the other apis but that is out of scope. it is the reason why i would prefer this api to work like rebuild, live-migrate and shelve however rather then emulate resize.</li><li>This can be closely emulated today by setting resize_confirm_window to a small positive number</ul><li>if both flavor and image are passed, this action recreates the server by reusign its volums and port etc but remiaging the root disk and updating the flavor as a singel atomic operation<ul class="bullet"><li>currently this requires stoping the vm, then rebuilding and then resizing before starting it again.</li><li>this is useful for cloud instances that use rebuild for upgrades where the resouce requirements of the updated stateless application differ form n to n+1</li><li>this is an edge case that customers have encountered and providing a single atomic operation would simplify there workflow.</ul><li>recreate could support shelved instances<ul class="bullet"><li>i think resize should support shelved instnace today as resize a shelved instance is jsut confirming its new flavor is compatiable with the image end the updating the flavor in the db.</li><li>the new flaovr will take effect when the instance is unshleved.</li><li>this allow upgrading fo shelved isntance to new flaovrs if operators want to discontinue an old flaovr without</li><li>this could be defered to a follow up that adds supprot for shelved instance to resize and recreate.</ul><li>(melwitt): Any reason not to do this as 'openstack server rebuild --keep-ports-and-volumes'? Maybe it's just me but that would feel more intuitive.<ul class="bullet"><li>yes i want this to be able to change host so that the requirement in the image can change rebuild are always to the same host they are not move operations.</li><li>also we want to be able to change the image and flavor at teh same time in one operation</li><li>(melwitt): Gah, sorry, I meant resize. But noted on wanting to change image and flavor at the same time :/</ul><li>(johnthetubaguy): Is this really resize with --rebuild <image-id>?<ul class="bullet"><li>It feels close to what we said about "no more orchestration" APIs +1 as far as I see a heat template can automate the stop + rebuild + resize + confirm + start process+1</li><li>New Resize API microversion idea:<ul class="bullet"><li>get rid of confirm resize / revert resize, or default to auto confirm resize+1</li><li>-- flavor to the same flavor, allow that if extra specs have changed, or maybe allow always+1</li><li>shelve offloaded, allow resize, in the new microversion, disaalow auto confirm resize</li><li>-- image addition, so you can avoid copying the disk during resize-1 from me (bauzas)... if this work with volumes</ul></li></ul><li><strong>AGREED:</strong><ul class="bullet"><li>new microversion <ul class="bullet"><li>auto confirming resize by default</li><li>allow resizing to the same flavor to update extra_spec</li><li>allow resizing shelve offloaded instances</ul><li>wait for the rebuild of bvf solution before we do the --image part</ul></li></ul></li></ul><br><ul class="bullet"><li>(stephenfin) NUMA in placement <ul class="bullet"><li>This is clearly a hard job thing to do. Given reduced resources, is it still a thing we care about?<ul class="bullet"><li>(alex_xu) probably left a lot of feature can't do numa affnity, vpmem, gpu, cyborg devices<ul class="bullet"><li>is it ok to continue using the existing host numa object to do the numa affinity?</ul></li></ul><li>What is it blocking? What does it give us besides warm fuzzy feelings?<ul class="bullet"><li>(melwitt): Existing NUMA and affinity claiming processes race and cause reschedule cascades + NoValidHost. It would be best to solve this (do the right thing: in placement), else customers continue to suffer with it.+100</li><li>(sean-k-mooney): we can also solve this without placment, we just need to create the claim in the resouce tracker on the host i the conductor/scduler. we have never need placment to fix that.<ul class="bullet"><li>(melwitt): So what would that look like? "If NUMA, do a two-phase commit style claim on resource tracker, else claim in placement"? (That's beside the fact that placement was created to perform all the placement things).</li><li>(sean-k-mooney): in the conductor/schduler where we currently do the placement allocation claim we would make a call to the compute node to claim the resouce in the resouce tracker similar to a move claim for cold migration if that succeeds then we proceed with that host if not we free the placement allocation and go to the next alternate host and repeat. this is the same solution we proposed before placment was created and its still equally valid today.</li><li>(melwitt): Sorry, I don't see how adding a second way of "claims in the scheduler" is valid after we chose to do it in placement after a lot of discussion. To elaborate (since this discussion will likely be before I come online in my time zone), I feel like we did a whole lot of work to get placement going and do claims in placement. And now it feels like we're saying, freeze placement and add another way to do a claim in the scheduler, and do all the things without placement going forward. It is a thing we could do, but I'm not sure "valid" is the best word.</li><li>I like a two-phase commit solution for things like server group affinitiy / anti-affinity. That stuff really sucks in a similar way. There is always a point where the hypervisor has to reject something... maybe we just draw the line at NUMA for now? Seems a shame though :'(</ul></li></ul><li>(gibi): For me it feels like we have a wish and a dream to do NUMA in placement but we don't have a the human resources to make it happen. Do we have developers who will spend time on implementing the necessary changes? If yes, then it make sense to agree on those changes.<ul class="bullet"><li>(sean-k-mooney): i agree with both points we do really want to do numa in placmeent but wallaby will be the base of our next lts downstream product and they are pushing to land as many feature that we can that are user visable since it will be 3 more release before our next lts based on Z e.g anything that is not in Wallaby will not be availabel to customer until Z is released in our downstream product modulo some very small and few feature backprots. from an enginerring point of view this is still a high priority but from a pm point of view its not. the flip side of this is we have been saying let wait for placment to have support for this for 3 years now it predates the creation of placement and its why nested resouce providers was added. placement now has support for nested resource providers but i dont this is somethign we coudl have delivered years ago and i dont think its resonable to keep defering this just because we dont do it in placment. we will eventrually do it in placment but it will be hard to justify working on this in wallaby form a redhat point of view.</li><li>(melwitt): I know this is going to be an unpopular opinion, but I feel like at some point, we do need to learn how to develop in placement being that critical functions we depend on are in it. From my perspective, I think of it as though part of nova is in placement and it feels like we keep pushing it off to learn to develop in it. Are we thinking of effectively freezing placement except for bug fixes from now on?<ul class="bullet"><li>+1 melwitt here. Could I turn this upsdie down though... can we think of a easier way of doing this that involves breaking some "rules".</li><li>(gibi): I don't think that the real blocking issues is that we don't know placement internals. I think we in general lack of developers who dedicate time to make the necessary code changes happen. I totally agree that it would be good to have NUMA in placement. <ul class="bullet"><li>(melwitt): Not sure I understand this, the developers would and should be the devs working on this feature right (i.e. there are devs who dedicate time to work on the feature)</ul></li></ul></li></ul><li><s>Stupid question, is there an easier but non-pefect path forward?</s><ul class="bullet"><li><s>Step1: if we agree a design, we have the option of asking for help for people to follow the spec and implement it</s></li><li><s>i.e. what about every nova compute reporting a hypervisor for every NUMA node, a bit like ironic-compute reporting lots of ironic nodes?</s><ul class="bullet"><li><s>this breaks targeting a specific hypervisor, but whatever, you just target a specific NUMA node now.</s></ul><li><s>for a new hypervisor, or a hypervisor that is empty (has had all its VM live-migrated off it), we "just" need to start reporting two sets of resources</s></li><li><s>we make it opt in, a bit like opting into doing pCPU vs vCPU</s></li><li><s>... I presume the hard bit is transitioning... is there a way to make the feasible if we break a few rules/guidelines? like only allowing empty hypervisors to move from a NUMA reporting system to non-NUMA reporting system?</s></li><li><s>.. maybe this is stupid.</s></ul><li>Context : <a href="https://specs.openstack.org/openstack/nova-specs/specs/victoria/approved/numa-topology-with-rps.html" rel="noreferrer noopener">https://specs.openstack.org/openstack/nova-specs/specs/victoria/approved/numa-topology-with-rps.html</a></li><li><strong>AGREED:</strong><ul class="bullet"><li>Implementing the two phase commit is less complex than modeling NUMA in placement and both could stop the race condition on resource claim</li><li>move the current NUMA in placement spec to backlog</li><li>stephenfin will propose a spec about two phase commit</li><li>we only approve the spec if the PoC code is proposed</ul></li></ul></li></ul><br><ul class="bullet"><li><ul class="bullet"><li>(sean-k-mooney): socket affinity as a new numa afinity policy for devices or memroy.<ul class="bullet"><li>because of the sub numa stuff? bummer.</li><li>ya basically as a simpler alternitive to doing numa distance modeling. just to affintiy to any numa node on the same socket</li><li>numa distance is better but might be more complex</li><li>this is important for cluster on die/subnuma clustering on intel cpus or amd zen cpus include zen2 and zen3</li><li>AGREED:<ul class="bullet"><li>more discussion needed in an additional spec</ul></li></ul><li></li><li>(sean-k-mooney): numa blancing <a href="https://bugs.launchpad.net/nova/+bug/1893121" rel="noreferrer noopener">https://bugs.launchpad.net/nova/+bug/1893121</a><ul class="bullet"><li>this was disccused when we first added numa support but was orignally declared out of scope.</li><li>today we deterministicly order the numa nodes and iterate over them using itertools permutaions.</li><li>we have a minor optimistaion to avoid numa nodes with pci devices if you do not request one by sorting the list before passing it to permutations</li><li>we should do the opisite if you reqeust a pci device but dont today<ul class="bullet"><li>this means that if you have a pci device on numa node 1 and the prefer pci affinity policy and hw:numa_nodes=1, then if the vm can fit on numa node 0 we will select it instead of numa node 1 even though we said to prefrer numa affinity since we bail out of the function when the first numa node matches.</ul><li>ideally we would also sort on other factors too </li><li>since python support stable sort orders complex sort can be achcive by multiple stables sorts <a href="https://docs.python.org/3/howto/sorting.html#sort-stability-and-complex-sorts" rel="noreferrer noopener">https://docs.python.org/3/howto/sorting.html#sort-stability-and-complex-sorts</a></li><li>so we can support numa blancing by doing the following sorts fo the numa node.<ul class="bullet"><li>first sorting by instance per numa node</li><li>then sorting by free memory per numa node</li><li>then by cpus per numa node and finally</li><li>by pci device per numa node.</ul><li>i belive this is a bug that should be adress and backported to all maintianed release. if we do numa in plamcnet providign this functionality is fundemtally achived by sorting the allcoation candiates instead of sorting the numa nodes in the hardware module. if we dont adress this before we add numa to placment then we cant eaissly adress this for exsiting releases. if we consider this a feature not a significant performance bug then it can be adreessed with or without numa in plamcnet.</li><li>a similar bug has since been filed indepently <a href="https://bugs.launchpad.net/nova/+bug/1901371" rel="noreferrer noopener">https://bugs.launchpad.net/nova/+bug/1901371</a> which i have marked as a duplicate of <a href="https://bugs.launchpad.net/nova/+bug/1893121" rel="noreferrer noopener">https://bugs.launchpad.net/nova/+bug/1893121</a></li><li><strong>AGREED:</strong><ul class="bullet"><li>sean-k-mooney will propose patch for this</li><li>have a spec and debate there about the need for a config that allow packing / spreading on NUMA level</ul></li></ul></li></ul></li></ul><br><ul class="bullet"><li><ul class="bullet"><li>(sean-k-mooney): related topic: default numa instance to hw:mem_page_size=any<ul class="bullet"><li>we basically need to do this if we track mempages in placment and we cant track numa in placment usefully if we dont do that.</li><li>we have had several customs and uptream threads related to OOM issues when using numa instnaces.</li><li>experince has shown that users do not understand how to configure numa related feature correctly.</li><li>unless you set hw:numa_nodes=<number of nodes on a host> there is currently non valid way to define a numa instance without setting hw:mem_page_size to a vaild value.</li><li>setting hw:mem_page_size or the image property hw_mem_page_size enable per numa memroy tracking</li><li>without it we pin the instance to a host numa node without checking the free capsity of that node or claiming the memory.</li><li>the vm will not be able to use memroy form other nodes and if you just use hw:numa_nodes=1 we will pin all instance to numa 0 and never use numa 1+</li><li>hw:mem_page_size=any mean use small pages not hugepages but allow the image to request a different page size. this i is the same beahvior as not setting the value in the flavor except<ul class="bullet"><li>memory is tracked and claimed in the numa toplogy blob allowign instance to use all numa nodes on the host.</li><li>OOM issue will be prevented as memory will be claimed and host will not be selected if there is not enough memroy.</li><li>oversubsriptiuon will be disabled for all numa instance<ul class="bullet"><li>note the only way to use oversubstiption + numa today is if you only set hw:numa_nodes without cpu pinning or explcit page size requests</li><li>this is only valid if you set hw:numa_nodes=<number of host numa nodes> since we dont enable per numa memory trackign so over subsription will only "work" if the instance can use memory from all numa nodes</ul></li></ul><li><strong>AGREED</strong><ul class="bullet"><li>Treat this as a bugfix with a fat releasenote describing the behavior change</ul></li></ul></li></ul></li></ul><br><br><br><ul class="bullet"><li>(lyarwood) Removing the use of persistent domains in the libvirt driver +1<ul class="bullet"><li>(lyarwood) We can skip this unless someone else wants to take it as I'm already fully loaded for the cycle.</li><li>(stephenfin) Could you say why we do this at the moment and what the implications are? I'm not sure<ul class="bullet"><li>i belive we do this today because its teh default way to interact with libvirt via persistnt domains. </li><li>with that said we have never used them the way that libvirt intended them to be used. persitent domains are intended to be used when you dont delete them every time you start a instance to provide stable device names and other things</li><li>nova thows away the domain every time we start an instance so it provide no benifit to use at all and encurages peopel to do bad things like modify the domain behind nova's back.</ul><li>(stephenfin) On this note, should we be more explicit about adding things that we get automatically on x86 (keyboard, mouse, ...). Translation: do we care about ARM?<ul class="bullet"><li>yes i think so. ideally i think we should not be using libvirt to automagically add anythign for us and only adding what we require or are asked to add. +1 for being explicit, it causes lots of bugs/CVEs.. I wish we could tell libvirt we only want what we ask for?</li><li>(kashyapc) <ul class="bullet"><li>On Arm, if we can get support for it without extreme effort, let's not lose that</li><li>Also, some (incomplete) notes on input devices for different architectures: <a href="https://kashyapc.fedorapeople.org/Input-devices-in-QEMU.txt" rel="noreferrer noopener">https://kashyapc.fedorapeople.org/Input-devices-in-QEMU.txt</a></ul></li></ul><li><strong>AGREED:</strong><ul class="bullet"><li>direction is OK</li><li>we don't have bandwidth right now to work on it. If you are interested please ping lyarwood on IRC</li><li>lyarwood to raise this in the libvirt group etherpad and mailing list.</ul></li></ul></li></ul><br><ul class="bullet"><li>(bauzas) Beware of the potential goals, one being python-novaclient being dropped in favor of OSC<ul class="bullet"><li>The above line is subject to change given the output of the goals conversation <a href="http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017459.html" rel="noreferrer noopener">http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017459.html</a></li><li>(stephenfin) I've been trying to merge (single +2, sadly, since I can't find reviewers) old patches that add support for e.g. force completing migrations and will review whatever's thrown my way. Also, anyone want core on OSC? :-)</li><li><a href="https://etherpad.opendev.org/p/community-w-series-goals" rel="noreferrer noopener">https://etherpad.opendev.org/p/community-w-series-goals</a><ul class="bullet"><li>OSC seems top prio as a goal candidate</ul><li><a href="https://etherpad.opendev.org/p/vSummit2020_FeatureGap" rel="noreferrer noopener">https://etherpad.opendev.org/p/vSummit2020_FeatureGap</a></li><li><strong>AGREED: </strong>stephenfin will stick gibi, bauzas on OSC reviews</ul></li></ul><br><ul class="bullet"><li>(gibi) W cycle release goal is privsep transition: <a href="https://github.com/openstack/governance/blob/master/goals/proposed/migrate-to-privsep.rst" rel="noreferrer noopener">https://github.com/openstack/governance/blob/master/goals/proposed/migrate-to-privsep.rst</a><ul class="bullet"><li>Do we still have work to do here or only cleanup remains?</li><li><a href="https://github.com/openstack/nova/blob/8bb44fd5453b545285c34142ab2074f50819041f/nova/utils.py#L96" rel="noreferrer noopener">https://github.com/openstack/nova/blob/8bb44fd5453b545285c34142ab2074f50819041f/nova/utils.py#L96</a></li><li><a href="https://github.com/openstack/nova/blob/8bb44fd5453b545285c34142ab2074f50819041f/nova/conf/workarounds.py#L46" rel="noreferrer noopener">https://github.com/openstack/nova/blob/8bb44fd5453b545285c34142ab2074f50819041f/nova/conf/workarounds.py#L46</a></li><li><a href="https://github.com/openstack/nova/tree/master/etc/nova/rootwrap.d" rel="noreferrer noopener">https://github.com/openstack/nova/tree/master/etc/nova/rootwrap.d</a></li><li>(stephenfin) I think os-brick is the only thing left, but I don't really understand rootwrap implementations</li><li><strong>AGREED:</strong><ul class="bullet"><li>move os_brick rootwrap profiles delivered by nova to os_brick -> <strong>lyarwood</strong> will do it</li><li>advise cinder folks that they should transfrom os_brick to privsep</li><li>all the remaining rootwrap pieces in nova is due to os_brick and can go away when os_brick is converted</ul></li></ul></li></ul><br><ul class="bullet"><li>(gibi) policy default to yaml (W cycle goal)<ul class="bullet"><li>In nova it was already done by gmann</li><li><strong>AGREED: </strong>gibi will propose a patch for Placement<ul class="bullet"><li>+1, thanks </ul></li></ul></li></ul><br><ul class="bullet"><li>(stephenfin) Support for the Q35 machine type in the libvirt virt driver<ul class="bullet"><li>This is potentially critical for RH leading into OSP 17 and RHEL. Do we understand the problem and can we prioritize work here?<ul class="bullet"><li>(lyarwood) I've picked this up from a RH PoV. To answer the question, yes I believe I understand the problem and the work required, namily the need to stash the machine type, stand up nova-next to use q35, resolve the volume extend bug (listed below) and anything else that comes up.</li><li>(kashyapc)<ul class="bullet"><li>This (now-historical spec) contains some useful info (some of which should be incorporated into docs) — <a href="https://review.opendev.org/#/c/631154/7/specs/victoria/approved/q35_qemu_machine_type_as_the_default.rst" rel="noreferrer noopener">https://review.opendev.org/#/c/631154/7/specs/victoria/approved/q35_qemu_machine_type_as_the_default.rst</a></li><li>After lengthy discussions in the above spec, we decided we don't want to change the *default* machine type in Nova itself, but:<ul class="bullet"><li>have the CI passing with Q35 (see further below);</li><li>then allow TripleO to switch the default from 'pc' (i440fx) to 'q35'</ul></li></ul></li></ul><li>Need to stash existing machine types before allowing operators to change the default to avoid breaking users by changing the underlying emulated hardware in their instances.<ul class="bullet"><li>This will be outlined in a spec to be written shortly</li><li>this is the stable abi thing i was mentioning earlier<ul class="bullet"><li>at a minium we need to recored machine type which we agreed to do last ptg i just didnt get to it. (required for q35 change)</li><li>ideally i think we should recored all values settable via image porperties for an instace ( nice to have)</ul><li>The libvirt virt driver being responsible for capturing this for existing instances at startup etc.</li><li>Obviously this is going to require some extensive docs/releasenotes setting out the upgrade case, we should also test this in grenade.</ul><li>CI<ul class="bullet"><li> nova-next: Start testing the 'q35' machine type<ul class="bullet"><li><a href="https://review.opendev.org/#/c/708701/" rel="noreferrer noopener">https://review.opendev.org/#/c/708701/</a></ul></li></ul><li>Bugs<ul class="bullet"><li>tempest.api.volume.test_volumes_extend.VolumesExtendAttachedTest.test_extend_attached_volume failing when using the Q35 machine type<ul class="bullet"><li><a href="https://bugs.launchpad.net/nova/+bug/1832248" rel="noreferrer noopener">https://bugs.launchpad.net/nova/+bug/1832248</a> +10</li><li>(aarents) We have this bug in operation q35/qemu-4.0/libvirt-5.4.0 but for interface attachment, not able to reproduce easily for now.</ul></li></ul></li></ul></li></ul><ul class="indent"><li><ul class="indent"><li><ul class="indent"><li><ul class="indent"><li>same behavior, attachment seems ok from libvirt/nova, then libvirt receive "DEVICE_DELETED" event from qemu. </ul></li></ul></li></ul></li></ul><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li><ul class="bullet"><li>(lyarwood) Can you add that context to the bug please.</li><li>Done</ul></li></ul></li></ul><li><strong>AGREED:</strong><ul class="bullet"><li>lyarwood to write it up as a generic record all the things spec.<ul class="bullet"><li>record all image props to allow future changes to defaults</ul><li>take special care about upgrade<ul class="bullet"><li>stash current machnie type at compute startup and hard reboot</li><li>make an upgrade check that warns if there are instances without machine type record</ul></li></ul></li></ul></li></ul><br><ul class="bullet"><li>(gibi) finishing V cycle goal<ul class="bullet"><li>We still need to move tempest-integrated-gate back to Focal as the nova libvirt fix has been merged<ul class="bullet"><li>lyarwood will follow it up<ul class="bullet"><li><a href="https://review.opendev.org/#/c/755525/" rel="noreferrer noopener">https://review.opendev.org/#/c/755525/</a> <- rechecked, not sure that it will merge with an active -W and +W but meh \o/</ul></li></ul><li>Zuul v3 migration<ul class="bullet"><li><a href="https://review.opendev.org/#/c/711625/" rel="noreferrer noopener">https://review.opendev.org/#/c/711625/</a> - zuul: Introduce a multinode ceph job<ul class="bullet"><li>Depends-On <a href="https://review.opendev.org/#/c/755270/" rel="noreferrer noopener">https://review.opendev.org/#/c/755270/</a> - orchestrate-devstack: Copy ceph.conf and keyrings to subnode</li><li>Required-By <a href="https://review.opendev.org/#/c/742056/" rel="noreferrer noopener">https://review.opendev.org/#/c/742056/</a> - Migrate nova-grenade-multinode job to zuulv3 native</li><li>Required-By <a href="https://review.opendev.org/#/c/752557/" rel="noreferrer noopener">https://review.opendev.org/#/c/752557/</a> - zuul: Replace nova-live-migration with zuulv3 jobs</ul><li><a href="https://review.opendev.org/#/c/755309/" rel="noreferrer noopener">https://review.opendev.org/#/c/755309/</a> - zuul: Merge nova-evacuate into nova-multinode-live-migration<ul class="bullet"><li>Unrelated but this merges the nova-evacuate and the new nova-multinode-live-migration jobs into a single job</ul></li></ul></li></ul></li></ul><br><ul class="bullet"><li>(kashyapc) Secure Boot spec<ul class="bullet"><li>Spec: <a href="https://review.opendev.org/759731" rel="noreferrer noopener">https://review.opendev.org/759731</a></li><li>WIP code (before I paused the effort): <a href="https://review.opendev.org/#/q/topic:bp/allow-secure-boot-for-qemu-kvm-guests+(status:open+OR+status:merged)" rel="noreferrer noopener">https://review.opendev.org/#/q/topic:bp/allow-secure-boot-for-qemu-kvm-guests+(status:open+OR+status:merged)</a></li><li>Q35 is needed for secure boot but we are not depending on the Q35 as a default spec<ul class="bullet"><li>Must make sure we enforce this -- yes</ul><li><strong>TODO</strong><ul class="bullet"><li>(Stephen raised this) Double-check if there's any other host-level config required: there _isn't_ any, top off my head, besides the virt component versions below<ul class="bullet"><li>libvirt, QEMU versions</li><li>ovmf package (perhaps this is flagged as a domain capability by libvirt?)<ul class="bullet"><li> Yes, there's a way, from the spec:<ul class="bullet"><li>"Make Nova programatically query the ``getDomainCapabilities()`` API to check if libvirt supports the relevant Secure Boot-related features. [...] This can be done by checking for the presence of ``efi`` and ``secure`` XML attributes from the output of the ``$getDomainCapabilities()`` API."</ul></li></ul><li>image metadata would ask for the trait</ul></li></ul><li><strong>AGREED:</strong><ul class="bullet"><li>direction looks good. </li><li>Let's fix up the nits in the spec and approve it</ul></li></ul></li></ul><br><ul class="bullet"><li>(sean-k-mooney): dnspython 2.0 support<ul class="bullet"><li>eventlet currenlty does not support it<ul class="bullet"><li><a href="https://bugs.launchpad.net/nova/+bug/1888237" rel="noreferrer noopener">https://bugs.launchpad.net/nova/+bug/1888237</a> <-- yes, this was the one we used to cap eventlet<ul class="bullet"><li><a href="https://review.opendev.org/#/c/741986" rel="noreferrer noopener">https://review.opendev.org/#/c/741986</a></ul><li><a href="https://github.com/eventlet/eventlet/issues/619" rel="noreferrer noopener">https://github.com/eventlet/eventlet/issues/619</a></li><li><a href="https://github.com/eventlet/eventlet/issues/632" rel="noreferrer noopener">https://github.com/eventlet/eventlet/issues/632</a></li><li>looks like most of the dnspython2 issues have been addressed by <a href="https://github.com/eventlet/eventlet/pull/639" rel="noreferrer noopener">https://github.com/eventlet/eventlet/pull/639</a></li><li><a href="https://github.com/openstack/requirements/blob/stable/victoria/upper-constraints.txt" rel="noreferrer noopener">https://github.com/openstack/requirements/blob/stable/victoria/upper-constraints.txt</a> 1.16.0 same on master</ul><li>debian is already shipping it so victoria wont actully work properly.</li><li>rhel9 will proably have it too so we should ideally fix it but that need change to eventlets</li><li>the only thing broken by nova we know of right now is the vnc console proxy but there might be others.</li><li><strong>AGREED:</strong><ul class="bullet"><li>make a release note stating the issue</li><li>gibi will look into the eventlet codebase to see how hard it is to fix</li><li>bump lower contraints on master on eventlet to cap dnspython</li><li>bump upper-constraint dnspython < 2.0 and backport it</li><li>gibi will coordinate with neutron</ul></li></ul></li></ul><br><ul class="bullet"><li>(gibi) test on py 3.9<ul class="bullet"><li>non voting jobs has been proposed <a href="https://review.opendev.org/#/c/758813/" rel="noreferrer noopener">https://review.opendev.org/#/c/758813/</a></li><li><strong>AGREED</strong>:<ul class="bullet"><li>we should test it</li><li>gibi will try to push it forward</ul></li></ul></li></ul><br><ul class="bullet"><li>(stephenfin) Filters -> placement pre-filters<ul class="bullet"><li>Are there other filters we might want to look at replacing with placement queries? ComputeFilter jumps to mind.<ul class="bullet"><li>Doesn't <a href="https://review.opendev.org/#/c/668752/" rel="noreferrer noopener">https://review.opendev.org/#/c/668752/</a> basically do this?<ul class="bullet"><li>(stephenfin) Almost. bauzas saw some issues when sean-k-mooney tried to remove this in the past</li><li>we are missing tracking status so we have state (enabled/disabled) but not staus(up/down/forced down)</li><li>if we have a trait for that we can drop it.</li><li><a href="https://github.com/openstack/nova/blob/master/nova/scheduler/request_filter.py#L91-L133" rel="noreferrer noopener">https://github.com/openstack/nova/blob/master/nova/scheduler/request_filter.py#L91-L133</a> example of logging</ul></li></ul><li><strong>AGREED:</strong><ul class="bullet"><li>if there is no external visible behavior change by transforming a filter to a prefilter then specless bp is enough</li><li>Only deprecate the translated filters but not remove them until we gather feedback about the pre-filter (this could be after more than a few cycles +1). </li><li>We can remove the replaced filter from the default filter list</li><li>Emit a debug log for each pre-filter when it the pre-filter is changed the allocation candidate request</ul></li></ul></li></ul><br><ul class="bullet"><li>(lyarwood) Enabling admin only move operations for instances with associated barbican sercerts<ul class="bullet"><li><a href="https://bugs.launchpad.net/nova/+bug/1895848" rel="noreferrer noopener">https://bugs.launchpad.net/nova/+bug/1895848</a></li><li><a href="https://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-containers-uuid-acl" rel="noreferrer noopener">https://docs.openstack.org/barbican/latest/api/reference/acls.html#patch-v1-containers-uuid-acl</a></li><li>mgoddard: Feel free to ping me for this one, since I raised the bug.</li><li>Q: Should we try to workaround this in code or just document the suggested workaround from the bug (using a migrator role who can read secrets) as Cinder does for other issues during the initial creation of an encrypted volume by a user:<ul class="bullet"><li><a href="https://docs.openstack.org/cinder/latest/configuration/block-storage/volume-encryption.html#key-management-access-control" rel="noreferrer noopener">https://docs.openstack.org/cinder/latest/configuration/block-storage/volume-encryption.html#key-management-access-control</a></ul><li>thre are thing that try to do things with an admin context without a user token<ul class="bullet"><li>resize auto confirm periodic task <- if the guess it running in resize verify this should not fail right</li><li>rebooting instance at compute startup due to resume_guests_state_on_host_boot config</ul><li><strong>AGREED:</strong><ul class="bullet"><li>add a new user to nova conf for barbican</li><li>when nova creates the secret in barbican with the user's token then nova needs to add an ACL so that the nova's barbican user can read the token later</li><li>alternative: service user token used in a similar way along side the user admin token</li><li>lyarwood to write up a spec for this in W</ul></li></ul></li></ul><br><ul class="bullet"><li>(lyarwood) refresh connection_info / avoid storing stale connection_info in Nova<ul class="bullet"><li><a href="https://review.opendev.org/#/q/topic:bug/1860913" rel="noreferrer noopener">https://review.opendev.org/#/q/topic:bug/1860913</a><ul class="bullet"><li><a href="https://bugs.launchpad.net/cinder/+bug/1860913" rel="noreferrer noopener">https://bugs.launchpad.net/cinder/+bug/1860913</a></li><li>Also useful when MON IPs change with Ceph. +1+1(I see the Ghost of Chet)</li><li>This also came up during the cinder PTG, during the Kioxia driver discussion.<ul class="bullet"><li><a href="https://etherpad.opendev.org/p/wallaby-ptg-cinder" rel="noreferrer noopener">https://etherpad.opendev.org/p/wallaby-ptg-cinder</a> (~L314)</li><li>It was agreed that as a workaround the new cinder volume driver will not provide stateful connection_info for the time being due to the issue of stale connection_info in Nova. Instead os_brick will request this stateful data via an agent installed on the computes before connecting the volume that is itself made up of various NVMe connections to storage across several nodes. These connections can change over time leading to the issue.</ul></li></ul><li>Q: Really Nova should stop storing connection_info between instance ops and start pulling it more often from Cinder API? If yes, is this a spec?</li><li><strong>AGREED:</strong><ul class="bullet"><li>have a small spec, but overall looks good.</ul></li></ul></li></ul><br><ul class="bullet"><li>(gibi): Interface attach with qos ports+1<ul class="bullet"><li>Spec: <a href="https://review.opendev.org/#/c/755477/" rel="noreferrer noopener">https://review.opendev.org/#/c/755477/</a></li><li>WIP code: <a href="https://review.opendev.org/#/q/topic:bp/support-interface-attach-with-qos-ports" rel="noreferrer noopener">https://review.opendev.org/#/q/topic:bp/support-interface-attach-with-qos-ports</a></li><li>Open Questions: <ul class="bullet"><li>Do we need microversion bump for this? See viewpoint in: <a href="https://review.opendev.org/#/c/755477/1/specs/wallaby/approved/support-interface-attach-with-qos-ports.rst@85" rel="noreferrer noopener">https://review.opendev.org/#/c/755477/1/specs/wallaby/approved/support-interface-attach-with-qos-ports.rst@85</a></ul><li><strong>AGREED:</strong><ul class="bullet"><li>no microversion is needed</li><li>update the spec</ul></li></ul></li></ul><br><ul class="bullet"><li>(sean-k-mooney): live migration and scheduler defaults, <ul class="bullet"><li>can we make them this<ul class="bullet"><li>live_migration_permit_post_copy=true<ul class="bullet"><li>(kashyapc)<strong> A concern: </strong>If you're using <em>not</em> using network-based storage, a serious downside to post-copy is that <strong>if you have a network failure while migration is in progress, you'll lose the guest</strong><ul class="bullet"><li>This problem of "post-copy recovery" is not yet resolved in QEMU</li><li><strong>Despite the above downside, for most users it <em>does</em> make sense to have 'post-copy' enabled—</strong>especially for network-based storage, because network will already be a critical point for you<ul class="bullet"><li>IOW, <strong>enabling post-copy is based on your risk tolerance</strong></ul></li></ul><li>(johnthetubaguy) +1 keep this off</ul><li>live_migration_timeout_action=force_complete<ul class="bullet"><li>yes</ul><li>live_migration_permit_auto_converge=true<ul class="bullet"><li>not sure about that one... although the OPS meetup folks said to turn this on</li><li>(aarents) this help us a lot to turn it on</ul><li>Also: 500 -> 2000 or 1000?</ul></li></ul></li></ul> <a href="https://review.opendev.org/#/c/760050/" rel="noreferrer noopener">https://review.opendev.org/#/c/760050/</a><br><ul class="bullet"><li><ul class="bullet"><li>when we intoduced multiple port binding one of the motivators was fast network setup with less packetloss.</li><li>this only happens if you use post copy</li><li>postcopy only triggers if the timeout action is force complete</li><li>for large vms or when you use hugepages post copy significantly reduces live migration time<ul class="bullet"><li>when usign 1G hugepages if you write a singel byte to a hugepage teh whole thing need to be copied again if you dont use post copy</ul><li>for busy vms auto converge ensure the live migration will eventualy complete</li><li>lets default to the fast option and allow operators to opt out if they dont want it.</li><li><strong>AGREED:</strong><ul class="bullet"><li>make force complete as the default action at live migration timeout</li><li>bump to 2000</li><li>document the hugepage recomendation</ul></li></ul></li></ul><br><ul class="bullet"><li><ul class="bullet"><li>for the scheduler it would be nice to set <ul class="bullet"><li>[filter_scheduler]/host_subset_size=3 <ul class="bullet"><li>this should really be in the range of 3-10 in most cases but large value basically break the weighing and make it random</li><li>basically this should roughly the same order of magniture or small as your typical max size multi create and it should be several oders of magniture smaller then the could size.</li><li>you want it to be small relivie to the cloud so that the weigher are statitcally relevent but large relitve to the request so that the entroy of the node selection fo alternate is enough to ensure we dont hit the retry limit.</li><li>if you have a 500 node cloud then this should be set to at most something in the 5-50 range to keep it 1 to 2 orders of magnitude smaller then the cloud. (for wheiers to matere this need to be staticialy small relive to the cloud size)</li><li>if your typical multicreate is 100 instance then you would want the value to be somewhere betwen 1-10</li><li>so for a cloud of this size we would recomment something between 5-10 though smaller values are still ok </li><li>3 is a guess but shoudl work for many cloud over ~30 nodes for smaller cloud 1 is proably the right default i chose 3 mainly because that is our default retry value so if you have 3 or less host its going to try them all anyway.</ul><li>I'm personnally against changing this default since it would make scheduling unpredictable for the slight benefit of performance (particularly for large clouds, but not for small ones). TBH, I just feel we need better docs. +1</li><li><strong>AGREED</strong>:<ul class="bullet"><li>only document, don't change the default</ul><li>[filter_scheduler]/shuffle_best_same_weighed_hosts=true<ul class="bullet"><li>+1+1</ul><li><a href="https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.host_subset_size" rel="noreferrer noopener">https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.host_subset_size</a></li><li><a href="https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.shuffle_best_same_weighed_hosts" rel="noreferrer noopener">https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.shuffle_best_same_weighed_hosts</a></li><li><a href="https://review.opendev.org/#/c/760055/" rel="noreferrer noopener">https://review.opendev.org/#/c/760055/</a></li><li>this is more or less required for multi create to work properly when you have any retries. the wehers work on the current state not the pending state so we need extra entropy to ensure we dont have retries all try the same host.</li><li><strong>AGREED</strong>:<ul class="bullet"><li>agreed to change the default</ul></li></ul><li>both the live migration and filter sheduler values have come up several times with customers over the last 6-12 months so i think its worth making these our defualts.</li><li>we could adress the sheduler default with better docs but i think the live migration options should be changed in code.</li><li>johnthetubaguy: ... but this is much less of a big deal with we do two-phase commit (whoop, whoop).</ul></li></ul><br><ul class="bullet"><li>(jrosser): Instance identity documents+1<ul class="bullet"><li>See here for a nice introduction to the subject <a href="https://smallstep.com/blog/embarrassingly-easy-certificates-on-aws-azure-gcp/" rel="noreferrer noopener">https://smallstep.com/blog/embarrassingly-easy-certificates-on-aws-azure-gcp/</a></li><li>Here is a POC <a href="http://paste.openstack.org/show/798996/" rel="noreferrer noopener">http://paste.openstack.org/show/798996/</a></li><li>The motivation is to provide a cryptographically verifiable identity document for an instance which can then be used outside the instance to bootstrap other operations which require trust<ul class="bullet"><li>Issuance of certificates</li><li>...</ul><li>The JWT approach from google appears simple and as the POC shows is a relatively trivial addition to the metadata api service</li><li>i mentioned on irc that this is almost small enough to be a specless blueprint but i forgot that all api changes require a spec. with that said i do think this is a resonable thing to add.</li><li>Things to think about<ul class="bullet"><li>Rotation of the private key - existing commercial public clouds may do this daily so whats the hook to allow a deployer to do this without lots of restarting services</li><li>How to pass the 'audience' for the JWT, either an HTTP header or query parameter, but how would this get from handler.py to base.py, and how would it pass through the metadata proxy</li><li>Where to publish the public key for validation of the identity document</li><li>What is the information that should & should not go in the identity document</ul><li><strong>AGREED:</strong><ul class="bullet"><li>discuss it in the spec</ul></li></ul></li></ul><br><ul class="bullet"><li>(gibi)(stephen): Static typing in nova with mypy+1+1<ul class="bullet"><li>What should we do about oslo versionedobjects in nova?<ul class="bullet"><li>The class member definition of o.vos are happen at runtime via the register, register_if or objectify class decorators based on the fields dict. So mypy does not know about the members of the class or the types of those members</li><li>A mypy plugin like <a href="https://github.com/gibizer/ovo-mypy-plugin" rel="noreferrer noopener">https://github.com/gibizer/ovo-mypy-plugin</a> can help mypy to understand what fields exists in an o.vo runtime</li><li>o.vos value coercing mechanism makes it hard to define exact types for o.vo defined fields. E.g. an IntegerField accept a string value durring assignment if int(value) can be used to convert the string to int</li><li>given the fields are objects could we define a mypy_type property on them and have the plugin call that to get the type to check and then we can handel this per field. e.g. IntegerFiled coudl return Union[String,Int]</li><li>in the base filed object we coudl have mypy_type return ANY</ul><li><strong>AGREED:</strong><ul class="bullet"><li>do type annotation for hardware.py</li><li>only best effort for o.vos</ul></li></ul></li></ul><br><ul class="bullet"><li>(bauzas) Stop recreating mdevs on reboot<ul class="bullet"><li>Context : <a href="https://bugs.launchpad.net/nova/+bug/1900800" rel="noreferrer noopener">https://bugs.launchpad.net/nova/+bug/1900800</a> </li><li>mdevs aren't persisted, so we can't guess whose parent they had before after rebooting</li><li>a workaround does exist : <a href="https://github.com/mdevctl/mdevctl" rel="noreferrer noopener">https://github.com/mdevctl/mdevctl</a></li><li>two possible outcomes:<ul class="bullet"><li>only stop trying to recreate at reboot, delete a single method and done. Profit.</li><li>or, stop creating mdevs on the fly at instance creation, which would require ops to pre-create mdevs, like we do for VFs. Harder to tell to ops tho and </ul><li><strong>AGREED:</strong><ul class="bullet"><li>continue discussing on IRC</ul></li></ul></li></ul><br><ul class="bullet"><li>(brinzhang): Cyborg shelve/unshelve support<ul class="bullet"><li><a href="https://review.opendev.org/#/c/729563/" rel="noreferrer noopener">https://review.opendev.org/#/c/729563/</a></li><li>We have approved this blueprint in Victoria, and it was not merged closely Victoria release</li><li>(sean-k-mooney) this should be moved up to the cyborg session slot but yes i think we should just continue with this</li><li><strong>AGREED</strong>: just review this specs no objections to continuing this</ul></li></ul><br><ul class="bullet"><li>(brinzhang): Proposal for a safer remote console with password authentication<ul class="bullet"><li><a href="https://review.opendev.org/#/c/623120/" rel="noreferrer noopener">https://review.opendev.org/#/c/623120/</a></li><li>We has already re-proposed this spec in Victoria, and due the contributor work changing, it couldn't be completed, and we will re-propose it in Wallaby, and I will change the owner<ul class="bullet"><li>Re-proposes spec: <a href="https://review.opendev.org/#/c/759828/" rel="noreferrer noopener">https://review.opendev.org/#/c/759828/</a></ul><li><strong>AGREED</strong>:<ul class="bullet"><li>review the spec, it is a repropose so it is OK.</ul></li></ul></li></ul><br><ul class="bullet"><li>(brinzhang): Cyborg suspend/resume support<ul class="bullet"><li><a href="https://review.opendev.org/#/c/729945" rel="noreferrer noopener">https://review.opendev.org/#/c/729945</a></li><li>We would like to complete this feature in Wallaby</li><li>(sean-k-mooney) this should be moved up to the cyborg session slot but yes i think we should just continue with this</li><li><strong>AGREED</strong>: just review this specs no objections to continuing this</ul></li></ul><br><ul class="bullet"><li>(stephenfin) Incorporating IP information in libvirt instance metadata<ul class="bullet"><li><a href="https://review.opendev.org/#/c/750552/3" rel="noreferrer noopener">https://review.opendev.org/#/c/750552/3</a><ul class="bullet"><li>this specific patch is in complete since it does not take into account interface attach/detach or floating ips as far as i can see.</ul><li>As an aside, our guideline for what someone should do with specless blueprints seems to be lacking<ul class="bullet"><li>as long as it is not an api change if we agree its well scoped and not a bug it can be a sepcless blueprint. this is not an api change so specless blueprint sound resonable to me, its what i was going to do.</li><li>(melwitt): As johnthetubaguy said, that's how I think of it too, if a thing needs any discussion or questions/answers, a spec is what we use to have that discussion +1</ul><li>(sean-k-mooney): actully this remind me of a patch i started working on last cycle. i was going to also add all the flavor and image info e.g. the exta specs and image properties.</li><li>basicailly i was going to add all the info needed to debug why the xml was generated the way it was and how it landed on a given host. that way without needing to lookup the flavor and image</li><li>we can debug things just form the xml. this is very very useful for us downstream when looking at sos reports from customers as we often do not get teh flavor and image info and have to ask</li><li>them to provide it but if its in the metadata we can validate our assumtions.</li><li><s>Related </s><a href="https://review.opendev.org/#/c/749977/" rel="noreferrer noopener"><s>https://review.opendev.org/#/c/749977/</s></a><s> (add requested_networks to RequestSpec)</s></li><li><strong>AGREED:</strong><ul class="bullet"><li>we need a small spec to answer the stephen's questions</ul></li></ul></li></ul><br><ul class="bullet"><li>(johnthetubaguy) adding non-fatal filters, deprecate weighers<ul class="bullet"><li>Make everything return a True/False, i.e. a filter</li><li>have an ordered list of the above filters, generates a bit field, use bit field generated as the weight<ul class="bullet"><li>Advantage: the precidence order is clear</li><li>Existing weighers can be converted by adding a threshold for True/False given a weigher that doesn't just return 1/0</li><li>... might need to have config that allows a weigher to be used twice with two different thresholds</li><li>AIM: no extra code needed when deciding if something moves from a filter to a weight or v.v.</ul><li>existing list becomes a list of "fatal" filters, i.e. a host must pass such filters to be a valid candidate</li><li>... actually this is just one more weigher, eventually we make it the only default weigher</li><li>please tell me more :)</li><li>(bauzas) Trying to gather old' Dublin etherpad...</ul></li></ul><br><ul class="bullet"><li>(sean-k-mooney): static rest endpoint to list available features.<ul class="bullet"><li>simple list of named tupples </li><li><> required [] optional</li><li><feature-string>:[min micoroversion]:[description]</li><li>semantics are if the feature is supported its listed and you can use it for discoverablity.</li><li>useful fo flavor extra specs or other virt dirver/backend speciifc features that are independet of micorverions.</li><li>(gmann): this seems same as providing capabilities? </li><li>Using JSON home was one option we discussed in past.<ul class="bullet"><li><a href="https://review.opendev.org/#/q/status:abandoned+topic:bp/nova-api-json-home" rel="noreferrer noopener">https://review.opendev.org/#/q/status:abandoned+topic:bp/nova-api-json-home</a></ul><li><strong>AGREED</strong>:<ul class="bullet"><li>write a spec, define what is a "feature"</li><li>probably we don't have time for this in the W cycle</ul></li></ul></li></ul><br><ul class="bullet"><li>(sean-k-mooney) on behalf of legochen add new domain prefilter to map keystone domains to host aggreates<ul class="bullet"><li><a href="https://github.com/openstack/nova/commit/732e202e81142a8ea462a9ebcde9a7226a62a60b" rel="noreferrer noopener">https://github.com/openstack/nova/commit/732e202e81142a8ea462a9ebcde9a7226a62a60b</a></li><li>basicaly the same as the existign tenant one ^ but change proejct id for domain and TENANT_METADATA_KEY with a DOMAIN_METADATA_KEY in host aggrate</li><li>addtionally check if AZ is valid for a given user based on project or domain and retrun error in server create instead of no valid host<ul class="bullet"><li>... erm but why? 5 AZs in the cloud, but this domain only has access to 3 AZs</ul><li>also could filter the az list on the same critiia</li><li>user scenario - <a href="https://docs.google.com/document/d/1Cv3FB3HLc70o4EcFh9aLxzPVszRgulkADnmJxmT65a8/edit#" rel="noreferrer noopener">https://docs.google.com/document/d/1Cv3FB3HLc70o4EcFh9aLxzPVszRgulkADnmJxmT65a8/edit#</a></li><li><strong>AGREED:</strong><ul class="bullet"><li>need a spec/blueprint on domain prefilter, seems good</li><li>need a spec to expand flavor ACL for domains as well as project, seems good</li><li>have a spec on filtering AZs by tenants and domain, need more details on use cases<ul class="bullet"><li>NOTE: we have plans to use "distance" or service group affinity/anti-affinity</ul></li></ul></li></ul><li>(legochen) one more question is about the access-control of flavors<ul class="bullet"><li>so far, flavor offers a way to share by multiple-tenants. But, I'm looking for a solution for domain level control.<ul class="bullet"><li>Will system scope things can be done instead of domain?</ul></li></ul></li></ul><br><ul class="bullet"><li>(belmoreira) Support guests from different architectures<ul class="bullet"><li>Probably I can't make it for the discussion but if you reach this topic it would be great if this gets some attention.</li><li>My use case is to run aarch64 guests on top of x86_64</li><li>In the past we had a generic bug to discuss this issue: <a href="https://bugs.launchpad.net/nova/+bug/1863728" rel="noreferrer noopener">https://bugs.launchpad.net/nova/+bug/1863728</a> </li><li>I'm now opening target bugs:<ul class="bullet"><li><a href="https://bugs.launchpad.net/nova/+bug/1902203" rel="noreferrer noopener">https://bugs.launchpad.net/nova/+bug/1902203</a></li><li><a href="https://bugs.launchpad.net/nova/+bug/1902205" rel="noreferrer noopener">https://bugs.launchpad.net/nova/+bug/1902205</a></li><li><a href="https://bugs.launchpad.net/nova/+bug/1902216" rel="noreferrer noopener">https://bugs.launchpad.net/nova/+bug/1902216</a></ul><li>Need to be sure we don't break mult-arch clouds be accident</li><li><strong>AGREED:</strong><ul class="bullet"><li>Thanks for the bugs. We need somebody who works on the bugfixes</li><li>To avoid breaking multi-arch clouds we need a spec to discuss separation</ul></li></ul></li></ul><br><br><br>
</body>
</html>