Earlier  
Posted Nick Remark
#openstack-nova - 2022-08-26
17:57:02 opendevreview Balazs Gibizer proposed openstack/nova master: Test reschedule with PCI in placement https://review.opendev.org/c/openstack/nova/+/854626
17:57:02 opendevreview Balazs Gibizer proposed openstack/nova master: Support same host resize with PCI in placement https://review.opendev.org/c/openstack/nova/+/854441
17:57:04 opendevreview Balazs Gibizer proposed openstack/nova master: Heal allocation for same host resize https://review.opendev.org/c/openstack/nova/+/854822
17:57:04 opendevreview Balazs Gibizer proposed openstack/nova master: Support multi create with PCI in placement https://review.opendev.org/c/openstack/nova/+/854663
17:58:06 dansmith ugh, that causes another failure later, which may be a quirk of our cinder fixture
17:58:19 dansmith the attachment isn't deleted, so much later it complains that the instance is double-attached
17:58:46 sean-k-mooney well form the cinder side i guess it is
17:59:04 sean-k-mooney we could try and recover at that point and delete the old one again
17:59:16 sean-k-mooney which would possisble stop the leak
17:59:18 dansmith that's what I'm trying to avoid because it ends up a pretty nested mess
17:59:24 sean-k-mooney ah ok
17:59:38 dansmith and it's likely to fail in reality if we just failed to delete
18:00:27 dansmith I'm also not sure I know why we're detaching and re-attaching here, just to do the reimage
18:00:27 sean-k-mooney we are not doing the attchment delete before the save to prevent the other case right
18:00:38 sean-k-mooney where our db is now out of sync if we fail to save
18:00:41 dansmith must be some cinder reason why that happens, to reset the state while the instance is powered off or something
18:00:58 dansmith yeah I think we have to update our db before the delete for races
18:01:11 sean-k-mooney ya i think so too.
18:01:58 opendevreview ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (db) https://review.opendev.org/c/openstack/nova/+/831193
18:01:59 opendevreview ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194
18:01:59 opendevreview ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401
18:02:00 opendevreview ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830
18:02:00 opendevreview ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090
18:02:01 opendevreview ribaudr proposed openstack/nova master: Bump compute version and check shares support https://review.opendev.org/c/openstack/nova/+/850499
18:02:02 opendevreview ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501
18:02:02 opendevreview ribaudr proposed openstack/nova master: Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500
18:02:03 opendevreview ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028
18:02:04 opendevreview ribaudr proposed openstack/nova master: Add instance.power_on_error notification https://review.opendev.org/c/openstack/nova/+/852084
18:02:04 opendevreview ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029
18:02:06 opendevreview ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/852085
18:02:06 opendevreview ribaudr proposed openstack/nova master: Add instance.power_off_error notification https://review.opendev.org/c/openstack/nova/+/852278
18:02:08 opendevreview ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087
18:02:08 opendevreview ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086
18:02:10 opendevreview ribaudr proposed openstack/nova master: Add share_info parameter to reboot method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/854823
18:02:10 opendevreview ribaudr proposed openstack/nova master: Change microversion to 2.93 https://review.opendev.org/c/openstack/nova/+/852088
18:02:12 opendevreview ribaudr proposed openstack/nova master: Support rebooting an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/854824
18:02:19 sean-k-mooney i dont recall why but i rememebr lee disucsing this at some point
18:06:42 sean-k-mooney i dont see this dicussed in the ptg
18:07:14 sean-k-mooney ah
18:07:16 sean-k-mooney https://review.opendev.org/c/openstack/nova-specs/+/840155/5/specs/zed/approved/volume-backed-server-rebuild.rst#58
18:07:31 sean-k-mooney #. Create an empty (no connector) volume attachment for the volume and
18:07:33 sean-k-mooney server. This ensures the volume remains ``reserved`` through the next
18:07:35 sean-k-mooney step.
18:07:37 sean-k-mooney #. Delete the existing volume attachment (the old one).
18:07:39 sean-k-mooney #. Save the new attachment UUID to the BDM.
18:07:41 sean-k-mooney #. The above two steps are needed to keep the volume in ``reserved`` state
18:07:43 sean-k-mooney as a management state which is required by cinder to perform re-image
18:07:45 sean-k-mooney operation on it.
18:07:47 sean-k-mooney #. Call the new ``os-reimage`` cinder API.
18:07:55 dansmith yeah, to reset the state basically I assume
18:08:24 sean-k-mooney we need to move it form in-use to reserved to reimage
18:11:20 sean-k-mooney honestly i feel like the way out of this if everything explodes is just call rebuild again
18:11:28 sean-k-mooney like wait for cinder to be back
18:11:43 sean-k-mooney and then the vm that is precumsble in error if we coudl not comptle the reimage later
18:11:52 sean-k-mooney could just be rebuilt again
18:12:18 dansmith yeah I assume that will work, as long as it's still in a reasonable state
18:12:19 sean-k-mooney kind of like what we do with a failed evacuate we just evacuate again
18:13:06 dansmith so I guess I'm just going to put it somewhat back the way it was, let it fail for all cases, but only call delete if we created the new attachment
18:13:14 dansmith right now it'll call delete(None) which I assume will fail
18:13:55 sean-k-mooney ya presumabley with a type/atibute error
18:14:14 sean-k-mooney None type has no attirbute uuid or something like that
18:15:00 gibi rebuild after a failed rebuild make sense to me too
18:16:01 sean-k-mooney i dont know if the precondtions on rebuild allow that
18:16:06 dansmith yeah, I'm not so concerned about that, I just want to make sure we haven't left things in too bad of a state where that's not possible
18:16:08 sean-k-mooney or if you would have to do reset state first
18:16:16 dansmith sounds to me like we're going to have leaked an attachment regardless
18:16:28 dansmith because we have nowhere to stash it and try to delete it later
18:16:28 sean-k-mooney yes
18:16:38 sean-k-mooney although the user can actully delete that if they wanted too
18:17:42 sean-k-mooney it would be a bit painful however
18:17:52 sean-k-mooney since they have no way to lsit teh bdms today
18:18:02 sean-k-mooney its not part of server detail show
18:18:34 sean-k-mooney i mena they coudl try deleteing all the attachments on a voluem but then nova and cinder are out of sync
18:19:01 sean-k-mooney so i think we woudl want to make sure they coudl juse rebuild again
18:19:09 sean-k-mooney rather then trying to repair it themselves
18:20:20 dansmith I think that will fail because of the double attachment
18:20:30 dansmith the same thing as when I failed the delete
18:20:38 dansmith but I dunno there's much we can do about that
18:56:56 opendevreview Rajat Dhasmana proposed openstack/nova master: add support for updating server's user_data https://review.opendev.org/c/openstack/nova/+/816157
18:56:57 opendevreview Rajat Dhasmana proposed openstack/nova master: Add conductor RPC interface for rebuild https://review.opendev.org/c/openstack/nova/+/831219
18:56:57 opendevreview Rajat Dhasmana proposed openstack/nova master: Add support for volume backed server rebuild https://review.opendev.org/c/openstack/nova/+/820368
18:56:58 opendevreview Rajat Dhasmana proposed openstack/nova master: Add API support for rebuilding BFV instances https://review.opendev.org/c/openstack/nova/+/830883
19:00:26 ozzzo_work We use the AggregateMultiTenancyIsolation filter for some aggregates, and for those aggregates we specify "filter_tenant_id = '(list of projects)'
19:00:57 ozzzo_work Today I'm hitting that filter for aggregates that do not have filter_tenant_id set
19:01:16 ozzzo_work This aggregate has no properties set at all
19:01:29 ozzzo_work 2022-08-26 17:48:49.879 33 INFO nova.filters [req-f57f505f-b3c8-42f5-acf7-5e5efe10ef83 a9219bb013c944edea6ba612b8fa704adc28d676f3ad1e326094350b8ff0c9c0 efc7139e50db483991df846c69b42477 - 8793b235debf49e6aba6bd1e2bf65360 8793b235debf49e6aba6bd1e2bf65360] Filtering removed all hosts for the request with instance ID 'e9f9292a-f1c0-409b-a47f-9fa596fd0965'. Filter results: ['ComputeFilter: (start: 50, end: 50)', 'RetryFilter: (start: 50, end
19:01:50 ozzzo_work looks like the line is too long
19:02:08 ozzzo_work https://paste.openstack.org/show/b5UFNxMB3oIlduDz1nat/
19:02:12 ozzzo_work What could be causing that?
19:02:44 dansmith oye
19:02:50 dansmith whoami-rajat: did you make changes to that set or just rebase?
19:03:14 whoami-rajat dansmith, just rebased to resolve merge conflict, now working on changes
19:03:14 dansmith whoami-rajat: I should have made it more clear -- I was doing some work there, but was trying to avoid rebasing the other person's patch
19:03:22 dansmith figured I was safe since you said monday
19:03:30 dansmith whoami-rajat: hold on, I have a number of changes
19:03:37 whoami-rajat dansmith, oh sorry about that
19:03:39 dansmith I might as well push them up now that you rebased it
19:03:58 whoami-rajat ack, will wait then
19:04:18 whoami-rajat this microversion dependency doesn't seem good ...
19:08:47 dansmith ah, whoami-rajat I think you reverted the other person's latest rev with your push just now :(

Earlier   Later