opendevreview | HYSong proposed openstack/nova master: fix vm deleted incorrectly when restoring failed https://review.opendev.org/c/openstack/nova/+/796985 | 02:47 |
---|---|---|
opendevreview | wangzhenmeng 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/+/796986 | 03:49 |
*** abhishekk is now known as akekane|away | 05:37 | |
*** akekane|away is now known as abhishekk | 05:37 | |
opendevreview | Yongli He proposed openstack/nova master: Smartnic support - cyborg drive https://review.opendev.org/c/openstack/nova/+/771362 | 07:01 |
opendevreview | Yongli He proposed openstack/nova master: smartnic support - new vnic type https://review.opendev.org/c/openstack/nova/+/771363 | 07:01 |
opendevreview | Yongli He proposed openstack/nova master: smartnic support https://review.opendev.org/c/openstack/nova/+/758944 | 07:01 |
opendevreview | Yongli He proposed openstack/nova master: smartnic support - reject server move and suspend https://review.opendev.org/c/openstack/nova/+/779913 | 07:01 |
opendevreview | Yongli He proposed openstack/nova master: smartnic support - functional tests https://review.opendev.org/c/openstack/nova/+/780147 | 07:01 |
yonglihe | alex_xu, addressed comments for 'smartnic support'. | 07:07 |
*** rpittau|afk is now known as rpittau | 08:17 | |
kevinz | Hi 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 updated | 08:49 |
opendevreview | melanie witt proposed openstack/placement master: Microversion 1.37: API support for consumer types https://review.opendev.org/c/openstack/placement/+/679441 | 08:50 |
opendevreview | melanie witt proposed openstack/placement master: Switch ConsumerType to use an AttributeCache https://review.opendev.org/c/openstack/placement/+/679486 | 08:50 |
melwitt | gibi: 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 next | 08:52 |
melwitt | feel free to reapply your -1 to flag it | 08:53 |
gibi | melwitt: ack, thank. have a nice time off | 08:55 |
melwitt | thanks o/ | 08:55 |
gibi | o/ | 08:55 |
stephenfin | gibi: I've addressed your comments on https://review.opendev.org/c/openstack/nova/+/786292/ if you have time today | 09:15 |
opendevreview | Lee Yarwood proposed openstack/nova stable/wallaby: Move 'check-cherry-picks' test to gate, n-v check https://review.opendev.org/c/openstack/nova/+/797039 | 09:48 |
opendevreview | Lee Yarwood proposed openstack/nova stable/victoria: Move 'check-cherry-picks' test to gate, n-v check https://review.opendev.org/c/openstack/nova/+/797040 | 09:49 |
stephenfin | Is it just me, or does building lower-constraints locally take, like, 5-10 minutes to run? | 10:24 |
stephenfin | guess there's a lot of dependency resolution going on | 10:24 |
opendevreview | Lee Yarwood proposed openstack/nova stable/ussuri: Move 'check-cherry-picks' test to gate, n-v check https://review.opendev.org/c/openstack/nova/+/797050 | 10:26 |
opendevreview | Lee Yarwood proposed openstack/nova stable/train: Move 'check-cherry-picks' test to gate, n-v check https://review.opendev.org/c/openstack/nova/+/797052 | 10:27 |
lyarwood | can't say I've tried recently but I can give it a go now | 10:27 |
stephenfin | yeah, it's still ongoing here 10 minutes later | 10:28 |
* stephenfin gives it another 5 minutes before pushing to Gerrit and letting the gate take care of things 0:) | 10:29 | |
gibi | stephenfin: it is slow to me too | 10:29 |
stephenfin | aaaand it failed because it's trying to run with the default python3 version, so 3.9.5 on my host :-( | 10:30 |
opendevreview | Stephen Finucane proposed openstack/nova stable/wallaby: libvirt: Delegate OVS plug to os-vif https://review.opendev.org/c/openstack/nova/+/790447 | 10:31 |
lyarwood | stephenfin: lol it failed in like 30 seconds for me because of 3.9 | 10:32 |
lyarwood | stephenfin: building greenlet right? | 10:33 |
stephenfin | yup | 10:33 |
stephenfin | I guess you had the packages locally already | 10:33 |
lyarwood | right so it isn't pip for you at least | 10:34 |
lyarwood | ah well I guess it does that before downloading | 10:34 |
lyarwood | so maybe it is | 10:34 |
gibi | yup greenlet for me too | 10:34 |
gibi | it take 5 minutes on my laptop to fail | 10:35 |
lyarwood | with 3.8 it takes ~30 seconds before tests start running | 10:36 |
opendevreview | Stephen Finucane proposed openstack/nova master: tox: Encode specific Python versions https://review.opendev.org/c/openstack/nova/+/797054 | 10:36 |
lyarwood | with a fresh .tox folder but lots cached on the host | 10:36 |
stephenfin | lyarwood: gibi: ^ | 10:36 |
lyarwood | stephenfin: I'm sure I suggested this in the past but gmann had reasons not to do it | 10:37 |
stephenfin | it'll be nice to be able to use the 'functional' env (vs. 'functional-py38') again | 10:37 |
lyarwood | aye | 10:37 |
lyarwood | https://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 |
stephenfin | I don't see any disadvantage other than the busywork aspect I've noted | 10:37 |
stephenfin | we 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 versions | 10:38 |
stephenfin | lyarwood: 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 now | 10:57 |
stephenfin | I 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 clear | 10:58 |
stephenfin | *changes from the master version | 10:58 |
lyarwood | stephenfin: 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 |
opendevreview | sean mooney proposed openstack/nova master: Test numa and vcpu topologies bug: #1910466 https://review.opendev.org/c/openstack/nova/+/769601 | 11:34 |
opendevreview | sean mooney proposed openstack/nova master: Fix max cpu topologies with numa affinity https://review.opendev.org/c/openstack/nova/+/769614 | 11:34 |
opendevreview | Lee Yarwood proposed openstack/nova master: tests: Allow bindep and test-setup.sh to run on EL distros https://review.opendev.org/c/openstack/nova/+/796428 | 11:35 |
opendevreview | Lee Yarwood proposed openstack/nova master: zuul: Add nova-tox-functional-centos8-py36 job https://review.opendev.org/c/openstack/nova/+/796684 | 11:35 |
sean-k-mooney | wow my console is jsut being spamed by sqlacmy warnings when i run the functional test | 11:38 |
sean-k-mooney | TypeDecoratro softDeleteInterger somethign something | 11: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-mooney | gibi: is that related to the sqlalchmey change we need to make for the latest version | 11:43 |
*** bhagyashris_ is now known as bhagyashris | 11:50 | |
opendevreview | Merged openstack/nova master: Add --task-log option to nova-manage db archive_deleted_rows https://review.opendev.org/c/openstack/nova/+/780395 | 11:55 |
gibi | sean-k-mooney: I think this a change in sqla 1.4 that we need to adapt to | 12:11 |
gibi | I had not time to look into which value should we set for cache_ok | 12:12 |
sean-k-mooney | ok i guess we just set them to cache_ok=false | 12:12 |
gibi | this soft delete thing is coming from oslo_db so I guess we should set the flag there | 12:13 |
gibi | bauzas: do you have a couple minutes to talk about the mdev spec | 12:38 |
gibi | ? | 12:38 |
bauzas | gibi: sure, shoot | 12:39 |
gibi | cool | 12:39 |
gibi | I think I missunderstood some port of the proposal | 12:39 |
bauzas | ah ? | 12:39 |
gibi | today we have the VGPU resource class in placement | 12:40 |
gibi | how do we use that if there are multiple vgpu types are enabled? | 12:40 |
bauzas | gibi: two possibilities | 12:41 |
bauzas | gibi: either you don't need to use types | 12:41 |
bauzas | and then even if you have multiple types, any of them will be used | 12:42 |
bauzas | or, you use traits | 12:42 |
gibi | I see | 12:42 |
gibi | so 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 traits | 12:42 |
gibi | do I understand it correctly? | 12:44 |
gibi | assume yes. :) | 12:45 |
gibi | so then we introduce generic mdev support | 12:46 |
bauzas | sorry, I was afk | 12:46 |
bauzas | yes, indeed | 12:46 |
gibi | and there we say each mdev type is a new CUSTOM RC | 12:46 |
gibi | so 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 |
gibi | so the logic changes | 12:47 |
sean-k-mooney | that is an interesting point | 12:48 |
gibi | what is a single resource pool today, will be two separate pool tomorrow | 12:48 |
sean-k-mooney | i guess when translating we would have to map both to vgpu | 12:48 |
gibi | sean-k-mooney: to be able to translate we need to know which mdev type represents a vgpu | 12:49 |
gibi | to put them into the same pool | 12:49 |
bauzas | sean-k-mooney: gibi: by default, this could not change | 12:49 |
sean-k-mooney | gibi: oh kno i ment have a config option | 12:49 |
sean-k-mooney | mdev_type -> RC | 12:49 |
bauzas | sean-k-mooney: gibi: but if the operator use a different mdev_class per type, yes | 12:50 |
sean-k-mooney | bauzas: well even in th vgpu case i think ti woudl be nice to use custom RCs instead of VGPU + trait | 12:50 |
gibi | hm | 12:50 |
sean-k-mooney | one thing i have been wonderign is do we want to have a different mechanium to request this | 12:51 |
gibi | so we can use the same mdev_class = vgpu to two different mdev type | 12:51 |
sean-k-mooney | e.g. an mdev: extra spec | 12:51 |
bauzas | sean-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 this | 12:51 |
sean-k-mooney | kind of like the pci alais | 12:52 |
sean-k-mooney | bauzas: yes it can | 12:52 |
bauzas | gibi: do you have concerns with this ? | 12:52 |
sean-k-mooney | gibi: yes you would have mdev_class = vgpu in two different mdev type | 12:53 |
bauzas | for 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-types | 12:53 |
gibi | bauzas: actually I've just relaized that my using the same mdev_class in two different types the pooling can be defined precisely | 12:53 |
lyarwood | artom / sean-k-mooney ; https://review.opendev.org/c/openstack/nova-specs/+/794799 - would you mind taking another look at this btw? | 12:53 |
gibi | s/my/by/ | 12:53 |
bauzas | gibi: if you use mdev_class='vgpu' which is the default, then you will have two inventories with the same RC | 12:53 |
gibi | bauzas: cool, that works for me | 12:54 |
sean-k-mooney | lyarwood: sure ill take a look tat this soon after ^ | 12:54 |
lyarwood | ack thanks :) | 12:54 |
sean-k-mooney | bauzas: i have one question though | 12:54 |
bauzas | gibi: if you use other mdev_class value, you will still have two inventories but with different RCs | 12:54 |
sean-k-mooney | from the generic resouces:request in the flavor | 12:54 |
gibi | bauzas: 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 things | 12:54 |
bauzas | sean-k-mooney: sure, shoot | 12:54 |
sean-k-mooney | how are you planning to determin that a RC is an request for an MDEV to be passed through | 12:55 |
bauzas | gibi: agreed | 12:55 |
gibi | s/to/too/ | 12:55 |
bauzas | gibi: we should document this | 12:55 |
gibi | bauzas: agreed | 12:55 |
sean-k-mooney | are you on the compute node going to look at all the RC in the config for mdevs and then just compare to that list | 12:55 |
bauzas | gibi: that's why I used the wording "class" and not "type" | 12:55 |
bauzas | gibi: in theory, that's for apples vs. bananas | 12:56 |
bauzas | gibi: and not about apple flavors | 12:56 |
sean-k-mooney | or should we havee a mdev_request:<RC>=<amount>,<RC>=<Amount>,... extra specs | 12:56 |
bauzas | sean-k-mooney: I was expecting to reuse this method, sec | 12:56 |
sean-k-mooney | gibi: bauzas would it be clear to use resouce_class instead of mdev_class in the cofnig | 12:57 |
bauzas | sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7377 | 12:57 |
bauzas | sean-k-mooney: meh, I'm not opiniated by the option name | 12:57 |
sean-k-mooney | bauzas: the reason im asking is for the pci in placement spec by the way | 12:58 |
gibi | sean-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 naming | 12:58 |
bauzas | sean-k-mooney: so I was expecting to look at the options to know the custom RCS | 12:58 |
sean-k-mooney | im not currently planning to support resource: syntax for pci passthough | 12:58 |
bauzas | sean-k-mooney: sorry, wrong method, this would be done in https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7763 | 12:59 |
sean-k-mooney | bauzas: ok | 12:59 |
sean-k-mooney | so for consitency should i include the same capablity in the pci spec? | 12:59 |
bauzas | sean-k-mooney: within this method, we would look at the known custom RCs besides the VGPU one | 12:59 |
sean-k-mooney | bauzas: i can determin the classes form pci_whitelist | 13:00 |
bauzas | sean-k-mooney: correct, I was expecting to look at the options | 13:00 |
gibi | sean-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 |
gibi | sure the PCI and the VGPU will be differnet from the flavor point of view | 13:01 |
gibi | but I think that is fine | 13:01 |
sean-k-mooney | i dont really like that personally | 13:02 |
sean-k-mooney | well its more i dont really like using resouce: as the only way to requst vgpus | 13:02 |
gibi | I see | 13:02 |
sean-k-mooney | but if we are supporting it for mdev i dont see why we would not support it for pci | 13:02 |
sean-k-mooney | i kind fo feel like we shoud go one way or the other | 13:02 |
gibi | I agree that having 'resource:' in the flavor is a shortcut, but it is an established form for VGPU already | 13:03 |
sean-k-mooney | the resouce class basiclaly will give use the same level of indrection the pci alais has today | 13:03 |
sean-k-mooney | but without the need to configure pci aliase in the first place | 13:03 |
sean-k-mooney | gibi: basically im wonderign should look to eventually remove the pci alaise and just use resouce: for pci passthough or mdev passtough in the future | 13:04 |
gibi | I can accept that ^^ | 13:04 |
gibi | they feel pretty equal to me regarding expressivity | 13:05 |
gibi | but I don't think we have to do that now. as you said, in the future :) | 13:05 |
sean-k-mooney | ill at least mention it in the spec in the alternitive section as possibel future work | 13:05 |
gibi | that is totally cool with me | 13:06 |
sean-k-mooney | the 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 cycle | 13:07 |
gibi | sure | 13:07 |
gibi | sounds like a plan :) | 13:07 |
sean-k-mooney | bauzas: so just looping back to your discussion | 13:08 |
sean-k-mooney | i think im ok with useing resouce: and just checking the config on the compute node for the RC classes | 13:08 |
sean-k-mooney | i would still prefer to use resouce_class as the config option name but thats minor | 13:09 |
sean-k-mooney | i can also live with mdev_class if we just have good help text | 13:09 |
sean-k-mooney | gibi: did you have any other open question on bauzas proposal | 13:09 |
sean-k-mooney | gibi: lyarwood asked first so im going to review his spec shortly but i can look at bauzas next | 13:10 |
bauzas | I diverted from IRC | 13:11 |
gibi | sean-k-mooney, bauzas: that settles my last quesiton in the mdev spec, so I going to reply in the spec and approve it | 13:12 |
bauzas | any thoughts ? | 13:12 |
bauzas | ack, ok | 13:12 |
sean-k-mooney | ok 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 so | 13:13 |
gibi | bauzas, sean-k-mooney: could you hit this small spec fix: https://review.opendev.org/c/openstack/nova-specs/+/795493 | 13:27 |
sean-k-mooney | gibi: i just fast approved that | 13:29 |
sean-k-mooney | oh | 13:29 |
sean-k-mooney | actully no | 13:29 |
sean-k-mooney | can you rename the file to match | 13:29 |
sean-k-mooney | it shoudl be cyborg-admin-user-client.rst | 13:30 |
gibi | OK, let me fix that quickly | 13:30 |
sean-k-mooney | the move implemented spec tool use that to find the blueprint | 13:30 |
opendevreview | Balazs Gibizer proposed openstack/nova-specs master: Fix the bp link in the cyborg admin token spec https://review.opendev.org/c/openstack/nova-specs/+/795493 | 13:33 |
gibi | sean-k-mooney: ^^ | 13:34 |
sean-k-mooney | gibi++ | 13:35 |
sean-k-mooney | we dont have a karma bot here but still | 13:35 |
gibi | sean-k-mooney: thanks | 13:36 |
gibi | the happy days of doing the virtual paperwork as a PTL | 13:36 |
sean-k-mooney | at least you dont have to do it in triplicate | 13:36 |
sean-k-mooney | not today but i can proably look at adding a small script that will check for this in the ci | 13:37 |
gibi | good idea | 13:38 |
gibi | on the CI script | 13:38 |
artom | lyarwood, done | 13:38 |
sean-k-mooney | get 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 404 | 13:38 |
lyarwood | thanks | 13:43 |
* lyarwood drops for a few hours | 13:44 | |
stephenfin | an interesting Python problem | 13:45 |
stephenfin | import json | 13:45 |
stephenfin | class Foo: | 13:45 |
stephenfin | @property | 13:45 |
stephenfin | def bar(self): | 13:45 |
stephenfin | return json.loads(self._bar) | 13:45 |
stephenfin | @bar.setter | 13:45 |
stephenfin | def bar(self, value): | 13:45 |
stephenfin | self._bar = json.dumps(value) | 13:45 |
stephenfin | foo = Foo() | 13:45 |
stephenfin | foo.bar = {} | 13:46 |
stephenfin | foo.bar['test'] = 'hello' | 13:46 |
stephenfin | assert foo.bar == {'test': 'hello'} | 13:46 |
stephenfin | ^ that fails | 13:46 |
sean-k-mooney | yes | 13:46 |
sean-k-mooney | that is expected | 13:46 |
sean-k-mooney | but you can fix that | 13:46 |
stephenfin | I get why (the setter is called for setting the attribute itself, not attributes of the attribute) but I don't know how to fix it | 13:46 |
sean-k-mooney | foo.bar is returing a copy of the data in self._bar | 13:47 |
sean-k-mooney | which is a dict | 13:47 |
sean-k-mooney | acn dyou cant do {} = {"key":"val"} | 13:47 |
stephenfin | well 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-L89 | 13:48 |
stephenfin | that'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 doing | 13:49 | |
sean-k-mooney | i fixed this in one of my pathces | 13:49 |
sean-k-mooney | well for the fiels i added | 13:49 |
stephenfin | if you can find that I'd like to have a look at it, because right now I'm stumped | 13:51 |
sean-k-mooney | i tough tit was that to be honnest | 13:51 |
jkulik | foo.bar = foo.bar.update({'test': 'hello'}) ? | 13:51 |
jkulik | too far off from the initial intention? | 13:52 |
sean-k-mooney | jkulik: well the fix is to inste do the update on the underling dict | 13:52 |
sean-k-mooney | so yes that works | 13:53 |
stephenfin | dict.update doesn't return anything, so the idea is sound but it needs a slight tweak | 13:54 |
sean-k-mooney | right not update but you read modify write | 13:54 |
gibi | yepp 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 |
stephenfin | foo.bar = dict(foo.bar, **{'test': 'hello'}) | 13:54 |
stephenfin | will do the trick. Still not as pretty but at least it works | 13:55 |
sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/objects/migrate_data.py#L81-L89 should work though | 13:55 |
stephenfin | gibi: Yeah. Slightly amazed that I haven't (that I can recall) hit this in all my years writing Python :D | 13:55 |
sean-k-mooney | i hit a proably with it and change it | 13:55 |
stephenfin | sean-k-mooney: the getter works, the setter does not | 13:55 |
gibi | I think we need get rid of the foo.bar['aaa'] by returning a frozen dict | 13:55 |
stephenfin | at least not in tests | 13:55 |
sean-k-mooney | stephenfin: its suoudl this was one of the things i had to workaround when writhing tha tpatch | 13:56 |
gibi | as the getter returns a copy of the underlining data not a reference for it | 13:56 |
gibi | so we have to tell the caller that it is copy | 13:56 |
gibi | not a live ref | 13:56 |
jkulik | frozen dict sounds good. then nobody can accidentally use the non-working pattern | 13:56 |
sean-k-mooney | frozen dict wont work | 13:57 |
sean-k-mooney | the issue is we are storing a json string | 13:58 |
gibi | sean-k-mooney: it does not solve the problem, it forces the caller to avoid modifying what is returned | 13:58 |
stephenfin | well it would indicate that you can't update it | 13:58 |
sean-k-mooney | and then we are returning it as a dict and we want update to that property to modify the json | 13:58 |
sean-k-mooney | gibi: right but we want them to be able to do that | 13:58 |
stephenfin | however, there's no such thing in stdlib | 13:58 |
gibi | sean-k-mooney: I don't :) | 13:58 |
sean-k-mooney | well for this code we are talkign too we do | 13:58 |
sean-k-mooney | other wise we shoudl jsut remove the property | 13:59 |
sean-k-mooney | and force use to work direclty on the json | 13:59 |
opendevreview | Merged openstack/nova-specs master: Fix the bp link in the cyborg admin token spec https://review.opendev.org/c/openstack/nova-specs/+/795493 | 13:59 |
sean-k-mooney | the only reason the properties exist is to to give a dict like interface to the json blobs | 13:59 |
sean-k-mooney | stephenfin: what test is failing | 14:00 |
gibi | sean-k-mooney: then we need to make it one level deper allowing to set per key | 14:00 |
gibi | like foo.bar.test = 'aaa' | 14:00 |
stephenfin | none currently, because we don't have tests covering this code path | 14:00 |
gibi | sean-k-mooney: but that needs more work on the implementation side | 14:00 |
sean-k-mooney | stephenfin: the quick fix is as follows | 14:01 |
sean-k-mooney | self.profile[OS_VIF_DELEGATION] = supported | 14:01 |
sean-k-mooney | becomes | 14:01 |
kashyap | Am 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.html | 14:01 |
sean-k-mooney | data = jsonutils.loads(self.profile_json); data[OS_VIF_DELEGATION]=supported; self.profile_json = jsonutils.dumps(data); | 14:02 |
sean-k-mooney | stephenfin: here https://github.com/openstack/nova/blob/master/nova/objects/migrate_data.py#L89 | 14:02 |
sean-k-mooney | kashyap: they were yes | 14: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.html | 14:04 | |
*** rpittau is now known as rpittau|afk | 14:09 | |
gibi | stephenfin: could you please hit https://review.opendev.org/c/openstack/osc-placement/+/794276 when you have time | 15:14 |
gmann | stephenfin: lyarwood if that broken on fedora having py3.9 ? but we do have py3.9 job running successfully though those are n-v | 15:54 |
gmann | is that | 15:56 |
opendevreview | Merged openstack/nova master: Handle OPERATION_FAILED error during detach https://review.opendev.org/c/openstack/nova/+/796255 | 16:22 |
stephenfin | lyarwood: Good thing you asked for that test. This code is doing nothing currently 😇 | 17:15 |
opendevreview | Stephen Finucane proposed openstack/nova master: objects: Fix VIFMigrateData.supports_os_vif_delegation setter https://review.opendev.org/c/openstack/nova/+/797142 | 17:15 |
stephenfin | sean-k-mooney: ^ | 17:15 |
stephenfin | I 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 job | 17:16 |
stephenfin | gmann: The main issue I was seeing is that the deps in lower-constraints don't work with Python 3.9 | 17:16 |
stephenfin | gmann: However, in the past the functional tests didn't work with Python 3.9. It could be possible that things have been fixed since | 17:17 |
stephenfin | gmann: 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 |
stephenfin | gibi: done | 17:18 |
gmann | stephenfin: yeah, l-c can be dropped :) which i am not much worried about. | 17:18 |
gmann | stephenfin: 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 both | 17:19 |
gmann | stephenfin: i am not against of that change to test py3.8 as default locally but it just add extra work you mentioned in commit msg | 17:20 |
stephenfin | Sure, but what about when Fedora introduces Python 3.10 | 17:20 |
stephenfin | Fedora is bleeding edge, and there will always be a delay between when Fedora introduces a Python version and when nova supports it | 17:20 |
stephenfin | we already have to update setup.cfg to state our supported versions so this is minimal extra work IMO | 17:21 |
gmann | yeah that is automated in release script i think and may we can add tox basepython update also.. | 17:21 |
stephenfin | that would be helpful | 17:22 |
gmann | stephenfin: we can merge that I am not -1 on that. I will see if we can automate in release script sometime later | 17:25 |
opendevreview | Stephen Finucane proposed openstack/nova stable/wallaby: libvirt: Delegate OVS plug to os-vif https://review.opendev.org/c/openstack/nova/+/790447 | 17:27 |
opendevreview | Merged openstack/osc-placement master: default to max version when no session https://review.opendev.org/c/openstack/osc-placement/+/794276 | 17:30 |
opendevreview | Stephen Finucane proposed openstack/nova stable/victoria: libvirt: Delegate OVS plug to os-vif https://review.opendev.org/c/openstack/nova/+/797144 | 17:39 |
stephenfin | hmm, why can't I leave -W on stable/wallaby? | 17:39 |
stephenfin | but I can on stable/victoria | 17:39 |
gmann | stephenfin: because of owner? | 17:48 |
stephenfin | ohhh | 17:49 |
stephenfin | yeah, that's it | 17:49 |
stephenfin | whoops :) | 17:49 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!