Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-04-21
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 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: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: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
11:20:12 sean-k-mooney we can correct the tempest jobs by defining the python version in devstack to be 3.9 or 3.10
11:20:23 sean-k-mooney both are avaiabel on 20.04
11:21:11 elodilles ack, i'll add that to the patch

Earlier   Later