Friday, 2021-06-18

opendevreviewHYSong proposed openstack/nova master: fix vm deleted incorrectly when restoring failed  https://review.opendev.org/c/openstack/nova/+/79698502:47
opendevreviewwangzhenmeng proposed openstack/nova master: Three CPU parameters, mode, model and vendor_id, are added to flavor, some guest os do not support new CPU, so you need to specify a specific CPU when starting.  https://review.opendev.org/c/openstack/nova/+/79698603:49
*** abhishekk is now known as akekane|away05:37
*** akekane|away is now known as abhishekk05:37
opendevreviewYongli He proposed openstack/nova master: Smartnic support - cyborg drive  https://review.opendev.org/c/openstack/nova/+/77136207:01
opendevreviewYongli He proposed openstack/nova master: smartnic support - new vnic type  https://review.opendev.org/c/openstack/nova/+/77136307:01
opendevreviewYongli He proposed openstack/nova master: smartnic support  https://review.opendev.org/c/openstack/nova/+/75894407:01
opendevreviewYongli He proposed openstack/nova master: smartnic support - reject server move and suspend  https://review.opendev.org/c/openstack/nova/+/77991307:01
opendevreviewYongli He proposed openstack/nova master: smartnic support - functional tests  https://review.opendev.org/c/openstack/nova/+/78014707:01
yonglihealex_xu,  addressed comments for 'smartnic support'.07:07
*** rpittau|afk is now known as rpittau08:17
kevinzHi Nova, would be really appreciated if you can help to review this patch for live migrate on Arm64: https://review.opendev.org/c/openstack/nova/+/763928, the patch has been updated08:49
opendevreviewmelanie witt proposed openstack/placement master: Microversion 1.37: API support for consumer types  https://review.opendev.org/c/openstack/placement/+/67944108:50
opendevreviewmelanie witt proposed openstack/placement master: Switch ConsumerType to use an AttributeCache  https://review.opendev.org/c/openstack/placement/+/67948608:50
melwittgibi: just added a whackadoodle func test for the race scenario ^. I'm off tomorrow and next week so I just wanted to push this for now. still have to fix the rollback logic and address your other comments, will do that week after next08:52
melwittfeel free to reapply your -1 to flag it08:53
gibimelwitt: ack, thank. have a nice time off08:55
melwittthanks o/08:55
gibio/08:55
stephenfingibi: I've addressed your comments on https://review.opendev.org/c/openstack/nova/+/786292/ if you have time today09:15
opendevreviewLee Yarwood proposed openstack/nova stable/wallaby: Move 'check-cherry-picks' test to gate, n-v check  https://review.opendev.org/c/openstack/nova/+/79703909:48
opendevreviewLee Yarwood proposed openstack/nova stable/victoria: Move 'check-cherry-picks' test to gate, n-v check  https://review.opendev.org/c/openstack/nova/+/79704009:49
stephenfinIs it just me, or does building lower-constraints locally take, like, 5-10 minutes to run?10:24
stephenfinguess there's a lot of dependency resolution going on10:24
opendevreviewLee Yarwood proposed openstack/nova stable/ussuri: Move 'check-cherry-picks' test to gate, n-v check  https://review.opendev.org/c/openstack/nova/+/79705010:26
opendevreviewLee Yarwood proposed openstack/nova stable/train: Move 'check-cherry-picks' test to gate, n-v check  https://review.opendev.org/c/openstack/nova/+/79705210:27
lyarwoodcan't say I've tried recently but I can give it a go now10:27
stephenfinyeah, it's still ongoing here 10 minutes later10:28
* stephenfin gives it another 5 minutes before pushing to Gerrit and letting the gate take care of things 0:)10:29
gibistephenfin: it is slow to me too10:29
stephenfinaaaand it failed because it's trying to run with the default python3 version, so 3.9.5 on my host :-(10:30
opendevreviewStephen Finucane proposed openstack/nova stable/wallaby: libvirt: Delegate OVS plug to os-vif  https://review.opendev.org/c/openstack/nova/+/79044710:31
lyarwoodstephenfin: lol it failed in like 30 seconds for me because of 3.9 10:32
lyarwoodstephenfin: building greenlet right?10:33
stephenfinyup10:33
stephenfinI guess you had the packages locally already10:33
lyarwoodright so it isn't pip for you at least10:34
lyarwoodah well I guess it does that before downloading10:34
lyarwoodso maybe it is10:34
gibiyup greenlet for me too10:34
gibiit take 5 minutes on my laptop to fail10:35
lyarwoodwith 3.8 it takes ~30 seconds before tests start running10:36
opendevreviewStephen Finucane proposed openstack/nova master: tox: Encode specific Python versions  https://review.opendev.org/c/openstack/nova/+/79705410:36
lyarwoodwith a fresh .tox folder but lots cached on the host10:36
stephenfinlyarwood: gibi: ^10:36
lyarwoodstephenfin: I'm sure I suggested this in the past but gmann had reasons not to do it 10:37
stephenfinit'll be nice to be able to use the 'functional' env (vs. 'functional-py38') again10:37
lyarwoodaye10:37
lyarwoodhttps://governance.openstack.org/tc/reference/runtimes/xena.html tbh 3.9 isn't listed as a supported runtime anyway so we should really cap 10:37
stephenfinI don't see any disadvantage other than the busywork aspect I've noted10:37
stephenfinwe use 'py3' as a default env in oslo land but the oslo libs are far simpler with fewer dependencies likely to cause issues on other python versions10:38
stephenfinlyarwood: Okay, got lower-constraints working and https://review.opendev.org/c/openstack/nova/+/790447 is now passing locally. Could you take a look today or early next week? I'd ping melwitt too but she's out now10:57
stephenfinI purposefully pushed the changes up separately, so you should be able to diff PS1 and PS3 to see what I did, in case the commit message isn't clear10:58
stephenfin*changes from the master version10:58
lyarwoodstephenfin: left some quick comments, I might be missing something tbh but I don't see tests for the check_can_live_migrate_destination changes?11:32
opendevreviewsean mooney proposed openstack/nova master: Test numa and vcpu topologies bug: #1910466  https://review.opendev.org/c/openstack/nova/+/76960111:34
opendevreviewsean mooney proposed openstack/nova master: Fix max cpu topologies with numa affinity  https://review.opendev.org/c/openstack/nova/+/76961411:34
opendevreviewLee Yarwood proposed openstack/nova master: tests: Allow bindep and test-setup.sh to run on EL distros  https://review.opendev.org/c/openstack/nova/+/79642811:35
opendevreviewLee Yarwood proposed openstack/nova master: zuul: Add nova-tox-functional-centos8-py36 job  https://review.opendev.org/c/openstack/nova/+/79668411:35
sean-k-mooneywow my console is jsut being spamed by sqlacmy  warnings when i run the functional test11:38
sean-k-mooneyTypeDecoratro softDeleteInterger somethign something11:39
sean-k-mooney   /home/sean/repos/openstack/nova/nova/db/sqlalchemy/api.py:419: SAWarning: TypeDecorator SoftDeleteInteger() will not produce a cache key because the ``cache_ok`` flag is not set to True.  Set this flag to True if this type object's state is safe to use in a cache key, or False to disable this warning.11:41
sean-k-mooney  return dict(min_versions)11:41
sean-k-mooney/home/sean/repos/openstack/nova/nova/db/sqlalchemy/api.py:473: SAWarning: TypeDecorator SoftDeleteInteger() will not produce a cache key because the ``cache_ok`` flag is not set to True.  Set this flag to True if this type object's state is safe to use in a cache key, or False to disable this warning.11:41
sean-k-mooney  result = model_query(context, models.Service, read_deleted="no").\11:42
sean-k-mooneygibi: is that related to the sqlalchmey change we need to make for the latest version11:43
*** bhagyashris_ is now known as bhagyashris11:50
opendevreviewMerged openstack/nova master: Add --task-log option to nova-manage db archive_deleted_rows  https://review.opendev.org/c/openstack/nova/+/78039511:55
gibisean-k-mooney: I think this a change in sqla 1.4 that we need to adapt to12:11
gibiI had not time to look into which value should we set for cache_ok12:12
sean-k-mooneyok i guess we just set them to cache_ok=false12:12
gibithis soft delete thing is coming from oslo_db so I guess we should set the flag there12:13
gibibauzas: do you have a couple minutes to talk about the mdev spec12:38
gibi?12:38
bauzasgibi: sure, shoot12:39
gibicool12:39
gibiI think I missunderstood some port of the proposal12:39
bauzasah ? 12:39
gibitoday we have the VGPU resource class in placement12:40
gibihow do we use that if there are multiple vgpu types are enabled?12:40
bauzasgibi: two possibilities12:41
bauzasgibi: either you don't need to use types 12:41
bauzasand then even if you have multiple types, any of them will be used12:42
bauzasor, you use traits12:42
gibiI see12:42
gibiso we always represent every vgpu type as VGPU inventory in placement, and if the deployer wants to differentiate between types then he needs to use traits12:42
gibido I understand it correctly?12:44
gibiassume yes. :) 12:45
gibiso then we introduce generic mdev support12:46
bauzassorry, I was afk12:46
bauzasyes, indeed12:46
gibiand there we say each mdev type is a new CUSTOM RC12:46
gibiso if I have enabled_vgpu_types = A, B, today then both represented az VGPU inventory, but when I translate that to the new enabled_mdev_types =A, B there will be two new CUSTOM RCs?12:47
gibiso the logic changes12:47
sean-k-mooneythat is an interesting point12:48
gibiwhat is a single resource pool today, will be two separate pool tomorrow12:48
sean-k-mooneyi guess when translating we would have to map both to vgpu12:48
gibisean-k-mooney: to be able to translate we need to know which mdev type represents a vgpu12:49
gibito put them into the same pool12:49
bauzassean-k-mooney: gibi: by default, this could not change 12:49
sean-k-mooneygibi: oh kno i ment have a config option12:49
sean-k-mooneymdev_type -> RC12:49
bauzassean-k-mooney: gibi: but if the operator use a different mdev_class per type, yes12:50
sean-k-mooneybauzas: well even in th vgpu case i think ti woudl be nice to use custom RCs instead of VGPU + trait12:50
gibihm12:50
sean-k-mooneyone thing i have been wonderign is do we want to have a different mechanium to request this12:51
gibiso we can use the same mdev_class = vgpu to two different mdev type 12:51
sean-k-mooneye.g. an mdev: extra spec12:51
bauzassean-k-mooney: the config options I provided in https://review.opendev.org/c/openstack/nova-specs/+/792796/3/specs/xena/approved/generic-mdevs.rst could do this12:51
sean-k-mooneykind of like the pci alais12:52
sean-k-mooneybauzas: yes it can12:52
bauzasgibi: do you have concerns with this ?12:52
sean-k-mooneygibi: yes you would have mdev_class = vgpu in two different mdev type12:53
bauzasfor the moment, we indeed use traits for vgpu types https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#optional-provide-custom-traits-for-multiple-gpu-types12:53
gibibauzas: actually I've just relaized that my using the same mdev_class in two different types the pooling can be defined precisely12:53
lyarwoodartom / sean-k-mooney ; https://review.opendev.org/c/openstack/nova-specs/+/794799 - would you mind taking another look at this btw?12:53
gibis/my/by/12:53
bauzasgibi: if you use mdev_class='vgpu' which is the default, then you will have two inventories with the same RC12:53
gibibauzas: cool, that works for me12:54
sean-k-mooneylyarwood: sure ill take a look tat this soon after ^12:54
lyarwoodack thanks :)12:54
sean-k-mooneybauzas: i have one question though12:54
bauzasgibi: if you use other mdev_class value, you will still have two inventories but with different RCs12:54
sean-k-mooneyfrom the generic resouces:request in the flavor12:54
gibibauzas: and then what I really want is to tell the consumers of the generic mdev feature not to use to specific RC names for different types but uses custom  traits instead as that is more flexibly when you request things12:54
bauzassean-k-mooney: sure, shoot12:54
sean-k-mooneyhow are you planning to determin that a RC is an request for an MDEV to be passed through12:55
bauzasgibi: agreed12:55
gibis/to/too/12:55
bauzasgibi: we should document this12:55
gibibauzas: agreed12:55
sean-k-mooneyare you  on the compute node going to look at all the RC in the config for mdevs and then just compare to that list12:55
bauzasgibi: that's why I used the wording "class" and not "type"12:55
bauzasgibi: in theory, that's for apples vs. bananas12:56
bauzasgibi: and not about apple flavors12:56
sean-k-mooneyor should we havee a mdev_request:<RC>=<amount>,<RC>=<Amount>,... extra specs12:56
bauzassean-k-mooney: I was expecting to reuse this method, sec12:56
sean-k-mooneygibi: bauzas  would it be clear to use resouce_class instead of mdev_class in the cofnig12:57
bauzassean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L737712:57
bauzassean-k-mooney: meh, I'm not opiniated by the option name12:57
sean-k-mooneybauzas: the reason im asking is for the pci in placement spec by the way12:58
gibisean-k-mooney: I have no hard opinion about naming, if the doc is clear about that different classes results in different resource pools then I'm fine with the naming12:58
bauzassean-k-mooney: so I was expecting to look at the options to know the custom RCS12:58
sean-k-mooneyim not currently planning to support resource: syntax for pci passthough12:58
bauzassean-k-mooney: sorry, wrong method, this would be done in https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L776312:59
sean-k-mooneybauzas: ok12:59
sean-k-mooney so for consitency should i include the same capablity in the pci spec?12:59
bauzassean-k-mooney: within this method,  we would look at the known custom RCs besides the VGPU one12:59
sean-k-mooneybauzas: i can determin the classes form pci_whitelist13:00
bauzassean-k-mooney: correct, I was expecting to look at the options13:00
gibisean-k-mooney: about PCI, we have an established way to request PCI, I would not extend on that as that can cause confusion. 13:01
gibisure the PCI and the VGPU will be differnet from the flavor point of view13:01
gibibut I think that is fine13:01
sean-k-mooneyi dont really like that personally13:02
sean-k-mooneywell its more i dont really like using resouce: as the only way to requst vgpus13:02
gibiI see13:02
sean-k-mooneybut if we are supporting it for mdev i dont see why we would not support it for pci13:02
sean-k-mooneyi kind fo feel like we shoud go one way or the other13:02
gibiI agree that having 'resource:' in the flavor is a shortcut, but it is an established form for VGPU already13:03
sean-k-mooneythe resouce class basiclaly will give use the same level of indrection the pci alais has today13:03
sean-k-mooneybut without the need to configure pci aliase in the first place13:03
sean-k-mooneygibi: basically im wonderign should look to eventually remove the pci alaise and just use resouce: for pci passthough or mdev passtough in the future13:04
gibiI can accept that ^^13:04
gibithey feel pretty equal to me regarding expressivity13:05
gibibut I don't think we have to do that now. as you said, in the future :)13:05
sean-k-mooneyill at least mention it in the spec in the alternitive section as possibel future work13:05
gibithat is totally cool with me13:06
sean-k-mooneythe spec will already be split into 2 spec 1 basic passtogh 2 neutron integration  i can add 3 which is replaceing alsias with resouce: but that wont happen this cycle13:07
gibisure 13:07
gibisounds like a plan :)13:07
sean-k-mooneybauzas: so just looping back to your discussion13:08
sean-k-mooneyi think im ok with useing resouce: and just checking the config on the compute node for the RC classes13:08
sean-k-mooneyi would still prefer to use resouce_class as the config option name but thats minor13:09
sean-k-mooneyi can also live with mdev_class if we just have good help text13:09
sean-k-mooneygibi: did you have any other open question on bauzas proposal13:09
sean-k-mooneygibi: lyarwood asked first so im going to review his spec shortly but i can look at bauzas next13:10
bauzasI diverted from IRC13:11
gibisean-k-mooney, bauzas: that settles my last quesiton in the mdev spec, so I going to reply in the spec and approve it13:12
bauzasany thoughts ?13:12
bauzasack, ok13:12
sean-k-mooneyok ill try and get to https://review.opendev.org/c/openstack/nova-specs/+/794799 and https://review.opendev.org/c/openstack/nova-specs/+/792796/3/specs/xena/approved/generic-mdevs.rst in the next hour or so13:13
gibibauzas, sean-k-mooney: could you hit this small spec fix: https://review.opendev.org/c/openstack/nova-specs/+/79549313:27
sean-k-mooneygibi: i just fast approved that13:29
sean-k-mooneyoh13:29
sean-k-mooneyactully no13:29
sean-k-mooneycan you rename the file to match13:29
sean-k-mooneyit shoudl be cyborg-admin-user-client.rst13:30
gibiOK, let me fix that quickly13:30
sean-k-mooneythe move implemented spec tool use that to find the blueprint13:30
opendevreviewBalazs Gibizer proposed openstack/nova-specs master: Fix the bp link in the cyborg admin token spec  https://review.opendev.org/c/openstack/nova-specs/+/79549313:33
gibisean-k-mooney: ^^13:34
sean-k-mooneygibi++13:35
sean-k-mooneywe dont have a karma bot here but still13:35
gibisean-k-mooney: thanks13:36
gibithe happy days of doing the virtual paperwork as a PTL13:36
sean-k-mooneyat least you dont have to do it in triplicate13:36
sean-k-mooneynot today but i can proably look at adding a small script that will check for this in the ci13:37
gibigood idea13:38
gibion the CI script13:38
artomlyarwood, done13:38
sean-k-mooneyget the added filename, strip the rst, grep and see if there is a url that end with that and curl it to make sure it does not have a 40413:38
lyarwoodthanks13:43
* lyarwood drops for a few hours 13:44
stephenfinan interesting Python problem13:45
stephenfinimport json13:45
stephenfinclass Foo:13:45
stephenfin    @property13:45
stephenfin    def bar(self):13:45
stephenfin        return json.loads(self._bar)13:45
stephenfin    @bar.setter13:45
stephenfin    def bar(self, value):13:45
stephenfin        self._bar = json.dumps(value)13:45
stephenfinfoo = Foo()13:45
stephenfinfoo.bar = {}13:46
stephenfinfoo.bar['test'] = 'hello'13:46
stephenfinassert foo.bar == {'test': 'hello'}13:46
stephenfin^ that fails13:46
sean-k-mooneyyes13:46
sean-k-mooneythat is expected13:46
sean-k-mooneybut you can fix that13:46
stephenfinI get why (the setter is called for setting the attribute itself, not attributes of the attribute) but I don't know how to fix it13:46
sean-k-mooneyfoo.bar is returing a copy of the data in self._bar13:47
sean-k-mooneywhich is a dict13:47
sean-k-mooneyacn dyou cant do {} = {"key":"val"}13:47
stephenfinwell I need to fix it, because I've got a bug here https://github.com/openstack/nova/blob/master/nova/objects/migrate_data.py#L71-L8913:48
stephenfinthat's the pattern I used there and it doesn't work - the 'OS_VIF_DELEGATION' attribute of the embedded profile is never set :-(13:48
* stephenfin wonders what the functional tests in that change are actually doing13:49
sean-k-mooneyi fixed this in one of my pathces13:49
sean-k-mooneywell for the fiels i added13:49
stephenfinif you can find that I'd like to have a look at it, because right now I'm stumped13:51
sean-k-mooneyi tough tit was that to be honnest13:51
jkulikfoo.bar = foo.bar.update({'test': 'hello'}) ?13:51
jkuliktoo far off from the initial intention?13:52
sean-k-mooneyjkulik: well the fix is to inste do the update on the underling dict13:52
sean-k-mooneyso yes that works13:53
stephenfindict.update doesn't return anything, so the idea is sound but it needs a slight tweak13:54
sean-k-mooneyright not update but you read modify write13:54
gibiyepp the problem is that you have a getter and a setter but foo.bar['test'] only use the getter but not the setter :)13:54
stephenfinfoo.bar = dict(foo.bar, **{'test': 'hello'})13:54
stephenfinwill do the trick. Still not as pretty but at least it works13:55
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/objects/migrate_data.py#L81-L89 should work though13:55
stephenfingibi: Yeah. Slightly amazed that I haven't (that I can recall) hit this in all my years writing Python :D13:55
sean-k-mooneyi hit a proably with it and change it 13:55
stephenfinsean-k-mooney: the getter works, the setter does not13:55
gibiI think we need get rid of the foo.bar['aaa'] by returning a frozen dict13:55
stephenfinat least not in tests13:55
sean-k-mooneystephenfin: its suoudl this was one of the things i had to workaround when writhing tha tpatch13:56
gibias the getter returns a copy of the underlining data not a reference for it13:56
gibiso we have to tell the caller that it is copy 13:56
gibinot a live ref13:56
jkulikfrozen dict sounds good. then nobody can accidentally use the non-working pattern13:56
sean-k-mooneyfrozen dict wont work13:57
sean-k-mooneythe issue is we are storing a json string13:58
gibisean-k-mooney: it does not solve the problem, it forces the caller to avoid modifying what is returned13:58
stephenfinwell it would indicate that you can't update it13:58
sean-k-mooneyand then we are returning it as a dict and we want update to that property to modify the json13:58
sean-k-mooneygibi: right but we want them to be able to do that13:58
stephenfinhowever, there's no such thing in stdlib13:58
gibisean-k-mooney: I don't :)13:58
sean-k-mooneywell for this code we are talkign too we do13:58
sean-k-mooneyother wise we shoudl jsut remove the property13:59
sean-k-mooneyand force use to work direclty on the json13:59
opendevreviewMerged openstack/nova-specs master: Fix the bp link in the cyborg admin token spec  https://review.opendev.org/c/openstack/nova-specs/+/79549313:59
sean-k-mooneythe only reason the properties exist is to to give a dict like interface to the json blobs13:59
sean-k-mooneystephenfin: what test is failing14:00
gibisean-k-mooney: then we need to make it one level deper allowing to set per key14:00
gibilike foo.bar.test = 'aaa'14:00
stephenfinnone currently, because we don't have tests covering this code path14:00
gibisean-k-mooney: but that needs more work on the implementation side14:00
sean-k-mooneystephenfin: the quick fix is as follows14:01
sean-k-mooney self.profile[OS_VIF_DELEGATION] = supported14:01
sean-k-mooneybecomes14:01
kashyapAm I hallucinating, or were the check marks of x, ✔, and ? used to be in colour on the support-matrix page? - https://docs.openstack.org/nova/wallaby/user/support-matrix.html14:01
sean-k-mooneydata = jsonutils.loads(self.profile_json); data[OS_VIF_DELEGATION]=supported; self.profile_json = jsonutils.dumps(data);14:02
sean-k-mooneystephenfin: here https://github.com/openstack/nova/blob/master/nova/objects/migrate_data.py#L8914:02
sean-k-mooneykashyap: they were yes14:03
* kashyap nods; also the size of the check marks has reduced quite a bit; compare Queens: https://docs.openstack.org/nova/queens/user/support-matrix.html14:04
*** rpittau is now known as rpittau|afk14:09
gibistephenfin: could you please hit https://review.opendev.org/c/openstack/osc-placement/+/794276 when you have time15:14
gmannstephenfin: lyarwood if that broken on fedora having py3.9 ? but we do have py3.9 job running successfully though those are n-v15:54
gmannis that15:56
opendevreviewMerged openstack/nova master: Handle OPERATION_FAILED error during detach  https://review.opendev.org/c/openstack/nova/+/79625516:22
stephenfinlyarwood: Good thing you asked for that test. This code is doing nothing currently 😇17:15
opendevreviewStephen Finucane proposed openstack/nova master: objects: Fix VIFMigrateData.supports_os_vif_delegation setter  https://review.opendev.org/c/openstack/nova/+/79714217:15
stephenfinsean-k-mooney: ^17:15
stephenfinI haven't run those tests locally. I want to push it to the gate and see if the interfaces are correctly created in the Tempest job17:16
stephenfingmann: The main issue I was seeing is that the deps in lower-constraints don't work with Python 3.917:16
stephenfingmann: However, in the past the functional tests didn't work with Python 3.9. It could be possible that things have been fixed since17:17
stephenfingmann: However, regardless, there's no reason we should be running different things locally and in the CI. Something could conceivably pass locally (where we're using Python 3.9) but fail in the gate (using Python 3.8)17:18
stephenfingibi: done17:18
gmannstephenfin: yeah, l-c can be dropped :) which i am not much worried about. 17:18
gmannstephenfin: cases like passing py3.9 and failing py3.8 should not be much right as at next cycle we want all code to run on both17:19
gmannstephenfin: i am not against of that change to test py3.8 as default locally but it just add extra work you mentioned in commit msg17:20
stephenfinSure, but what about when Fedora introduces Python 3.1017:20
stephenfinFedora is bleeding edge, and there will always be a delay between when Fedora introduces a Python version and when nova supports it17:20
stephenfinwe already have to update setup.cfg to state our supported versions so this is minimal extra work IMO17:21
gmannyeah that is automated in release script i think and may we can add tox basepython update also..17:21
stephenfinthat would be helpful17:22
gmannstephenfin: we can merge that I am not -1 on that. I will see if we can automate in release script sometime later17:25
opendevreviewStephen Finucane proposed openstack/nova stable/wallaby: libvirt: Delegate OVS plug to os-vif  https://review.opendev.org/c/openstack/nova/+/79044717:27
opendevreviewMerged openstack/osc-placement master: default to max version when no session  https://review.opendev.org/c/openstack/osc-placement/+/79427617:30
opendevreviewStephen Finucane proposed openstack/nova stable/victoria: libvirt: Delegate OVS plug to os-vif  https://review.opendev.org/c/openstack/nova/+/79714417:39
stephenfinhmm, why can't I leave -W on stable/wallaby?17:39
stephenfinbut I can on stable/victoria17:39
gmannstephenfin: because of owner?17:48
stephenfinohhh17:49
stephenfinyeah, that's it17:49
stephenfinwhoops :)17:49

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!