| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-17 | |||
| 13:26:10 | lyarwood | given what's already in there | |
| 13:26:53 | sean-k-mooney | well given we want to evenually recored the value of all image properties and the machine_type propsoal was just a scoped down verion of that i think its a problematic design | |
| 13:27:30 | lyarwood | it wasn't a scoped down version of that at all | |
| 13:27:46 | lyarwood | I think you're crossing wires here tbh | |
| 13:27:49 | sean-k-mooney | it was ment to be | |
| 13:28:16 | lyarwood | it was always just about recording the machine type of existing instances | |
| 13:28:24 | sean-k-mooney | thats what i discussed with stephen when we were deciding if i or you would write the spec | |
| 13:28:55 | lyarwood | the image properties are part of it but not all instances will have the machine type set that way | |
| 13:29:15 | sean-k-mooney | yes i know | |
| 13:29:36 | lyarwood | this was always about capturing the currently used machine type and stashing it somewhere | |
| 13:29:43 | sean-k-mooney | yep | |
| 13:29:45 | lyarwood | allowing the config to change | |
| 13:29:58 | lyarwood | I didn't take from that the need to use the image properties | |
| 13:30:14 | lyarwood | I wasn't even planning to look at the image properties tbh | |
| 13:30:20 | lyarwood | Just the defined domains | |
| 13:30:41 | sean-k-mooney | well i had a very differnet plan for implementing it then | |
| 13:31:53 | sean-k-mooney | i will also point out form a downstream perspecitve we may need to backport this to 16.2 to support 17 upgrades | |
| 13:32:11 | sean-k-mooney | that would depend on how we handel the defualt machine type in 17/wallaby | |
| 13:32:34 | sean-k-mooney | its intended to be q35 for all new installs | |
| 13:32:47 | lyarwood | I wasn't planning on backporting this | |
| 13:32:49 | sean-k-mooney | for upgrade we need to ensure that the machine type does not change | |
| 13:32:55 | lyarwood | new installs would be q35 | |
| 13:33:01 | lyarwood | upgrades would be the old default | |
| 13:33:11 | lyarwood | until the env was fully upgraded | |
| 13:33:20 | lyarwood | and the original machine types stashed | |
| 13:33:24 | sean-k-mooney | ok but that means the ooo work is more involed but that is fine | |
| 13:33:40 | lyarwood | yeah it's a wrinkle we would need to document | |
| 13:33:48 | lyarwood | if we go with system metadata then I could backport it | |
| 13:34:01 | sean-k-mooney | yep | |
| 13:34:02 | lyarwood | so I'll take another look at that | |
| 13:41:12 | gibi | lyarwood, sean-k-mooney: I barely followed the machine type dicussion above, if your decide on a change in direction then please propose a spec update accordingly | |
| 13:42:02 | sean-k-mooney | ack im not sure it sa change in direction at elast form the ptg discussion | |
| 13:42:23 | sean-k-mooney | https://etherpad.opendev.org/p/nova-wallaby-ptg line 196 is the aggreed statement | |
| 13:42:30 | sean-k-mooney | *796 | |
| 13:43:02 | gibi | sean-k-mooney: anyhow, please keep the spec in sync with the impl : | |
| 13:43:03 | gibi | :) | |
| 13:43:15 | sean-k-mooney | but the main delta is lyarwood is going to look at using system metatdata table instead of a new column which would be a change in spec | |
| 13:43:34 | gibi | ack | |
| 13:44:24 | sean-k-mooney | i guess its tbd how easy that is but i think it shoudl be a smaller code change in general | |
| 14:08:41 | lyarwood | sean-k-mooney: sorry I can't recall why I dropped the generic record all the metadata props part of this | |
| 14:09:09 | sean-k-mooney | it was likely not in the downstream bz/dod | |
| 14:09:14 | lyarwood | sean-k-mooney: I think it might be due to that approach not capturing the config side | |
| 14:09:22 | lyarwood | sean-k-mooney: yeah or that | |
| 14:09:28 | sean-k-mooney | it was going to capture the config too | |
| 14:09:46 | sean-k-mooney | the idea was to sotre the config value in the imgage prerty filed if it was not set | |
| 14:09:57 | sean-k-mooney | but its fine to strat with just machien_type | |
| 14:10:14 | sean-k-mooney | if its easy to repate the same pattern for the other value when we need them | |
| 14:11:02 | lyarwood | yup, let me rewrite this and update the spec | |
| 14:11:33 | gibi | ^^ +1 | |
| 14:11:34 | gibi | :) | |
| 14:11:41 | gibi | on the spec side | |
| 14:11:51 | lyarwood | yup sorry about this | |
| 14:12:33 | gibi | no problem on my side | |
| 14:39:22 | openstackgerrit | YumengBao proposed openstack/nova-specs master: libvirt supports composing cyborg owned vGPU accelerator into domain XML https://review.opendev.org/c/openstack/nova-specs/+/750116 | |
| 14:40:30 | stephenfin | bauzas: any chance you could look at https://review.opendev.org/q/topic:%2522sriov-functional-tests%2522+status:open too | |
| 14:40:31 | stephenfin | ?? | |
| 14:45:16 | Yumeng | gibi: just updated vGPU spec according to today's discuss. Please help to mention in nova's meeting today so cores can know about the update! need their review and comment,Thanks! https://review.opendev.org/c/openstack/nova-specs/+/750116 | |
| 14:45:59 | gibi | Yumeng: thanks for the update. I will mention the fact that the spec needs core review on today's meeting | |
| 14:52:19 | openstackgerrit | Lance Bragstad proposed openstack/placement master: Bump oslo.log version to 4.3.0 https://review.opendev.org/c/openstack/placement/+/760229 | |
| 14:53:54 | openstackgerrit | Lance Bragstad proposed openstack/placement master: Pass context objects to oslo.policy directly https://review.opendev.org/c/openstack/placement/+/766785 | |
| 14:54:08 | openstackgerrit | Aleksey Ulyanov proposed openstack/nova master: Fix graceful shutdown timeout https://review.opendev.org/c/openstack/nova/+/764927 | |
| 15:02:33 | openstackgerrit | Lance Bragstad proposed openstack/placement master: Implement secure RBAC for resource providers https://review.opendev.org/c/openstack/placement/+/760240 | |
| 15:02:56 | openstackgerrit | Aleksey Ulyanov proposed openstack/nova master: Fix graceful shutdown timeout https://review.opendev.org/c/openstack/nova/+/764927 | |
| 15:13:34 | bauzas | Yumeng: gibi: saw the update but honestly, I won't have time for reviewing this large spec before end of this year | |
| 15:13:57 | bauzas | which is for me in 24 hours (with Friday afternoon full of meetings) | |
| 15:17:53 | gibi | bauzas: no worries | |
| 15:18:12 | gibi | Yumeng knows that we are just about to go for PTO for two weeks | |
| 15:23:42 | bauzas | gibi: actually, I lied, I just commented out loud | |
| 15:24:06 | bauzas | because I was horrified by what I saw | |
| 15:35:11 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/victoria: WIP run-evacuate-hook: Use osc to evacuate instances https://review.opendev.org/c/openstack/nova/+/767570 | |
| 15:36:12 | openstack | Launchpad bug 1823251 in OpenStack Compute (nova) "Spike in TestNovaMigrationsMySQL.test_walk_versions/test_innodb_tables failures since April 1 2019 on limestone-regionone" [High,Confirmed] | |
| 15:36:12 | gibi | sean-k-mooney: you were right and I was wrong. https://bugs.launchpad.net/nova/+bug/1823251 is a timeout issue really. Now I can reporduce it locally. | |
| 15:36:42 | sean-k-mooney | gibi: oh ok so can we do what manial did or is it different? | |
| 15:37:08 | gibi | sean-k-mooney: I think we can try what manial did, but I'm affraid at some point we will run out the time budget for the whole test run | |
| 15:37:17 | gibi | test job run | |
| 15:37:38 | sean-k-mooney | you mentioned something about scale factor in the bug | |
| 15:37:53 | gibi | yeah, we have a 160sec per test case timeout | |
| 15:37:54 | sean-k-mooney | ah self.useFixture(timeout.Timeout( | |
| 15:37:55 | sean-k-mooney | scaling_factor=self.TIMEOUT_SCALING_FACTOR)) | |
| 15:38:08 | gibi | but the mysql tests uses 4 * 160 sec | |
| 15:38:12 | gibi | and still not enough | |
| 15:38:32 | gibi | somehow the test VM is pretty IO limited | |
| 15:38:44 | sean-k-mooney | hum well they defalt to 300 second for manila | |
| 15:39:01 | sean-k-mooney | gibi: this only happens on limestone right | |
| 15:39:16 | gibi | the original report said so | |
| 15:39:24 | gibi | but I havent validated that recently | |
| 15:39:38 | sean-k-mooney | im not sure how new the hardware is, we have had io issue in the past where qos was limiting the disk to 100 IOPS on ovh? | |
| 15:45:10 | gibi | sean-k-mooney: now I see more this happening on vexxhost-ca-ymq-1 provider | |
| 15:45:34 | gibi | but maybe it is just because we run test more there | |
| 15:45:38 | gibi | i dont know | |
| 15:47:00 | gibi | hm, here is a neutron migration test with postgres failing for the same reason https://b2b5edd1153190007318-36597f05313fd3fdc073d75819a76269.ssl.cf1.rackcdn.com/766204/7/check/neutron-functional-with-uwsgi/8533ed9/job-output.txt | |
| 15:47:08 | gibi | so it is not at all nova or mysql specific | |
| 15:47:33 | gibi | they have ~ 200sec timeout | |
| 15:47:39 | sean-k-mooney | ya it proably affect all project with a lot of migrations | |
| 15:47:48 | gibi | (nova has 160 for the api db test, and 640 for the nova db test) | |
| 15:47:53 | sean-k-mooney | stephenfin's patch shoudl help with that | |
| 15:48:15 | gibi | the squashing migration one? | |
| 15:48:21 | sean-k-mooney | yep | |
| 15:48:28 | sean-k-mooney | stephenfin: have you pushed that yet ^ | |
| 15:50:17 | gibi | nova meeting starts in 10 minutes... | |