| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-22 | |||
| 11:24:32 | sean-k-mooney | which they wont | |
| 11:24:49 | stephenfin | again, why? | |
| 11:24:50 | sean-k-mooney | the migration data vifs are not the same as the ones in the info cache | |
| 11:25:15 | sean-k-mooney | the ones in the info cache get rebuilt form neutron by the perodic task | |
| 11:25:26 | sean-k-mooney | or whenever we get a network-changed event | |
| 11:25:40 | sean-k-mooney | so delegate_create=True will be lost | |
| 11:25:56 | sean-k-mooney | if its ever populated in it in the first place | |
| 11:26:32 | stephenfin | ah, TIL | |
| 11:26:50 | stephenfin | okay, so I'll squash the third patch in too so | |
| 11:27:31 | sean-k-mooney | ok am can we wait for grenade to run on the 3rd patch then we can merge the second one? | |
| 11:27:39 | sean-k-mooney | i just want to make sure that it is not breaking anything | |
| 11:29:38 | stephenfin | we really need to mute that SQLAlchemy warning | |
| 11:29:44 | sean-k-mooney | yep | |
| 11:29:52 | stephenfin | I've a fix proposed to oslo.db | |
| 11:29:59 | stephenfin | https://review.opendev.org/c/openstack/oslo.db/+/797426 | |
| 11:30:00 | sean-k-mooney | ah nice | |
| 11:30:22 | sean-k-mooney | i was assuming we woudl set that to false | |
| 11:30:54 | sean-k-mooney | are we ok with caching softdelete or json data | |
| 11:31:55 | sean-k-mooney | The requirements for cacheable elements is that they are hashable and also that they indicate the same SQL rendered for expressions using this type every time for a given cache value. | |
| 11:31:57 | sean-k-mooney | ok | |
| 11:32:02 | sean-k-mooney | so ya that is correct | |
| 11:32:10 | sean-k-mooney | cache_ok applies | |
| 12:39:30 | sean-k-mooney | stephenfin: the full job suite is not finished yet but the live migration job passed and is now using ethernet so thats good to see just waiting on grenade now | |
| 12:52:07 | sean-k-mooney | gibi: gmann so intersing problem, apparently we do not validate server_group policy strings | |
| 12:52:30 | sean-k-mooney | we have never intended the server group to be user extendable right? | |
| 12:52:47 | sean-k-mooney | e.g. by using out of tree filters and weighers? | |
| 12:59:22 | sean-k-mooney | actully we do have schema validataion for thsi | |
| 12:59:24 | sean-k-mooney | https://github.com/openstack/nova/blob/5979c648462b03a2fe90148f20f099c964cdd298/nova/api/openstack/compute/schemas/server_groups.py#L22-L67 | |
| 12:59:44 | sean-k-mooney | but i guess that is not workign i need to confrim what is being repoted downstream | |
| 13:10:40 | stephenfin | sean-k-mooney: gibi: gmann: Yeah, there's a request to undo the validation of what we pass to the API in OSC because its seems someone is relying on this broken behavior https://storyboard.openstack.org/#!/story/2008975 | |
| 13:13:19 | sean-k-mooney | so i thikn we need to figure out why the json schema validation is not rejectign there request and fix that and backport it in thet api | |
| 13:14:01 | sean-k-mooney | we could have a workaround config option to disable that but this is not a valid extenion point today | |
| 13:15:01 | gibi | I agree that we should validate the policy | |
| 13:15:07 | gibi | so let's fix it | |
| 13:15:10 | gibi | and backport it | |
| 13:15:29 | gibi | I'm meh on providing the workaround config | |
| 13:15:39 | gibi | if we do that the the default should be still to validate the policy | |
| 13:15:39 | sean-k-mooney | the real question is why is the existing code not validating it when we have the json scmea files to do that and unit test that apprently are testing the validation | |
| 13:16:08 | sean-k-mooney | gibi: yep agreed if we have a config option it shoudl default to validating | |
| 13:16:25 | gibi | good question. unfortunately I have swamped with other things right now | |
| 13:57:33 | sean-k-mooney | am.... wehre do we actully do the jsonscema validation fo the api schema https://codesearch.opendev.org/?q=jsonschema&i=nope&files=&excludeFiles=&repos=openstack/nova | |
| 14:27:07 | sean-k-mooney | ah this is how we import them https://codesearch.opendev.org/?q=from%20nova.api.openstack.compute.schemas%20import&i=nope&files=nova%2Fapi&excludeFiles=&repos=openstack/nova | |
| 14:27:42 | sean-k-mooney | and this is where we use the server group schema https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/compute/server_groups.py#L26 | |
| 14:29:15 | sean-k-mooney | and this is where we apply the vlaidations https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/compute/server_groups.py#L182-L184 | |
| 14:42:56 | gibi | sean-k-mooney: there is a bug around VDPA https://bugs.launchpad.net/nova/+bug/1933096 | |
| 14:43:42 | sean-k-mooney | that should not happen | |
| 14:43:53 | sean-k-mooney | we have a version check for this | |
| 14:44:23 | sean-k-mooney | let me triple check but im pretty sure we only try to use that if libvirt is knew enouch | |
| 14:47:11 | sean-k-mooney | its used here https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/libvirt/host.py#L1338 | |
| 14:48:36 | sean-k-mooney | which is called form here https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/libvirt/vif.py#L537-L540 | |
| 14:49:03 | sean-k-mooney | i guess we dont have a libvirt verion check here | |
| 14:49:30 | sean-k-mooney | but they would only hit this if they were using a vdpa port with a version of libvirt that did not uspprot this | |
| 14:50:13 | sean-k-mooney | although form the trace it looks like this is from the perodic | |
| 14:51:07 | sean-k-mooney | which is protected by the version check | |
| 14:51:09 | sean-k-mooney | https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/libvirt/driver.py#L7346-L7349 | |
| 14:55:50 | gibi | sean-k-mooney: the bug report says they see it on libvirt 7.0.0 | |
| 14:56:00 | gibi | that would pass our version check | |
| 14:56:17 | sean-k-mooney | yep just responding i think there version fo libvirt python is older then there libvirt version | |
| 14:56:25 | sean-k-mooney | which is not supported | |
| 14:59:53 | sean-k-mooney | hum successfully installed libvirt-python-7.4.0 | |
| 14:59:56 | sean-k-mooney | that should work | |
| 15:16:27 | kashyap | The libvirt commit that introduced that _CAP_VDPA should be available from v.6.9.0 (including the Pyth bindings too): | |
| 15:16:30 | kashyap | $> git tag --sort version:refname --contains 53aec799fa31 | head -1 | |
| 15:16:32 | kashyap | v6.9.0 | |
| 15:16:33 | kashyap | (That was on libvirt Git repo) | |
| 15:21:16 | sean-k-mooney | yep next thing to check is the libvirt-python version on pypi | |
| 15:24:43 | sean-k-mooney | so "sean@p50:~/Downloads/libvirt-python-7.4.0$ grep -i VDPA -r *" should have found something but it has not | |
| 15:36:01 | opendevreview | Stephen Finucane proposed openstack/nova master: libvirt: Always delegate OVS plug to os-vif https://review.opendev.org/c/openstack/nova/+/797428 | |
| 15:53:22 | gibi | nova weekly meeting starts in 6 minutes here in the channel | |
| 16:00:05 | gibi | #startmeeting nova | |
| 16:00:05 | opendevmeet | Meeting started Tue Jun 22 16:00:05 2021 UTC and is due to finish in 60 minutes. The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:00:05 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:05 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:25 | bauzas | \o | |
| 16:00:54 | dansmith | o/ (kinda) | |
| 16:01:00 | sean-k-mooney | o/ | |
| 16:01:35 | elodilles | o/ | |
| 16:01:41 | gibi | \o | |
| 16:02:08 | alistarle | o/ | |
| 16:02:18 | gibi | #topic Bugs (stuck/critical) | |
| 16:02:25 | gibi | No critical bugs | |
| 16:02:30 | gibi | #link 21 new untriaged bugs (+7 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New | |
| 16:02:43 | stephenfin | o/ | |
| 16:02:51 | gibi | our backlog is growing so please if you have some time then look at it and triage some bugs | |
| 16:03:36 | gibi | is there any specific bug that we need to discuss now? | |
| 16:04:10 | sean-k-mooney | gibi: i am pretty sure that https://bugs.launchpad.net/nova/+bug/1933096 | |
| 16:04:16 | sean-k-mooney | is a bug in ther ci env | |
| 16:04:24 | sean-k-mooney | so hopefully we can close that soon | |
| 16:04:45 | gibi | sean-k-mooney: cool. thanks for looking into that | |
| 16:05:53 | gibi | if nothing else then | |
| 16:05:53 | gibi | #topic Gate status | |
| 16:05:58 | gibi | Nova gate bugs #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure | |
| 16:06:01 | bauzas | gibi: I'll look at open bugs | |
| 16:06:16 | gibi | bauzas: thank you | |
| 16:06:23 | gibi | I don't see fresh gate bug in that list | |
| 16:06:31 | gibi | last week we merged couple of fixes | |
| 16:06:46 | gibi | how do you feel, does the gate improved? | |
| 16:06:46 | sean-k-mooney | am any suggestions on who i should ping to move https://review.opendev.org/c/openstack/devstack/+/796826 along in devstack | |
| 16:07:06 | bauzas | thanks lyarwood btw. | |
| 16:07:13 | bauzas | for the gate failures fixes | |