Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-04-21
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 :)
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

Earlier   Later