| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-21 | |||
| 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 | |
| 09:01:10 | bauzas | elodilles: what python version is shipped with 22.04 Jellyfish ? | |
| 09:01:43 | bauzas | 3.10, sorry found it | |
| 09:02:47 | elodilles | to be honest i'd rather keep the old python versions in all deliverables as long as the code is compatible with them. but that is harder to follow and we might not notice when we add incompatible changes (unless we keep old jobs, or lower-constraints like jobs around... :S) | |
| 09:07:06 | bauzas | elodilles: found the TC resolution | |
| 09:07:12 | bauzas | elodilles: read this : | |
| 09:07:13 | opendevreview | Elod Illes proposed openstack/nova master: Drop nova-tox-functional-py38 https://review.opendev.org/c/openstack/nova/+/881339 | |
| 09:07:17 | bauzas | Testing: Just as we test and guarantee that upgrades are supported between adjacent releases today, we will also test and guarantee that upgrades between two “SLURP” releases are supported. Upgrades are tested for most projects today with grenade. A skip-level job will be maintained in the grenade repository that tests a normal configuration between the last two “SLURP” releases. The job will be updated on every new “ | |
| 09:07:17 | bauzas | SLURP” release, and there will always be a regular single-release grenade job testing between the previous release and current one, as we have today. | |
| 09:08:13 | bauzas | it says nothing for the dependencies | |
| 09:08:57 | elodilles | yes, no word about runtimes | |
| 09:11:04 | kashyap | What are "SLURP" releases, again? | |
| 09:13:47 | bauzas | kashyap: this is the new upstream release cadence where you can skip some release https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html | |
| 09:27:14 | elodilles | bauzas: note that this failure can be now in other repositories as well, it is likely that other projects will start dropping their py38 support / job (neutron for example merged a similar patch already) | |
| 09:29:31 | bauzas | elodilles: yeah, looks like the boat has sailed, but at least for nova, I'd prefer us to take a bit of time for discussing it | |
| 09:29:41 | bauzas | elodilles: at least because of computes :) | |