| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-20 | |||
| 12:07:36 | lajoskatona | sean-k-mooney: so till the mi microversion is not bumped higher that 2.36 we have to keep these proxy APIs and the tests? | |
| 12:07:52 | sean-k-mooney | if i can leverage this as a forcing funciton to actully raise our min microversion then i would be happy to raise it above where those were decpreated and delete the code | |
| 12:08:24 | sean-k-mooney | lajoskatona: yes i think we do because they are still fully supproted and i think horizon might still be using some of them | |
| 12:10:00 | lajoskatona | sean-k-mooney: I see you also commented on the bug, thanks, it will help everybody to see the whole picture | |
| 12:10:24 | sean-k-mooney | i have no partically issue with skiping the nova test by defualt in most jobs | |
| 12:10:32 | sean-k-mooney | but the nova gate still need to test it | |
| 12:12:53 | sean-k-mooney | lajoskatona: we also have proxy apis for cinder and glance that we unfortunetlly still need to test | |
| 12:13:00 | sean-k-mooney | for basically the same reason | |
| 12:15:12 | sean-k-mooney | lajoskatona: im not that familar with horizon but https://github.com/openstack/horizon/commit/9067ae8b0fe6dd57906d0eb5fe31ee96eb021fd4 it looks like they have actully converted to usign neutron instead | |
| 12:15:59 | lajoskatona | sean-k-mooney: anyway I still think it is worth to discuss if we have to test these APIs for all patch, and instead run these tests against a really used API (Neutron in this this case but can be true for Glance or Cinder also) | |
| 12:20:29 | sean-k-mooney | well that is why i suggested not testign them in gates other then nova | |
| 12:20:55 | sean-k-mooney | so neutron cinder and glance coudl perhaps stop testign them but i think nova still needs too | |
| 12:21:21 | sean-k-mooney | i woudl suggest usign the Intergrated-Compute job to test them | |
| 12:21:44 | sean-k-mooney | bauzas: gibi ^ does that sound reasonable to ye | |
| 12:22:24 | sean-k-mooney | i wont be at the physical ptg but once we have one job on nova testing the proxy apis then i think thats enough | |
| 12:32:33 | lajoskatona | sean-k-mooney: sonds reasonable, keep the tests and execute them in a Nova only job, and do not test these "legcy" API from other projects | |
| 12:33:10 | sean-k-mooney | that does mean if cidner or neutron breaks these ye wont see that breakage but we will | |
| 12:33:17 | sean-k-mooney | that said i dont think that has ever happened | |
| 12:33:24 | sean-k-mooney | so im not realy worreid about that | |
| 12:34:11 | sean-k-mooney | pluse we will see it and we can let ye know if it happens | |
| 12:41:21 | bauzas | sean-k-mooney: can you summarize your opinion please ? | |
| 12:41:29 | bauzas | (just to make sure I understand it correctly) | |
| 12:42:00 | sean-k-mooney | tl;dr we cant stop testing proxy api unless we rais our min microversion but we dont need to test it in project other then nova | |
| 12:42:42 | sean-k-mooney | so im fine with not running the proxy api test in other proejct jobs and i think testing it only in the intergarte-compute jobs woudl be enough coverage for our gate | |
| 12:43:22 | sean-k-mooney | i.e. one job to smoke test that they still work as expected on our side but no expectation for other project to continue testing the proxy apis | |
| 12:43:29 | bauzas | sean-k-mooney: sure, those are deprecated | |
| 12:43:39 | sean-k-mooney | yep but fully supported | |
| 12:44:08 | sean-k-mooney | deprecation in this case just means we wont extend them and you should not build new uasge of them | |
| 12:44:44 | sean-k-mooney | i would love to delete the code but to do that we really need to raise our min microversion | |
| 12:45:26 | sean-k-mooney | i think we should do that regardelss of this effort but i dont think we shoudl remove all testing in tempest if we report our min microvstion as 2.1 | |
| 12:46:18 | sean-k-mooney | anyway hopefully that is a sufficent summary if not ask away and i can clarify | |
| 12:50:45 | bauzas | cool | |
| 13:09:31 | sean-k-mooney | bauzas: gibi im doing some jira cleanup this morning... so ill reping the weigher patch in the next hour or so | |
| 13:09:38 | sean-k-mooney | thanks for the reviews | |
| 13:14:37 | gibi | sean-k-mooney: cool. I can +2 it quickly as I'm OK with the content | |
| 17:15:34 | opendevreview | Merged openstack/nova stable/zed: Handle InstanceInvalidState exception https://review.opendev.org/c/openstack/nova/+/872115 | |
| 18:34:08 | opendevreview | sean mooney proposed openstack/nova master: add hypervisor version weigher https://review.opendev.org/c/openstack/nova/+/880231 | |
| 18:34:30 | sean-k-mooney | gibi: bauzas sorry that took me longer then it should have but its there for you in the morning | |
| #openstack-nova - 2023-04-21 | |||
| 07:49:24 | gibi | sean-k-mooney: +2 | |
| 08:41:43 | dvo-plv_ | sean-k-mooney: Hello | |
| 08:42:54 | dvo-plv_ | I would like to clarify our blueprint status. https://review.opendev.org/c/openstack/nova-specs/+/868377 | |
| 08:44:10 | dvo-plv_ | Maybe community need something from us to start further activities | |
| 09:48:52 | sean-k-mooney | no just pinging me and others to reveiw. my time is currently quite limited for upstream work so my review bandwith has been reduced alot due to downstream work. | |
| 09:49:08 | sean-k-mooney | i think i was more or less ok with it the last time i looked so ill take a look again | |
| 09:53:59 | sean-k-mooney | dvo-plv_: im happy with the spec as is. others might ask for more info but i think you have the main points. | |
| 09:54:15 | sean-k-mooney | i changed the topic in gerrit to bp/virtio-packedring-configuration-support | |
| 09:54:23 | sean-k-mooney | can you use the same topic for the code | |
| 10:19:35 | dvo-plv_ | okay, I will update topic for code. Currently it has https://review.opendev.org/q/topic:VirtIO_PackedRing | |
| 10:19:42 | dvo-plv_ | What does this topic means ? | |
| 10:29:09 | sean-k-mooney | we can use that on the spec | |
| 10:29:18 | sean-k-mooney | the topic is just wa way to group related patches together | |
| 10:29:27 | sean-k-mooney | so the code and spec should use the same one | |
| 10:30:07 | sean-k-mooney | by convention we use bp/<bluprint name> for features that are tracked by a bluepirnt or spec | |
| 10:30:17 | sean-k-mooney | and bug/<bug number> for bugs | |
| 10:30:39 | sean-k-mooney | otherwise its freeform | |
| 10:31:08 | sean-k-mooney | for feature that require changes in multiple project we try to use the same topic across all of them to be able to see all reated patches quickly | |
| 10:31:42 | sean-k-mooney | so now that you updated it https://review.opendev.org/q/topic:bp%252Fvirtio-packedring-configuration-support | |
| 10:32:00 | sean-k-mooney | we can see the spec, nova and os-traits patches all in one view | |
| 10:33:08 | sean-k-mooney | that tells me you are missing a patch to glance to update the metadefs https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt.json | |
| 10:33:48 | sean-k-mooney | dvo-plv_: ^ the metadefs are what horizon and heat use to generate the drop down for adding traits automatically | |
| 10:34:09 | sean-k-mooney | sorry not triats extra_specs and image properties | |
| 10:35:49 | dvo-plv_ | okay, I will investigate and fix | |
| 10:36:23 | sean-k-mooney | you basically jsut need to copy this https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt.json#L30-L35 | |
| 10:36:45 | sean-k-mooney | updatign mem_encyption to packed_ring | |
| 10:37:07 | sean-k-mooney | the namespce/prefix is automaticaly handeled by https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt.json#L7-L16 | |
| 10:37:49 | dvo-plv_ | okay, thanks. I would liek to check it on the horizon ui too | |
| 10:37:52 | sean-k-mooney | its also good to update the userful image properies doc https://github.com/openstack/glance/commit/3a281b9bc62a1b8b0f1468bc641105a5662f8ecd is an example | |
| 10:38:11 | dvo-plv_ | sure | |
| 10:38:18 | dvo-plv_ | Could you also clarify me with your scheduler according to the upstream work? We would like to start work over multiqueue support for hardware offloading | |
| 10:39:55 | sean-k-mooney | other can review your code not jsut me. but currently i have around 20% of my time for upstream work less fo the last 3-4 weeks because i was busy with downstream planing activies due to the ptg and other issues | |
| 10:40:54 | sean-k-mooney | i have been trying to capture all the outcomes of the ptg in our downstream jira and plannign the work for our team there | |
| 10:41:15 | sean-k-mooney | normally i have more time for upstream review so that shoudl go back to normal soon | |
| 10:41:48 | sean-k-mooney | regarding multi queue | |
| 10:42:14 | sean-k-mooney | do you mean https://review.opendev.org/c/openstack/nova-specs/+/855514 | |
| 10:42:26 | dvo-plv_ | Whom I should ping regarding review process. I saw gibi on some review process | |
| 10:43:13 | dvo-plv_ | Yes, we would like to analyze it better and provide some vision, how we can improve this in the OpenStack for hardware offloading, expecially for our nic | |
| 10:43:58 | sean-k-mooney | so multi queue is only partly implemented for hardware offload | |
| 10:44:15 | sean-k-mooney | i dont think it actully works we cannot enable it for nics that use sriov | |
| 10:44:26 | sean-k-mooney | i.e. nics that present the vf directly to the guest | |
| 10:44:37 | sean-k-mooney | but it might eb possibel for macvtap or vdpa | |
| 10:45:03 | sean-k-mooney | dvo-plv_: in terms of pings the active member of the nova core team | |
| 10:46:13 | sean-k-mooney | dvo-plv_: so gibi, bauzas, melwitt, gmann and dansmith are you best bet in addtion to me. stephenfin is also around somethimes but they mainly work on non nova related thigns day to day | |
| 10:47:51 | dvo-plv_ | okay, thanks | |
| 10:49:32 | sean-k-mooney | so looping back to multi queue | |
| 10:50:06 | sean-k-mooney | implementing this in the way you wanted is not going to be easy or really desireable form a nova point of view | |
| 10:51:19 | sean-k-mooney | there are a few parts to this problem | |
| 10:51:56 | sean-k-mooney | first we need to detach and recored the number of queues avaialbel in the vf | |
| 10:52:28 | sean-k-mooney | second we need to be able to schudle based on that (either updatign the pci filter or recording this in placement) | |
| 10:53:16 | sean-k-mooney | third we need a way to request a device with a min number of queuse multiup queuse out side the falvoar/image (likely on the nutron port) | |
| 10:54:09 | sean-k-mooney | finally we need to take the resouce request form teh port and include that in our scueduling reeust and wonce we find a host/device that meets that need we need to ensure that the qemu device is cofnigured correctly | |
| 10:54:37 | dvo-plv_ | regarding first question, we investigated it and the best option on our opinio is to parse other config. we configure queues like that -a 0000:65:00.0,representor=[4-6],portqueues=[4:2,5:2,6:2]. Yes it will work only for our nic | |
| 10:54:57 | sean-k-mooney | which config | |
| 10:55:01 | sean-k-mooney | the pci config space | |
| 10:55:15 | dvo-plv_ | ovs. other_config | |
| 10:55:15 | sean-k-mooney | you can useuslly get this form sysfs i tought | |
| 10:55:31 | sean-k-mooney | we cant do that | |
| 10:55:42 | sean-k-mooney | the ovs port wont exist at that point | |
| 10:55:45 | dvo-plv_ | no we can not, this is untrivial task for our dpdk driver | |
| 10:56:05 | sean-k-mooney | oh right so honestly you cant start this work | |
| 10:56:24 | sean-k-mooney | until the basic work of supporting the dpdk represtors is done | |