| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-21 | |||
| 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 :) | |
| 09:36:19 | kashyap | bauzas: Thanks for the link! | |
| 10:22:50 | sean-k-mooney | bauzas: elodilles im +2 on the removal of python 3.8 testing because we should not be testing with 20.04 in the antelope to bobcat grenade job | |
| 10:23:48 | sean-k-mooney | you are required to upgrade your host os before you can upgrade form 2023.1 -> 2023.2 | |
| 10:24:33 | sean-k-mooney | the upgrade order is zed -> 2023.1 , ubuntu 20.04 -> ubuntu 22.04, 2023.1->2023.2 | |
| 10:25:00 | sean-k-mooney | bauzas: so not only should we expect that they have alredy upgraded there python we should require it | |
| 10:26:31 | sean-k-mooney | we support one release for 2 version of the base os. that was antelope for the ubuntu 20.04 -> 22.04 transtion | |
| 10:27:34 | sean-k-mooney | bobcat does not need to supprot python 3.8 computes even with the slurp cadance nor does C | |
| 10:27:55 | sean-k-mooney | before you can do the skip lelvel upgrade you will need to upgrade the host os | |
| 10:32:18 | sean-k-mooney | actully i have some other comments on https://review.opendev.org/c/openstack/nova/+/881339 so dropign down to -1 as that patch does not remove the 3.8 support in the setup.cfg and tox | |
| 10:33:11 | sean-k-mooney | we should not drop any test coverage until all jobs are usign at least python 3.9 includign grenade | |
| 11:10:07 | elodilles | sean-k-mooney: thanks, yes, that is what i understood as well. about the patch: it's more about dropping the py38 based job, not about 'dropping py38 support of nova', but yes, i can propose a patch (on top of the original patch) that removes py38 from setup.cfg | |
| 11:11:10 | sean-k-mooney | if we claim we supprot it it should be tested | |
| 11:11:19 | sean-k-mooney | so to me droping the jobs and dropign the supprot is tied | |
| 11:12:05 | sean-k-mooney | it could be two patches but i woudl prefer to merge them together in that case | |
| 11:12:45 | sean-k-mooney | do we currently ahve a gate blocker due to tooz? | |
| 11:13:09 | sean-k-mooney | or do we have time to do this proeprly | |
| 11:18:15 | elodilles | nova-tox-functional-py38 is blocking the gate | |
| 11:19:20 | elodilles | and it seem tempest-integrated-compute-ubuntu-focal and nova-ceph-multistore as well using py38 | |
| 11:19:23 | elodilles | hmm | |