| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-18 | |||
| 17:50:49 | sean-k-mooney | so i assume the latter | |
| 18:04:50 | bauzas | apart from Antelope, don't know the other options meanings. | |
| 18:05:40 | bauzas | this cycle, looks like the names are more misunderstandable than the other times | |
| 18:06:10 | bauzas | Wallaby, Xena, Yoga, Zed, all of those were meaningful for a non-native speaker | |
| 18:06:47 | sean-k-mooney | Xena is the best warrior princess :) | |
| 18:07:15 | bauzas | that's also why I thought geonamings were better | |
| 18:07:36 | bauzas | except rare situations, in general those were understandable by anyone | |
| 18:07:51 | sean-k-mooney | train choo choo | |
| 18:09:09 | bauzas | so we have to pick between 3 animals? ok | |
| 18:10:56 | melwitt | ew, hope not Beetle | |
| 18:11:09 | sean-k-mooney | we shoudl go with pizza toppings | |
| 18:11:10 | melwitt | Bear | |
| 18:11:26 | sean-k-mooney | and then wait for the flame ware wehn we get to pineapple | |
| 18:11:41 | bauzas | sean-k-mooney: love the idea | |
| 18:11:43 | melwitt | that would be pretty funny | |
| 18:12:15 | bauzas | but before Pineapple, people would have to be convinced Oyster can be a good name | |
| 18:12:18 | sean-k-mooney | pepperoni vs pineapple | |
| 18:12:33 | sean-k-mooney | i can see the devisions formaing already | |
| 18:13:06 | bauzas | bon appetit https://oyster-obsession.com/category/oyster-recipes/oyster-pizza-recipes/ | |
| 18:13:09 | melwitt | 😂 | |
| 18:14:06 | sean-k-mooney | i have heard worse ideas | |
| 18:14:23 | bauzas | for B, easy peasy : Blue cheese | |
| 18:16:51 | sean-k-mooney | see worse idea ^ for pizza toping then oysters | |
| 18:18:29 | bauzas | oysters and blue cheese always match | |
| 18:25:17 | sean-k-mooney | my home town makes blue chseese its even somewhat famous but i never really liked blue cheese | |
| 18:26:06 | sean-k-mooney | https://en.wikipedia.org/wiki/J%26L_Grubb | |
| 18:59:57 | opendevreview | Merged openstack/nova master: Remove unused requirement https://review.opendev.org/c/openstack/nova/+/850006 | |
| 19:07:13 | colby_ | bauzas: I worked with sean-k-mooney last week on our vgpu issue. I created a bug: https://bugs.launchpad.net/nova/+bug/1981631. Im happy to provide any info needed. I did some debugging by logging variables and its definitely trying to use a new resource_provider(pci address) instead of one of the ones already created | |
| 19:19:04 | opendevreview | Merged openstack/nova master: Fix compatibility with jsonschema 4.x https://review.opendev.org/c/openstack/nova/+/849867 | |
| 19:40:29 | spatel | is devstack support centos-8 stream? | |
| #openstack-nova - 2022-07-19 | |||
| 07:48:12 | bauzas | morning Nova | |
| 08:13:32 | gibi | o/ | |
| 08:48:55 | opendevreview | Merged openstack/nova master: Adds link in releasenotes for hw machine type bug https://review.opendev.org/c/openstack/nova/+/849532 | |
| 08:51:13 | stephenfin | morning, I need another +2 on dtantsur's patch here https://review.opendev.org/c/openstack/nova/+/849881 | |
| 08:51:30 | stephenfin | to hopefully finally unblock jsonschema 4.x | |
| 09:00:38 | gibi | sean-k-mooney[m]: done | |
| 09:00:40 | gibi | sorry | |
| 09:00:42 | gibi | stephenfin: done | |
| 09:14:13 | stephenfin | gibi: thanks | |
| 09:22:44 | opendevreview | Merged openstack/nova master: Add a proper schema version to network_data.json https://review.opendev.org/c/openstack/nova/+/849881 | |
| 09:49:22 | bauzas | Uggla: lemme know when you have time to respin https://review.opendev.org/c/openstack/nova/+/845897 | |
| 09:50:20 | Uggla | bauzas, yep I will look at it beginning of the afternoon. ok for you ? | |
| 09:51:09 | bauzas | Uggla: cool, I already uploaded my series using the 2.92 microversion so I'll only fix some simple merge conflicts https://review.opendev.org/c/openstack/nova/+/849133 | |
| 09:51:27 | bauzas | sean-k-mooney: I found a way to have a regression test for https://bugs.launchpad.net/nova/+bug/1951656 | |
| 09:51:45 | sean-k-mooney | bauzas: that great | |
| 09:51:45 | bauzas | I'll upload it | |
| 09:52:11 | sean-k-mooney | i did not have time to try and create one myslef but i hoped it woudl be possibel without too much work | |
| 09:52:35 | sean-k-mooney | bauzas: with that regression did you also obseve the breakage of the reuse of freed mdevs | |
| 09:52:58 | sean-k-mooney | my guess is the list of aviable free mdevs was empty | |
| 09:53:05 | bauzas | yes | |
| 09:53:07 | sean-k-mooney | so we always tried to alocate | |
| 09:53:20 | bauzas | so the inventory is getting less | |
| 09:53:44 | sean-k-mooney | well thats good that we have a repoducer now | |
| 09:53:52 | sean-k-mooney | it should aid in fixing and backporting | |
| 09:56:57 | gibi | sean-k-mooney, bauzas: can we quickly discuss the force down requirement in https://review.opendev.org/c/openstack/nova/+/848886 ? | |
| 09:57:22 | gibi | sean-k-mooney: could you elaborate on the data corruption risk. is it depends on the task state? | |
| 09:59:04 | sean-k-mooney | well my ortinal concern was we were in the midel of doing an operation | |
| 09:59:12 | sean-k-mooney | it could be a snapshot for example | |
| 09:59:25 | sean-k-mooney | and depending on the backend we do strange thigns with say nfs | |
| 09:59:44 | sean-k-mooney | so im not sure how safe it is to always ignore it | |
| 10:00:34 | sean-k-mooney | like for nfs cinder volume snapshots we create a delta disks and update some paths in the xml and on the cidner side | |
| 10:00:49 | sean-k-mooney | if we evaucate in the midel of that i dont knwo what the sate will be | |
| 10:01:00 | sean-k-mooney | same for ceph i guess | |
| 10:01:06 | sean-k-mooney | in this case its just powering off | |
| 10:01:22 | sean-k-mooney | which shoudl be fine because we allow eveac with active vms | |
| 10:02:10 | gibi | ohh so the case is when the task was actually started by the compute service, then the compute service died. leaving a half uploaded snapshot or leaving a not fully updated geust xml behind | |
| 10:02:32 | sean-k-mooney | ya or if we were shelving ectra | |
| 10:02:49 | sean-k-mooney | basically if we are in the midel fo an operation im not sure what will happen | |
| 10:02:55 | sean-k-mooney | maybe its fine to evacuate | |
| 10:03:07 | sean-k-mooney | but we dont allwo that today | |
| 10:03:11 | gibi | so if that is the case then simply asking the admin to fence + force down before evac is not enough, the admin manually needs to clean up / repair things | |
| 10:03:29 | sean-k-mooney | ya i guess that is true | |
| 10:03:35 | gibi | right now force down only requires fencing | |
| 10:03:41 | sean-k-mooney | yes | |
| 10:03:46 | gibi | but going forward it will required a manual check by the admin | |
| 10:03:52 | gibi | and we need to be able to describe what to check | |
| 10:04:00 | sean-k-mooney | so i guess it really does not help in that respect | |
| 10:04:16 | sean-k-mooney | (force down) | |
| 10:04:40 | sean-k-mooney | i guess we are starting form this is blocked and you have to do reset-state | |
| 10:04:46 | sean-k-mooney | to evacuate | |
| 10:04:50 | gibi | yeah, it is convinient to push the responsibility to the admin by asking to force down, but we have to be able to tell the admin what to do before force down | |
| 10:05:47 | sean-k-mooney | if the node is down say psu exploded | |
| 10:05:59 | gibi | reset-state and force down is pretty similar in this regard, we ask the admin to do something and take over the burden of keeping the system consistent | |
| 10:06:00 | sean-k-mooney | i dont think there is much if anything the operator can do to clean up the state | |
| 10:06:31 | gibi | yeah | |
| 10:06:33 | sean-k-mooney | at least not without out lookign behind cinders back at the stroage | |
| 10:06:44 | sean-k-mooney | so maybe im overthinking it | |
| 10:06:55 | sean-k-mooney | but that is why i was suggesting force down | |
| 10:08:27 | gibi | we can suggest force down but then we have to change the definition of force down, as simple fencing the host is not enough any more | |
| 10:09:15 | sean-k-mooney | ya i think im coming around to your way of thinking and not overloading force-down | |
| 10:09:42 | sean-k-mooney | we perhaps should isntead just document that if the instance task state is not None | |
| 10:09:52 | sean-k-mooney | the operator may need to do addtional cleanup of the instance | |
| 10:10:15 | sean-k-mooney | e.g. remove a partial snapshot | |
| 10:10:17 | gibi | yepp | |
| 10:10:43 | gibi | we can keep the reset-state requirement as today if that helps against accidental evac | |
| 10:11:34 | sean-k-mooney | well i guess that is the choice we have to make. if we think the timeout is suffeicnet as it has been in the past | |
| 10:11:49 | sean-k-mooney | then we can proceed with the change and just drop the force down requirement and add some extra docs | |
| 10:12:06 | sean-k-mooney | otherwise yes we can leave it as it is today with reset state | |
| 11:13:18 | bauzas | OK, I need to go lunching, but I think I see the problem with the mdev names | |
| 11:13:49 | bauzas | it creates an exception when we run the periodic RT method for updating | |