| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-14 | |||
| 17:10:32 | mriedem | it might just be that the documented replies to my questions/edge cases are done in a follow up i could drop the -1 | |
| 17:11:08 | mriedem | as it reads today, the spec is very much like "if you're using libvirt and everything is fully upgraded, you're golden" but i think it's worth documenting if those aren't true and what happens | |
| 17:11:35 | mriedem | plus there is no liaison and that's just like, -5 | |
| 17:13:36 | dansmith | mriedem: well, fwiw, I asked him to remove the hard fail, and also encouraged him to remove some of the upgrade impact, | |
| 17:13:56 | dansmith | well, nevermind, that's more the BFV one | |
| 17:14:03 | dansmith | anyway, whatever | |
| 17:14:35 | mriedem | ok. i'm just asking that rather than remove things and leave questions (which i obviously had b/c it wasn't documented), i'm asking that we're clear about intent | |
| 17:14:54 | mriedem | so in a year or 2 people aren't like, "why does it work this way? was x considered?" | |
| 17:15:00 | dansmith | yeah, not arguing against that, | |
| 17:15:27 | dansmith | more like hoping I didn't lead him too astray asking him to pare down some of it, specifically around the start-failing-when-we-didn't-before stuff | |
| 17:15:40 | mriedem | ack | |
| 17:15:54 | mriedem | never lead sweet lee astray | |
| 17:18:39 | openstack | bug 1852610 in OpenStack Compute (nova) "API allows source compute service/node deletion while instances are pending a resize confirm/revert" [Medium,Triaged] https://launchpad.net/bugs/1852610 | |
| 17:18:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional recreate revert resize test for bug 1852610 https://review.opendev.org/694364 | |
| 17:20:07 | mriedem | sean-k-mooney: ^ and the one below it are the tests we talked about | |
| 17:21:44 | efried | bauzas: Hi, here now, sorry. | |
| 17:21:54 | bauzas | efried: no worries | |
| 17:22:31 | bauzas | efried: traits from a root RP aren't automatically cascaded to their siblings, right? | |
| 17:22:43 | efried | correct | |
| 17:22:47 | bauzas | efried: because I really want to iterate over the list of RPs | |
| 17:22:48 | efried | siblings/descendants | |
| 17:23:23 | bauzas | so in a world with nested RPs, I'll look over every RP and call its root RP to see whether it's COMPUTE_NODE | |
| 17:23:24 | efried | bauzas: I need to remind myself what you're doing here. If you really just want the compute node RPs, you ought to be able to do it with GET /resource_providers?required=COMPUTE_NODE | |
| 17:23:37 | efried | and not need to iterate | |
| 17:23:49 | bauzas | efried: I want to look at every RP to see whether it has orphaned allocs | |
| 17:24:01 | bauzas | efried: scrubbing if you prefer | |
| 17:25:04 | mriedem | how are you going to determine that for nested providers? | |
| 17:25:06 | bauzas | and for that, I'm 1/ looking at the RP, 2/ ask for its allocs, 3/ see whether those allocs are compute-related (and I was using RCs for this, but I could use traits), 4/ get instances and migrations from the compute it relases, 5/ do the comparison | |
| 17:25:34 | bauzas | mriedem: the code I wrote atm is getting the root RP and get its instance and migrations | |
| 17:25:44 | mriedem | trying to build in support for nested providers from the first iteration of that audit command seems like something that will keep it from ever getting done | |
| 17:25:48 | bauzas | mriedem: and then only comparing allocations of RCs we manage | |
| 17:26:03 | mriedem | bauzas: but like efried just said, you can get the compute node roots today | |
| 17:26:07 | bauzas | mriedem: that doesn't really overcomplexify the logic | |
| 17:26:08 | mriedem | or with that trait i guess | |
| 17:26:32 | mriedem | so, "i want to do x but the slow way" | |
| 17:26:42 | bauzas | mriedem: yup, that's what I'm changing as of now, instead of looking at Nova RCs, I'm just looking whether the root RP is havint the trait | |
| 17:26:45 | bauzas | having* | |
| 17:26:48 | efried | Okay, that was the missing piece: if we're truly not trying to implement support for nested (or sharing) then using the trait will get you back all and only roots in one query. | |
| 17:27:12 | efried | though I'm not fully grasping why we wouldn't include logic for nested right now. | |
| 17:27:18 | mriedem | efried: i'm not saying those aren't cases to consider, but i wouldn't in v1 | |
| 17:27:30 | mriedem | efried: he's been working on this for like a year | |
| 17:27:32 | bauzas | mriedem: the current patch is managing nested | |
| 17:27:34 | efried | heh | |
| 17:27:50 | sean-k-mooney | mriedem: thanks i have added them to my review list | |
| 17:27:54 | bauzas | mriedem: nah, I was working on it since maybe 3 weeks of time | |
| 17:28:11 | mriedem | bauzas: but you've been *talking* about this audit command for a long time | |
| 17:28:11 | bauzas | and I just want to get rid of it | |
| 17:28:18 | bauzas | oh hell yeah | |
| 17:28:28 | mriedem | so you know, i'm just saying shit or get off the pot | |
| 17:28:37 | mriedem | do the more complex stuff in v2 | |
| 17:28:44 | bauzas | I can split the change | |
| 17:28:53 | mriedem | fwiw heal_allocations still doesn't supported nested | |
| 17:28:58 | bauzas | the change is actually already big | |
| 17:29:06 | mriedem | well, except qos ports which gibi added and that took awhile | |
| 17:29:12 | mriedem | bauzas: right that's my point | |
| 17:29:18 | bauzas | makes sens | |
| 17:29:20 | bauzas | sense* | |
| 17:29:27 | bauzas | I'll try to split into two | |
| 17:34:35 | bauzas | artom: we really wanted to leave it optional | |
| 17:34:51 | bauzas | I mean, that would be a totally separate and desperate API | |
| 17:35:02 | bauzas | all words thought | |
| 17:35:05 | mriedem | gum? | |
| 17:35:16 | mriedem | jim? | |
| 17:35:20 | mriedem | are you chewing on jroll?! | |
| 17:35:27 | jroll | O_o | |
| 17:35:32 | jroll | pls don't. | |
| 17:35:46 | mriedem | jroll requires consent to be chewed upon | |
| 17:35:53 | jroll | my baby bites me enough as it is | |
| 17:36:22 | mriedem | babies are like puppies, just give it a chew toy | |
| 17:36:30 | mriedem | and let it poop somewhere random | |
| 17:36:51 | jroll | indeed | |
| 17:38:35 | bauzas | mriedem: I guess you saw the flavor explosion thread | |
| 17:38:44 | mriedem | i'm not getting involved | |
| 17:39:22 | bauzas | mriedem: most of the crux is to say : "whatever you want, make it not impactful to any other API that already exists, and don't change what a flavor means" | |
| 17:39:33 | bauzas | hah, that was dansmith and efried, my bad :) | |
| 17:41:23 | efried | I need to catch up on that thread, but unless we got a bunch of hands in the air in the last two weeks saying "Oh, I love this and I'm gonna use it in my cloud," I'm still likely to think it's not worth the effort to implement. | |
| 17:42:56 | dansmith | none of my deeply-rooted concerns are addressed in the discussion | |
| 17:43:19 | dansmith | more definition of how it's expected to be used (although still missing stuff), but nothing about how to provide some affinity | |
| 17:43:42 | dansmith | and I'm super concerned about altering this fundamental part of nova, especially without serious planning | |
| 17:43:51 | bauzas | efried: sounded like people were interested in, including mnaser | |
| 17:44:16 | bauzas | dansmith: that's the reason why we asked to *not* change the notion of a flavor | |
| 17:44:25 | bauzas | a flavor remains a flavor | |
| 17:45:00 | bauzas | they can compose bits of something, but the result of this API is a flavor | |
| 17:45:01 | dansmith | yep, and that helps, but it still brings a lot of complexity to everything that looks at flavors (which is lots of stuff) and also, with no affinity, it's just a toy for single-tenant clouds where everyone is trusted, IMHO | |
| 17:45:26 | efried | dansmith: I all along have assumed that backward compat of current flavor usage would not be affected, period. Agree that part is worth -1ing all day until addressed in the spec. My -2 was for "not worth the effort" -- but if folks are clamoring, I can be persuaded otherwise. | |
| 17:45:35 | bauzas | dansmith: honestly, that's why I don't want this to be in for example POST /servers | |
| 17:45:59 | bauzas | it would be just a os-stuff-my-flavor API, that's it | |
| 17:46:21 | mriedem | aren't you describing basically a flavor template? | |
| 17:46:24 | dansmith | efried: keeping the flavor whole helps the loss of feature, but doesn't help needing to touch everywhere that handles flavors | |
| 17:46:27 | bauzas | mriedem: -ish | |
| 17:46:44 | mriedem | wouldn't a flavor template be a lot simpler? | |
| 17:47:10 | mriedem | create a flavor based on a generic template with extra specs and then override whatever things are unique to that flavor | |
| 17:47:15 | efried | dansmith: Also been assuming/pushing for the composition to happen just once, at spawn time, whereupon all the contents go into the instance's existing flavor record. | |
| 17:47:17 | bauzas | mriedem: that's one of the approaches | |
| 17:47:26 | mriedem | though that doesn't help with the explosion | |
| 17:47:41 | bauzas | mriedem: correct, and we said that too | |
| 17:47:57 | mriedem | nested flavors! | |
| 17:47:59 | efried | That (composition at spawn only) hits POST /servers, but nothing else. No explosion. | |
| 17:48:01 | bauzas | I just feel people want a Domino's Make-My-Pizza generator thingy | |
| 17:48:12 | mriedem | efried: if you add it to spawn people are going to want it in resize also | |