Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-12-10
15:30:25 kashyap (There were 10 folks; two groups of 5 each.)
15:30:38 efried As a veteran of tournaments, both single elimination and round robin, it makes perfect sense. How many in the bracket?
15:30:50 efried disregard, race condition.
15:30:59 kashyap Hehe
15:31:12 efried sean-k-mooney: I actually stole that from dustinc, whom I now consider to be our ddt expert.
15:32:17 efried kashyap: congratulations. There are many reasons competition is a positive experience, and winning is only a small (and IMO not close to the most important) aspect.
15:32:32 sean-k-mooney thanks for adding the comment on the ddt elements, it makes it easier to follow without having to figure it out
15:32:54 kashyap efried: Yeah, I barely practised the last few Mondays; and went in there just to see how _different_ players play in a game vs. routine practise
15:33:07 efried kashyap: On that note: http://www.taylorbjj.com/why-i-dont-compete/
15:33:23 kashyap efried: I fully agree on the positive experience; I didn't mind "losing", but was definitely fun
15:34:57 efried o/ tssurya. Is this coincidence, or did you just happen to see my ironic patch?
15:35:54 tssurya efried: saw the ironic patch comment :)
15:36:10 tssurya I'll see if I can clean that up
15:36:13 efried tssurya: I put up https://review.opendev.org/698273 already
15:36:24 efried ...and need to go note it on the original...
15:36:50 tssurya efried: aha! thanks a lot
15:37:19 efried tssurya: Figured since I made the mess, I ought to clean it up :P
15:37:19 efried Your review would be most appreciated though.
15:38:31 efried kashyap: Most of that blog post is anti-what we talked about. The bottom three bullets though...
15:44:54 openstackgerrit Alexandre arents proposed openstack/nova stable/queens: Do not update root_device_name during guest config https://review.opendev.org/696469
16:18:03 kashyap efried: Thanks for the executive summary; have the URL open :-)
16:22:48 kashyap efried: Yeah, indeed the last three bullets hit the point right on its mazard
16:31:36 openstackgerrit Mykola Yakovliev proposed openstack/nova master: Validate aggregate IDs before querying database https://review.opendev.org/698094
16:38:53 openstackgerrit Alexandre arents proposed openstack/nova stable/queens: Do not update root_device_name during guest config https://review.opendev.org/696469
16:49:25 openstackgerrit Alexandre arents proposed openstack/nova stable/queens: Do not update root_device_name during guest config https://review.opendev.org/696469
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

Earlier   Later