| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-01-05 | |||
| 16:41:34 | opendevreview | Balazs Gibizer proposed openstack/nova master: Split ignored_tags in stats.py https://review.opendev.org/c/openstack/nova/+/867978 | |
| 16:43:15 | gibi | stephenfin, sean-k-mooney[m]: fixed up the comments and added a new reno ^^ | |
| 17:39:20 | opendevreview | Merged openstack/osc-placement stable/zed: Make tox.ini tox 4.0.0 compatible https://review.opendev.org/c/openstack/osc-placement/+/868722 | |
| 18:12:28 | dansmith | melwitt: sean-k-mooney: so I need to sanity check something with people for the stable compute node uuid stuff | |
| 18:12:53 | dansmith | ignoring the pep8 thing, I left one test failing on this patch: https://review.opendev.org/c/openstack/nova/+/863917/1 | |
| 18:13:26 | dansmith | because the test checks for a thing that (a) was part of upgrade stuff from long ago and (b) is somewhat incompatible with the new stuff | |
| 18:14:19 | dansmith | this is the test: https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/test_bug_1764556.py#L69-L144 | |
| 18:14:53 | dansmith | it's checking going from a deleted service/node with no uuid to re-creating a service with the same name, which generates a node uuid | |
| 18:15:23 | dansmith | bug is here: https://bugs.launchpad.net/nova/+bug/1764556 | |
| 18:16:06 | dansmith | fixed in stein, so the test is checking for things that could have happened in an upgrade _to_ stein, where you deleted a service/node before the upgrade and then re-created it with the same name after the upgrade | |
| 18:16:46 | dansmith | what I want to do is just drop that test early in the stable compute uuid set as no longer relevant, but since that's a big red flag, I want to make sure people are okay with that | |
| 18:33:02 | opendevreview | Balazs Gibizer proposed openstack/nova master: Factor out a mixin class for candidate aware filters https://review.opendev.org/c/openstack/nova/+/854929 | |
| 18:33:27 | gibi | stephenfin, sean-k-mooney[m]: another stab at the candidate aware schedule filter refactoring ^^ now with a mixing class | |
| 18:46:41 | sean-k-mooney | dansmith: sorry was still in calls il read back in a bit | |
| 18:50:51 | sean-k-mooney | dansmith: correct me if im wrong but before cells v2 when teh service were first added they just had an int id filed and later we added a uuid field later, not nessically for cellv2 but its required for cellsv2 for for service to be unique since we cant rely on the id filed being unique | |
| 18:51:09 | sean-k-mooney | i.g. the id filed was an auto_increment int primary key | |
| 18:51:25 | sean-k-mooney | and sicne the service are in the cell db we could have two with the same id in differnt cell dbs | |
| 18:51:47 | sean-k-mooney | and the uuid was added to give us a globally unique id for each service | |
| 18:51:58 | dansmith | that's one reason we added uuid on the compute node yeah. not sure if that's relevant here though. | |
| 18:52:19 | sean-k-mooney | well i mention that becuase test_instance_list_deleted_service_with_no_uuid | |
| 18:52:33 | sean-k-mooney | is there to test that upgrade case where the service has not had a uuid populated | |
| 18:52:48 | sean-k-mooney | that the old upgade behiovior you mentioned | |
| 18:52:51 | sean-k-mooney | i was just confirming that | |
| 18:54:51 | sean-k-mooney | the test is also testign what happens fi you delete and recreate teh service but thats not really the point its doing it to thest the online migration | |
| 18:55:41 | sean-k-mooney | dansmith: i think im fin with droping it given that only really works pre placement | |
| 18:56:00 | dansmith | the point of the test (AFAICT) is to test the case where you restart a compute after the upgrade, when you deleted it before the upgrade | |
| 18:56:18 | dansmith | good point on pre-placement, didn't even think about that | |
| 18:56:21 | sean-k-mooney | right which should not work | |
| 18:57:39 | sean-k-mooney | ``` 4. start a new service with the old hostname (still host1); this will | |
| 18:57:41 | sean-k-mooney | also create a new compute_nodes table record for that host/node | |
| 18:57:43 | sean-k-mooney | ``` | |
| 18:58:29 | sean-k-mooney | so if the host had allocations then one of two thing would happen etierh we delete all callocation when we deleted teh service | |
| 18:58:47 | sean-k-mooney | and when the new rp is created with the new cn uuid we need to rebuild them | |
| 18:59:23 | sean-k-mooney | or the service delete would fail if you were on older version of openstack because of thte allocations | |
| 18:59:48 | dansmith | well, it couldn't have had allocations, because it didn't have a uuid before | |
| 18:59:54 | sean-k-mooney | if the RP is not removed the compute agent will get a rp conflict due to duplicate RP name with different uuids | |
| 19:00:17 | sean-k-mooney | oh right | |
| 19:00:24 | dansmith | the scenario is for computes that were created (and deleted) before we had CN uuids | |
| 19:00:51 | sean-k-mooney | is this compute node uuids or service uuids | |
| 19:01:11 | sean-k-mooney | i tought this test was a compute service with no compute service uuid | |
| 19:01:19 | sean-k-mooney | not compute node uuid | |
| 19:03:25 | dansmith | the test is more focused on service, but the implication is what happens to the CN for us | |
| 19:03:41 | dansmith | because you don't delete computes, you delete services, which is what the bug is about | |
| 19:03:44 | dansmith | bug/test | |
| 19:03:57 | sean-k-mooney | right | |
| 19:04:14 | sean-k-mooney | so the problem is really the creation of the new compute node recorrd | |
| 19:04:16 | melwitt | I'm pretty sure it's compute node uuid that was added | |
| 19:04:46 | dansmith | well, they were both added at one point, | |
| 19:04:51 | dansmith | but yes compute node was most recent (although still a long time ago) | |
| 19:05:15 | melwitt | hm, yeah. this is confusing | |
| 19:05:28 | dansmith | the "problem" for me is that the test relies on us creating a new compute node for the resurrected service | |
| 19:05:39 | dansmith | which will get a new auto-generated node uuid | |
| 19:05:43 | sean-k-mooney | compute service uuid was pike https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-pike | |
| 19:05:48 | dansmith | but after I fix that to not happen, it ... doesn't :) | |
| 19:05:58 | dansmith | and fails because the compute node can't be re-created with the same uuid | |
| 19:06:09 | dansmith | I can make it create-or-undelete (and have locally) | |
| 19:06:16 | sean-k-mooney | dansmith: right so creating a new compute node record is wrong | |
| 19:06:25 | sean-k-mooney | well | |
| 19:06:25 | melwitt | this is the commit that added the test https://github.com/openstack/nova/commit/81f05f53d357a546c7f9a53cae6ef45b92e28bc1 | |
| 19:06:28 | dansmith | but that's a bit more change, out of sequence with the rest of the series, etc | |
| 19:06:37 | sean-k-mooney | if we still have a compute node record we shoudl not be creating a new one | |
| 19:06:49 | sean-k-mooney | if its has been deleted then creating one makes sense | |
| 19:06:59 | sean-k-mooney | as its the same as the first time it was created | |
| 19:07:06 | dansmith | well, that's kinda the thing | |
| 19:07:32 | dansmith | we create a new one, but shouldn't, and if we create with the same uuid, the unique contstraint will fail with the deleted one | |
| 19:09:04 | melwitt | sean-k-mooney: the test is deleting the compute node record (implicitly) so that's why it expects to create a new record right? | |
| 19:09:14 | melwitt | afterwards | |
| 19:09:36 | dansmith | it doesn't expect to create a new compute node, it just assumes/relies on it happening | |
| 19:09:37 | sean-k-mooney | melwitt: i think so which is why its checking the hyperviors api to ensure its gone | |
| 19:10:17 | sean-k-mooney | dansmith: its expecting a sidefect of the service delete is that the compute node is removed | |
| 19:10:31 | sean-k-mooney | and the side efffect of the restart is that a new one is created | |
| 19:10:54 | dansmith | my first thought was to make it undelete the compute, then assert the uuid is the same, but then I realized that the test is checking for a thing that can't have happened since stein, so it seems like not worth a bunch of monkeywork to keep asserting this | |
| 19:10:55 | sean-k-mooney | at least that is how im interperting https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/test_bug_1764556.py#L98-L107 | |
| 19:11:30 | melwitt | ok, so what is different with the new change ... if a service and thus compute node are deleted and then nova-compute is started again, will it un-delete the existing compute node record? | |
| 19:11:45 | dansmith | it doesn't currently | |
| 19:11:54 | dansmith | after my series is done then it will | |
| 19:11:55 | melwitt | but your change will make it do that I mean? | |
| 19:11:56 | melwitt | ok | |
| 19:12:03 | sean-k-mooney | do we included deleted in the uniqconstriat for cn table | |
| 19:12:22 | dansmith | sean-k-mooney: no, which is why it conflicts | |
| 19:12:37 | dansmith | sean-k-mooney: we hit that with some of the previous rename customer scenarios too if you recall | |
| 19:12:47 | sean-k-mooney | ack ok so either we undelete or we add it to the uniqcontratint | |
| 19:13:07 | dansmith | yes, and undelete is the right thing IMHO, but that's *after* this point in the series | |
| 19:13:21 | dansmith | and since this test is asserting something that can't be the case anymore, I want to nuke it :) | |
| 19:13:49 | sean-k-mooney | ya so either slap an expect fail on this or nuke it | |
| 19:13:53 | sean-k-mooney | im fine with the latter | |
| 19:14:11 | dansmith | I don't want to xfail it because I don't want to fix it later because I think it's no longer useful | |
| 19:14:23 | dansmith | but if I'm wrong, you (all) need to say so | |
| 19:15:06 | sean-k-mooney | well going forward we dont want to recreate the CN with a differnt uuid | |
| 19:15:14 | melwitt | sorry, I'm going back and trying to understand how that test is relying on a new compute node record | |
| 19:15:28 | melwitt | I know that it is but I can't see why when I look at it | |
| 19:15:50 | dansmith | melwitt: relying on the new compute node or relying on it being recreated in some way? | |
| 19:16:00 | melwitt | dansmith: the recreation | |
| 19:16:09 | dansmith | it relies on there being some compute node because it does a migration, which won't work without it | |
| 19:16:17 | sean-k-mooney | it migrate back to the host that was deleted | |
| 19:16:25 | dansmith | it doesn't care (or know) whether or not it's recreated or undeleted | |
| 19:16:37 | sean-k-mooney | just that it exists | |
| 19:16:54 | melwitt | ok, I guess I don't get why that wouldn't work with your code change | |
| 19:16:55 | dansmith | not even that it exists, just that it can migrate | |
| 19:17:00 | melwitt | if you are going to undelete it | |