Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-12-10
17:09:15 openstackgerrit Mykola Yakovliev proposed openstack/nova master: Fix boot_roles in InstanceSystemMetadata https://review.opendev.org/698040
17:13:40 sean-k-mooney efried: do you have a minute to talk about the notifcaiton changes in https://review.opendev.org/#/c/674072/14
17:14:08 efried sean-k-mooney: hmu in half an hour?
17:14:10 efried otp
17:14:29 sean-k-mooney sure im goint to adress the other comments in the interim
17:34:32 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: debug cross-cell resize https://review.opendev.org/698304
17:42:40 openstackgerrit Merged openstack/nova stable/rocky: compute: Use long_rpc_timeout in reserve_block_device_name https://review.opendev.org/696956
17:49:01 openstackgerrit Matt Riedemann proposed openstack/nova master: Update orphaned allocations troubleshooting doc for unset command https://review.opendev.org/696582
18:20:12 efried sean-k-mooney: that took longer than expected, sorry. Ready to talk about notifications?
18:22:17 sean-k-mooney no worries
18:22:27 sean-k-mooney so basicaly im a littel fuzzy on our policy
18:23:01 sean-k-mooney i did not need to extend the notifciaiton payload but i though we were ment to every time we added an image property
18:23:10 sean-k-mooney gmann: ^ maybe you know
18:23:53 sean-k-mooney i know we have to update the notifcaiton object if i extend a field that is used in an existing notifcation
18:24:12 sean-k-mooney but i dont know if its requried when we add new image properties
18:25:27 sean-k-mooney efried: i assume that was what you wanted to know regarding the notification change in https://review.opendev.org/#/c/674072/14 right
18:26:14 efried Yes, that's what I wanted to know. It struck me because I'm adding (and have seen recently added) image properties and haven't seen corresponding notifications changes.
18:28:51 sean-k-mooney right so i was asked to add them for https://review.opendev.org/#/c/647733/ where i exetended the video_model field
18:29:01 sean-k-mooney but i did not add them for my vPMU change
18:29:29 sean-k-mooney i can drop them but i jsut dont know if we should be keeping them in sync or not
18:31:19 sean-k-mooney efried: would you perfer i drop them?
18:31:39 efried This may be a question for gibi_off
18:31:42 efried but he's... off
18:31:46 efried mriedem: do you know this answer?
18:32:21 efried TLDR: What is the policy for keeping image meta notification payload fields consistent with image meta fields? Always, never, based on some criteria...?
18:37:06 mriedem otp, will get back
19:31:46 mriedem cripes, i didn't know we have a notification payload ImageMetaPropsPayload that was 1:1 with ImageMetaProps
19:31:54 mriedem given that, it seems it's meant to be 1:1
19:32:08 mriedem i don't think we have a policy but i'm assuming that's the intent, but would have to confirm with gibi
19:32:25 mriedem if those are meant to be 1:1 then we need a test that asserts they are
19:32:33 mriedem efried_afk: sean-k-mooney: ^
19:32:54 mriedem "# NOTE(takashin): If fields are not set in the ImageMetaProps object,
19:32:55 mriedem # it will not set the fields in the ImageMetaPropsPayload
19:32:55 mriedem # in order to avoid too many fields whose values are None."
19:34:13 mriedem seems ImageMetaPropsPayload, or what uses it, would have been better off with a simple DictOfStrings thing where the values are the coerced ImageMetaProps
19:34:19 mriedem because keeping that all 1:1 seems a bit nuts
19:35:40 mriedem https://review.opendev.org/#/c/482629/
19:36:23 mriedem the request spec payload is not as beefy but it's....beefy
19:36:27 mriedem lite beef
19:41:18 mriedem dansmith: are you aware of any poison fixtures off the top of your head for the api db? like say i want to do some stuff in a test, then nuke the api db global conf connection and run some more test code
19:42:01 dansmith mriedem: no, since it requires using the fixture, I don't think we've ever needed one
19:42:13 dansmith needs the actual fixture for the api db I mean
19:42:23 mriedem wanted to test a 'no upcall' kind of thing
19:42:37 dansmith I imagine you could add something to the db fixture to let you break it midway if that's what you're tryingto do
19:44:01 mriedem i was able to do something by just getting a handle to the api db fixture and calling cleanup() on it which drops the schema on the db
19:44:15 mriedem so you get DBNonExistentTable rather than like DBConnectionError or whatever
19:44:26 mriedem might be good enough for what i need
19:47:31 dansmith yeah, that's what I was thinking
20:12:02 sean-k-mooney mriedem: ya so i think it was added as part of the version notification work
20:12:13 sean-k-mooney but it has to be manually updated each time
20:14:50 sean-k-mooney mriedem: so should i keep the payload notificion updates in the patch. i could post something to the mailing list if we want to change this longer term
20:16:10 mriedem fun https://bugs.launchpad.net/nova/+bug/1855927
20:16:10 openstack Launchpad bug 1855927 in OpenStack Compute (nova) "_poll_unconfirmed_resizes may not retry later if confirm_resize fails in API" [Low,New]
20:16:25 mriedem sean-k-mooney: idk, ask gibi
20:17:00 mriedem you get one shot at confirming a resize and if it fails you can't retry
20:17:05 mriedem without db surgery
20:18:39 sean-k-mooney oh interesting.
20:20:21 sean-k-mooney would it be valid to include both finished and confiming migration in the periodic
20:20:39 mriedem maybe
20:20:48 mriedem that doesn't change the api behavior though - you'd have to do the same in the api
20:21:08 mriedem i think like an instance task_state you likely need to reset the migration status on error
20:21:09 sean-k-mooney true
20:22:22 sean-k-mooney i can see the logic of rolling back the migration to the finished state but we dont want to keep retrying forever
20:22:52 sean-k-mooney if we go to error can we reset teh migration status to finished via the api or only via the db
20:22:59 mriedem only the db
20:23:03 mriedem there is no api to update migration records
20:24:15 mriedem it's an extremely latent bug so not high priority, just something i noticed while writing a test around that periodic
20:25:31 sean-k-mooney right /os-migrations is just a list of all migration and the server migration enpoint does not have a put
20:30:27 sean-k-mooney we check for both finished and confriming here https://github.com/openstack/nova/blob/5a3ef39539ca112ae0552aef5cbd536338db61b7/nova/compute/manager.py#L4267 do we arrive at that form finished from teh periodic task
20:30:41 mriedem yes
20:30:51 sean-k-mooney ah ok
20:31:01 mriedem https://github.com/openstack/nova/blob/5a3ef39539ca112ae0552aef5cbd536338db61b7/nova/compute/manager.py#L8866
20:31:20 mriedem the periodic on the dest host calls the api method which calls confirm_resize on the source host
20:32:08 sean-k-mooney right but the compute api method set it to confirming https://github.com/openstack/nova/blob/5a3ef39539ca112ae0552aef5cbd536338db61b7/nova/compute/api.py#L3684
20:32:19 mriedem correct
20:32:42 mriedem and after the api does that, if anything fails you can't re-confirm the resize
20:34:22 sean-k-mooney yes but in the compute manager do_confirm_resize which is an inner function of confirm_resize seams to exepct the migration could be in finished or confriming so i was trying to figure out when could it be finish since i think it shoudld only be in confirming based on that code flow
20:34:54 sean-k-mooney anyway its proably not important i just thought it was odd
20:35:04 mriedem it's probably leftover
20:35:19 mriedem or when deleting a resized server
20:35:28 mriedem see _confirm_resize_on_deleting
20:36:25 sean-k-mooney oh so we clean up the resouce on the source node then delete it on the dest
20:37:02 mriedem yes
20:38:13 sean-k-mooney that still calls confirm_resize via rpc but ya it looks like it " for status in ('finished', 'confirming'):" code was copied between the two functions
20:41:44 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: debug cross-cell resize https://review.opendev.org/698304
20:41:45 openstackgerrit Matt Riedemann proposed openstack/nova master: Add cross-cell resize tests for _poll_unconfirmed_resizes https://review.opendev.org/698322
22:02:45 openstackgerrit sean mooney proposed openstack/nova master: support pci numa affinity policies in flavor and image https://review.opendev.org/674072
22:25:21 efried well that took rather longer than expected.
22:25:59 efried sean-k-mooney: So I guess the right thing here is to hold off making irreversible OVO changes until we can get the word from gibi_off. Can you live with that?
22:26:14 sean-k-mooney yep that is fine with me
22:26:19 sean-k-mooney i address some of your nits
22:26:36 sean-k-mooney but i have not done the functional test changes yet
22:29:22 efried okay
22:30:13 sean-k-mooney do you want the extra functional test in the same patch or a follow up. i need to think about how to do it smartly instead of just copy pasting and tweeking
22:34:51 efried sean-k-mooney: stephenfin isn't disappearing until well after you do, so getting his re+2 ought to be easy enough; same patch seems reasonable.
22:35:15 openstackgerrit sean mooney proposed openstack/nova master: fix imports of typeing module https://review.opendev.org/698334
22:35:30 efried we may not even be able to move on it until the new year -- not sure whether gibi is thoroughly gone until then.
22:35:33 sean-k-mooney i think artom is going to pick up the patch if its not reay before i do
22:36:13 sean-k-mooney hum ok that would less then ideal but ok
22:36:41 sean-k-mooney i could split the notifciation change into a second patch if that helped

Earlier   Later