Earlier  
Posted Nick Remark
#openstack-nova - 2023-01-04
16:24:32 sean-k-mooney[m] that makes testing simpler
16:35:18 opendevreview Pierre-Samuel Le Stang proposed openstack/nova master: Correctly reset instance task state in rebooting hard https://review.opendev.org/c/openstack/nova/+/867832
17:51:52 danzelius Hey there, I have some old instances I wan't to live-migrate. They used flavors which had some metadata assigned like "highmem: True". The scheduler can't find a host because the AggregateInstanceExtraSpecs-Filter (we included recently) filters them out since the "highmem" key is unscoped. In the nova database I found the instance_extra table and modified the instance in question, removing the extra_specs dict contents....Still the filter tries t
17:52:20 danzelius highmem"-metadata-field. Are there some other places in the db I have forgotten about? I also modified the original-flavor, removing the metadata, still no luck.
18:15:28 opendevreview Ghanshyam Mann proposed openstack/nova stable/zed: DNM: tetsing tox<4 pin https://review.opendev.org/c/openstack/nova/+/869250
18:16:25 opendevreview Ghanshyam Mann proposed openstack/nova stable/yoga: DNM: tetsing tox<4 pin https://review.opendev.org/c/openstack/nova/+/869184
18:16:41 opendevreview Ghanshyam Mann proposed openstack/nova stable/xena: DNM: tetsing tox<4 pin https://review.opendev.org/c/openstack/nova/+/869185
18:16:50 opendevreview Ghanshyam Mann proposed openstack/nova stable/wallaby: DNM: tetsing tox<4 pin https://review.opendev.org/c/openstack/nova/+/869186
19:27:39 opendevreview Ghanshyam Mann proposed openstack/nova master: Enable new defaults and scope checks by default https://review.opendev.org/c/openstack/nova/+/866218
22:29:43 dansmith when did we stop being able to -1 specs?
22:30:04 dansmith oh, heh, because this one is merged, lol
22:30:17 dansmith guess I should refresh my tabs from early december
#openstack-nova - 2023-01-05
01:52:34 opendevreview melanie witt proposed openstack/nova master: Add mock to avoid loading guestfs in unit test https://review.opendev.org/c/openstack/nova/+/862769
02:16:29 opendevreview melanie witt proposed openstack/placement stable/ussuri: placement-status: check only consumers in allocation table https://review.opendev.org/c/openstack/placement/+/840703
09:05:40 sahid o/ a gentle reminder if it's possible to get eyes on https://review.opendev.org/c/openstack/nova/+/858383 ?
09:30:56 gibi good morning
10:00:19 Uggla oh gibi, good morning and happy new year.
10:00:38 gibi Uggla: same to you too
10:01:42 opendevreview Balazs Gibizer proposed openstack/placement master: Make tox.ini tox 4.0.0 compatible https://review.opendev.org/c/openstack/placement/+/868418
10:04:37 gibi bauzas, gmann: the os-vif tox4 fix is blocked by test failure from master confirmed by sean-k-mooney[m] last year.
10:04:56 gibi I fixed up the placement tox4 patch based on stephenfin's comments now
10:05:00 bauzas k
10:05:17 bauzas working on some reproducer downstream atm
10:05:52 gibi ack
12:31:19 opendevreview Konrad Gube proposed openstack/nova-specs master: Use extend volume completion action https://review.opendev.org/c/openstack/nova-specs/+/855490
14:03:22 sean-k-mooney gibi: i have reviewed up to https://review.opendev.org/c/openstack/nova/+/854924/9 and am starting on it now. stephenfin is -1 on it i think just the docs/release notes can you adress those quickly?
14:03:36 gibi sean-k-mooney: looking...
14:04:21 sean-k-mooney i have approved everything before that so if you do fix it please avoid rebasing the previous patches :)
14:08:06 gibi sure :)
14:40:04 opendevreview Merged openstack/nova master: Support cold migrate and resize with PCI tracking in placement https://review.opendev.org/c/openstack/nova/+/854247
15:05:35 sean-k-mooney gibi: stephenfin ok so at this point stephen and i have completed the review fo the pci seriese. i have approve most of it including the followps so there are two bits left. 1 the docs/release note fixes noted above and the refactor in the last patch which is optional
15:05:57 gibi sean-k-mooney: thanks I will provide the fix for the followup toda
15:05:58 sean-k-mooney so i think we can wrap this up this week
15:07:30 sean-k-mooney gibi: https://review.opendev.org/c/openstack/nova/+/854929/8 my suggestion fro that is make it a mixin instead and only mix it into the filters that need it
15:07:47 gibi I will think about that
15:08:22 sean-k-mooney ack i dont think its pressing in any case. if we did not merge the last patch it would have no ill effect one way or anohter
15:08:46 gibi yepp, this was the reason we moved it to the top
15:08:47 sean-k-mooney im going to go afk for a few mins chat in a bit
15:08:49 gibi so it does not block us
15:08:52 gibi ack
16:31:04 opendevreview Pierre-Samuel Le Stang proposed openstack/nova master: Correctly reset instance task state in rebooting hard https://review.opendev.org/c/openstack/nova/+/867832
16:31:04 opendevreview Pierre-Samuel Le Stang proposed openstack/nova master: Reproducer test of bug #1999674 https://review.opendev.org/c/openstack/nova/+/867807
16:41:31 opendevreview Balazs Gibizer proposed openstack/nova master: Follow up for the PCI in placement series https://review.opendev.org/c/openstack/nova/+/855654
16:41:31 opendevreview Balazs Gibizer proposed openstack/nova master: Allow enabling PCI scheduling in Placement https://review.opendev.org/c/openstack/nova/+/854924
16:41:32 opendevreview Balazs Gibizer proposed openstack/nova master: Reproduce PCI pool filtering bug https://review.opendev.org/c/openstack/nova/+/855649
16:41:32 opendevreview Balazs Gibizer proposed openstack/nova master: Rename _to_device_spec_conf to _to_list_of_json_str https://review.opendev.org/c/openstack/nova/+/855648
16:41:33 opendevreview Balazs Gibizer proposed openstack/nova master: FUP for the scheduler part of PCI in placement https://review.opendev.org/c/openstack/nova/+/862876
16:41:33 opendevreview Balazs Gibizer proposed openstack/nova master: Strictly follow placement allocation during PCI claim https://review.opendev.org/c/openstack/nova/+/855650
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

Earlier   Later