| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-10 | |||
| 14:33:03 | sean-k-mooney | anyway got to run | |
| 14:33:16 | dansmith | efried: if we backport it, you should expect someone would have yum upgraded one machine at a time, in any order, potentially without upgrading neutron or anything else, before or after | |
| 14:33:53 | dansmith | efried: so if we introduce some different behavior, there are lots of ways that could be much worse than a coordinated upgrade, which would generally be smoked out ahead of time, rolled to prod in a maintenance window, etc | |
| 14:34:11 | efried | sean-k-mooney: It just uses the code for logging purposes https://review.opendev.org/#/c/664842/19/ironic/common/nova.py | |
| 14:34:22 | efried | so the behavior would change, but the result (error or not) would be the same. | |
| 14:37:02 | efried | oh, I lied. | |
| 14:37:11 | efried | it will return True in the 207/4xx case. | |
| 14:39:40 | efried | ...which is only ever checked in UT. Phew. | |
| 14:39:54 | openstackgerrit | Merged openstack/nova stable/rocky: Do not update root_device_name during guest config https://review.opendev.org/696353 | |
| 14:43:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add NodeOwnerFilter https://review.opendev.org/697331 | |
| 15:11:02 | stephenfin | efried: Think I could entice you to burn through a few more of those nova-net patches today? | |
| 15:11:38 | efried | stephenfin: Totally. When do you bugger off til 2020? | |
| 15:12:25 | stephenfin | I'm around until the 27th, minus the 25th/26th | |
| 15:12:40 | stephenfin | gone the new years week | |
| 15:12:46 | stephenfin | *week of new years | |
| 15:13:33 | efried | stephenfin: cool. So, can I trade you nova-net for vTPM (not today, I've got some more updates to make)? | |
| 15:14:36 | efried | dun dun dahhh | |
| 15:15:16 | stephenfin | I'll allow it. | |
| 15:15:22 | efried | Thanks. | |
| 15:15:33 | efried | Is gibi_off off for the remainder? | |
| 15:24:55 | aarents | kashyap: thks for the review https://review.opendev.org/#/c/696084/ I added some remarks about if go on rebase versus flatten | |
| 15:25:26 | kashyap | aarents: No problem; will look. I'm running around like a head-less chicken doing last-minute stuff | |
| 15:27:30 | aarents | k no prob | |
| 15:28:56 | efried | dansmith, mriedem, sean-k-mooney: https://review.opendev.org/698273 (ironic refactor for the external events fix) | |
| 15:30:09 | kashyap | efried: If you're curious about yesterday's "competition", I won ... the "loser's final", if that makes sense | |
| 15:30:22 | sean-k-mooney | i have not seen us use the ddt stuff much i should look into that more closely sometime | |
| 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 | |