| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-21 | |||
| 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 | |
| 08:39:56 | frickler | oslo.db in its latest release is >= py3.9, too | |
| 08:41:23 | bauzas | frickler: elodilles: anyway, what's then the plan ? forcing us to no longer support py3.8 because of some lib that 99% of Nova doesn't use ? | |
| 08:43:08 | elodilles | bauzas: i'm about to propoze a patch that removes the py38 job from .zuul.yaml :) | |
| 08:45:55 | bauzas | for master, that's OK https://governance.openstack.org/tc/reference/runtimes/2023.2.html | |
| 08:46:31 | bauzas | but I'm very sad of how we're forced to drop support for a python version due to some lib | |
| 08:47:00 | bauzas | a counter-proposal could be to not use tooz 4 yet | |
| 08:47:14 | bauzas | particularly when it comes to SLURP upgrades | |
| 08:47:35 | bauzas | https://governance.openstack.org/tc/reference/runtimes/2023.1.html was guaranteeing py3.8 | |
| 08:47:58 | bauzas | so operators upgrading to 2024.1 would have to raise their OS versions before the bump | |
| 08:48:22 | opendevreview | Elod Illes proposed openstack/nova master: Drop nova-tox-functional-py38 https://review.opendev.org/c/openstack/nova/+/881339 | |
| 08:48:38 | elodilles | yes, but master is for 2023.2 Bobcat already :) | |
| 08:48:56 | bauzas | I know | |
| 08:49:29 | bauzas | I'm saying that the requirements we have for 2023.1 can't be used when upgrading to 2024.1 now | |
| 08:49:43 | bauzas | or rather 2023.2 | |
| 08:50:01 | bauzas | I mean, I'm an operator wanting to upgrade from A to B | |
| 08:50:08 | bauzas | and ideally from A to C | |
| 08:50:40 | bauzas | if I check the common requirements between A and B, I know that I'll be able to use 22.04 but not py38 | |
| 08:51:27 | elodilles | i see, but still, the same issue would happen from C to E, as clearly we can't expect to keep py38 till end of time | |
| 08:52:13 | elodilles | nevertheless i'm also not fond of dropping py38 support IF there is no compatibility issue | |
| 08:52:43 | bauzas | elodilles: sure, people have to upgrade anyway by some cadence | |
| 08:53:02 | bauzas | and we're not discussing of any distro, like the one I'm paid for | |
| 08:53:49 | bauzas | I'm just saying that dropping a python version for a release that's not purely required and will prevent operators to seamlessly upgrade from A to B is at least unfortunate | |
| 08:54:11 | bauzas | and I'd like us to take a bit of a thought before we merge this | |
| 08:59:26 | elodilles | bauzas: ack, unfortunately with the tooz release we already started that road :/ | |
| 08:59:51 | bauzas | I've seen it | |