| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-10 | |||
| 14:23:28 | dansmith | efried: find on principle, but unless there's something that is going to use it, I'm not sure there's a point | |
| 14:23:37 | dansmith | efried: cyborg master tests against nova master yeah? | |
| 14:23:57 | efried | Yeah, tight dependency, several things they're relying on (including your event cancel) | |
| 14:24:45 | efried | I can buy "wait until needed". It should be isolated enough that it would be easy to do at any point. | |
| 14:25:15 | dansmith | sure, but seems about like any other cross-service dependency, | |
| 14:25:49 | dansmith | unless they're going to run against the older service, there's no reason to backport something like that, and they clearly aren't going to get all of nova's cyborg integration stuff backported | |
| 14:28:27 | openstackgerrit | sean mooney proposed openstack/nova master: FUP for in-place numa rebuild https://review.opendev.org/698260 | |
| 14:29:13 | sean-k-mooney | efried: ^ that should adress the comments on the first two patches. i have a checkup at my doctors in 15 mins so ill look at the final patch when i get back | |
| 14:29:31 | mriedem | i agree with what dan said | |
| 14:30:23 | efried | dansmith: right, I wasn't thinking of cyborg, I was thinking of some other service that needs to be able to operate against different levels of nova. If they have to change code for the fix, it might be easier for them if the fix was backported rather than them having to code for either possibility. | |
| 14:30:41 | dansmith | well, | |
| 14:30:42 | efried | I guess "other service" is just neutron, ironic, cinder | |
| 14:30:50 | dansmith | I thought we said we didn't expect anyone else to notice, | |
| 14:30:58 | efried | famous last words | |
| 14:31:05 | sean-k-mooney | neutron is the only one one that i think would send events maybe cinder and i dont think neutron ever checks the responce code | |
| 14:31:05 | dansmith | so I'd want to know what actual service would care in what actual situation | |
| 14:31:19 | dansmith | not doubting that it's possible, just saying.. backports like that need reasons, IMHO | |
| 14:31:26 | efried | ironic does too now for the power state thing | |
| 14:31:34 | efried | Fine by me, just talking it through. | |
| 14:31:35 | dansmith | efried: if they're going to notice, then backporting something they'll notice is really much worse | |
| 14:31:37 | sean-k-mooney | efried: but does it actully check the responce code | |
| 14:32:00 | sean-k-mooney | most of the external events usage just fired the event and forgot about it | |
| 14:32:05 | efried | dansmith: yeah, that makes sense, because we can't count on the backport being applied in a given field situation, right? | |
| 14:32:37 | dansmith | efried: backports need to be things that can be applied (or not) in any order to a running deployment.. | |
| 14:32:40 | sean-k-mooney | also in the ironic case the only failure mode we know of would be for shelved instaces. is that a thing with ironic? | |
| 14:32:53 | sean-k-mooney | it could be form bfv i guess but in general i woudl guess not? | |
| 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 | |