| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-21 | |||
| 11:19:17 | dvo-plv_ | yes | |
| 11:19:26 | sean-k-mooney | i mean before you propsoed it | |
| 11:19:55 | sean-k-mooney | there have been attempts to do this in teh past and it was rejected | |
| 11:20:07 | sean-k-mooney | that said we now have enough things like this that we might be ok with it | |
| 11:20:26 | sean-k-mooney | we now have things liek remote_managed and resouce class | |
| 11:20:51 | dvo-plv_ | I see. now you would like to see that queue parameter gets automatically like metadata and placemnet filter nodes according to the required queue. But you would not like to increase resource provider | |
| 11:20:58 | sean-k-mooney | so addign queue_pairs=<count> might be ok | |
| 11:21:58 | sean-k-mooney | am no we can model this in placment but it would need use to have one RP per vf | |
| 11:22:05 | sean-k-mooney | which is not soemthgn we wanted to do if we coudl avoid it | |
| 11:22:37 | sean-k-mooney | we would need to adress the placment scaling bug first | |
| 11:23:24 | sean-k-mooney | dvo-plv_: https://review.opendev.org/c/openstack/nova/+/855885 | |
| 11:23:33 | sean-k-mooney | so we could not track this in placment initally | |
| 11:23:51 | sean-k-mooney | we would have to track this in nova and use the pci filter to filter based on the queus | |
| 11:24:20 | sean-k-mooney | eventully it could be done in placement but we also need to start trackign neutron consumabel pci devices in placemnet before that | |
| 11:25:20 | sean-k-mooney | the only workable solution i see in the next 6-12 months is to do this in nova | |
| 11:26:00 | sean-k-mooney | if we require all VFs in the same pool to have the same queue count | |
| 11:26:31 | sean-k-mooney | then we can add the queue_pair count to the extra_info on the pci_device in the nova db | |
| 11:26:46 | sean-k-mooney | and the pci_passhtough filter can use that | |
| 11:28:10 | dvo-plv_ | lets assume that we have already dealt with the automatic queue getting. Lets use traits config. if this node has vf with 2 and 3 queues. Placemnet will add traits 2_queus and 3_queues to the scheduler to fitler node by queue. and than, when node is choosen, nova and choose appropariate vf by queue number | |
| 11:28:28 | sean-k-mooney | no | |
| 11:28:35 | sean-k-mooney | thsi is not a correct use of traits | |
| 11:29:38 | sean-k-mooney | traits cannot be used for Quantitative aspect of a resuce i.e the number of queuse or frequency of a cpu | |
| 11:30:36 | sean-k-mooney | HW_NIC_MULTIQUEUE is an accpaable trait which we already have https://github.com/openstack/os-traits/blob/master/os_traits/hw/nic/__init__.py#L18 | |
| 11:30:45 | sean-k-mooney | but 2_queus is not | |
| 11:31:29 | sean-k-mooney | Quantitative aspects must eb tracked as inventories in a resouce provider | |
| 11:32:13 | sean-k-mooney | dvo-plv_: we cannot currently track neutron consumable pci devices in placment by the way | |
| 11:32:24 | sean-k-mooney | vmaccel: has said they want to work on that this cycle | |
| 11:33:02 | sean-k-mooney | so for bobcat it would be risky to asume that work woudl be compelte in time for multi queu to be implemetned | |
| 11:33:16 | dvo-plv_ | does it will be part of this spec ? https://specs.openstack.org/openstack/nova-specs/specs/2023.1/implemented/pci-device-tracking-in-placement.html | |
| 11:33:41 | sean-k-mooney | dvo-plv_: no that spec epxlictly dose not support any pci device that can be use via neutron | |
| 11:37:16 | dvo-plv_ | so, the main problem taht we can not filter specific node fro the pool with required vf queue number, right ? | |
| 11:37:53 | sean-k-mooney | we can solve that todya with the pci_passhtough_filter | |
| 11:38:16 | sean-k-mooney | as i said there are 3-4 peice that need to be done | |
| 11:39:11 | sean-k-mooney | 1 recored the number of quesue (add queue_pairs to devspec and store it in pci_divice.extra_info.network_caps.queu_pairs) | |
| 11:39:51 | sean-k-mooney | 2 add a new extention to neutron to queueu queue pairs | |
| 11:40:17 | sean-k-mooney | 3 modify the pci pasthough filter to use the neutron request to fine a vf that fullfiles the need | |
| 11:40:56 | dvo-plv_ | i will be positive and believe that we can solve all of it) | |
| 11:40:58 | sean-k-mooney | 4 update teh libvirt generation to use queues=min(vf.queues,flavor.vcpus) | |
| 11:41:41 | sean-k-mooney | we can but you need to file a spec for the neutorn api extention and implement that before we can do the nova part | |
| 11:42:27 | dvo-plv_ | I have a question regarding neutron extension | |
| 11:42:39 | sean-k-mooney | sure | |
| 11:43:13 | sean-k-mooney | we might be able to use the neutron port tag extention by the way | |
| 11:43:46 | sean-k-mooney | but we need a way to say either that this port need multi queue or it need multi queue with at least X queues | |
| 11:45:07 | sean-k-mooney | we could initally skip that i guess | |
| 11:45:20 | sean-k-mooney | and just use hw_vif_multiqueu | |
| 11:45:34 | sean-k-mooney | but i fear that woul break things so i think that would be a bad idea | |
| 11:45:36 | dvo-plv_ | maybe it will more logical to extend neutron port with some additional parameter openstack port create --network net10 < --queues=2 or --binding-profile queues=2 > ... port10 | |
| 11:45:54 | sean-k-mooney | no binding profie is not a user facing field | |
| 11:46:07 | sean-k-mooney | it is for nova to pass info to the network backend | |
| 11:46:31 | sean-k-mooney | it shoudl never be written by a human or neutron | |
| 11:46:58 | dvo-plv_ | use flavor or image is not a soklution, because we could have vm with 2 port and differnet queues number. or leave it like a limitation | |
| 11:47:32 | sean-k-mooney | ya so this is whyi think we need a per port solution which means a neutron api extenion | |
| 11:47:37 | sean-k-mooney | or reusing an exsiting one | |
| 11:47:58 | sean-k-mooney | --binding-profile cant be used as makign that writabel is a security risk | |
| 11:48:11 | dvo-plv_ | sorry, Im not familiar with it. Do you means that https://docs.openstack.org/neutron/latest/contributor/internals/api_extensions.html | |
| 11:49:02 | sean-k-mooney | kind of so https://github.com/openstack/neutron-lib/tree/master/neutron_lib/api/definitions are all the api extenstiosn that neutron supprots | |
| 11:50:44 | sean-k-mooney | the binding profile for example is part of the portbindings api extention https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/portbindings.py#L31-L34 | |
| 11:50:48 | dvo-plv_ | okay, I will investiagate it. regarding this extension I should create rfe and talk with ralonsoh regarding t hat , right ? | |
| 11:51:05 | sean-k-mooney | yes | |
| 11:51:12 | sean-k-mooney | i see two possibale approches | |
| 11:51:26 | sean-k-mooney | either model this as part fo the QOS extentions | |
| 11:51:42 | sean-k-mooney | or as a sepereate multiqueue extension | |
| 11:51:48 | sean-k-mooney | if we add a new one | |
| 11:55:04 | dvo-plv_ | Thank you, I have alot of work now | |
| 11:55:42 | sean-k-mooney | one exsiting api we might be able to use is https://docs.openstack.org/neutron/latest/contributor/internals/tag.html | |
| 11:56:35 | sean-k-mooney | we could use that for hw_vif_multiqueue=true|false for example on a per port basis | |
| 11:56:54 | sean-k-mooney | the issue is its currently a string field and we woudl really prefer it to be a key value field | |
| 11:57:04 | sean-k-mooney | well a dict of key values | |
| 11:57:42 | sean-k-mooney | we have 3 or 4 usecasue that woudl benifit form a v2 of this feature that wsa key value | |
| 11:58:09 | sean-k-mooney | we spoke to ralonsoh about that durign the ptg | |
| 11:58:18 | sean-k-mooney | so tha might just be the best thign to do | |
| 11:59:41 | sean-k-mooney | then you coudl do {nova_min_queues:2,nova_multiqueue:true} on a per port basis | |
| 12:00:15 | sean-k-mooney | we coudl also do use it for nova_delete_on_detach: true|false | |
| 12:01:56 | dvo-plv_ | but this parameter is relayted to the flavor and image | |
| 12:09:30 | ralonsoh | sorry, I'm having l;unch now | |
| 12:09:39 | ralonsoh | I'll read this channel later | |
| 13:56:58 | opendevreview | Artom Lifshitz proposed openstack/nova master: Fix pep8 errors with new hacking https://review.opendev.org/c/openstack/nova/+/874517 | |
| 14:28:40 | opendevreview | Artom Lifshitz proposed openstack/nova master: Fix pep8 errors with new hacking https://review.opendev.org/c/openstack/nova/+/874517 | |
| 15:20:57 | opendevreview | Stephen Finucane proposed openstack/nova master: docs: Correct a typo, grammar in AZ doc https://review.opendev.org/c/openstack/nova/+/881235 | |
| #openstack-nova - 2023-04-23 | |||
| 00:46:20 | opendevreview | Merged openstack/nova stable/zed: Remove deleted projects from flavor access list https://review.opendev.org/c/openstack/nova/+/870053 | |
| 19:21:25 | opendevreview | Alexey Stupnikov proposed openstack/nova stable/yoga: Remove deleted projects from flavor access list https://review.opendev.org/c/openstack/nova/+/881314 | |
| 21:00:15 | opendevreview | Merged openstack/nova stable/wallaby: libvirt: Delegate OVS plug to os-vif https://review.opendev.org/c/openstack/nova/+/790447 | |
| #openstack-nova - 2023-04-24 | |||
| 07:41:09 | sahid | o/ | |
| 08:25:21 | elodilles | hi nova, note that tooz 4.0.0 dropped py38 support and upper constraints was bumped on master to new tooz version thus all py38 job is failing now on master with not finding proper version of tooz | |
| 08:26:30 | bauzas | elodilles: but we don't use tooz, right? | |
| 08:26:33 | frickler | note that this not only affects tox-py38 type jobs, but also all jobs that still run on focal | |
| 08:26:57 | frickler | but other services do, so all devstack jobs will be affected | |
| 08:29:52 | frickler | like tempest-integrated-compute-ubuntu-focal https://zuul.opendev.org/t/openstack/build/0af6ddcd55cf4b02ab996f9134d0c7f4 | |
| 08:30:49 | frickler | the latter is easy to mistake for a mirror or pypi issue | |
| 08:32:43 | elodilles | bauzas: with a quick glance i see that nova-tox-functional-py38 is failing with this issue. though i guess we shouldn't have this job on master anymore as py39 and py310 are the supported runtimes | |
| 08:33:04 | bauzas | elodilles: hmmm, lemme check | |
| 08:33:20 | bauzas | because when some people were asking whether we should tooz, we said no before | |
| 08:33:34 | bauzas | should *use* | |
| 08:34:16 | bauzas | oh damn https://github.com/openstack/nova/blob/72370a188c0755bc9c864b5a5e4a972077cb8dd6/nova/virt/ironic/driver.py | |
| 08:35:31 | bauzas | sorry, I was only thinking about the servicegroup drivers | |
| 08:36:06 | bauzas | so, we don't directly use zool in Nova but yeah, we have it for the ironic driver | |
| 08:37:58 | bauzas | ha ok | |
| 08:38:06 | frickler | IMO don't focus too much on tooz, likely other libs will follow and drop py38 support soon | |
| 08:38:54 | bauzas | frickler: well, I'm afraid we depend on some library that we don't really need | |
| 08:39:23 | bauzas | frickler: at least the ironic driver could use tooz by its client | |