| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-19 | |||
| 13:23:12 | efried | oh | |
| 13:23:13 | efried | whyzat? | |
| 13:23:24 | stephenfin | I've been working on cpu-resources, which that relies on, all this week and a good bit of last week | |
| 13:23:40 | efried | yes, obviously that's a hard dep | |
| 13:23:46 | stephenfin | The upgrade scenario is tricky af | |
| 13:24:19 | stephenfin | but it's being made easier by some assumptions I can make through a VM being all one kind of CPU | |
| 13:24:31 | efried | you mean reshaping allocations? | |
| 13:24:39 | stephenfin | Among other things, yeah | |
| 13:24:43 | efried | Hm | |
| 13:25:01 | stephenfin | The reason we dragged that out in the first place was because cpu-resources was horribly complex | |
| 13:25:07 | efried | yeah, I get that. | |
| 13:25:16 | efried | can a VM today have pinned and shared? | |
| 13:25:24 | stephenfin | Not today, no | |
| 13:25:33 | efried | oh, I see. Yeah, that makes a difference. | |
| 13:25:38 | stephenfin | Except for emulator threads | |
| 13:25:45 | stephenfin | But that's not the same thing at all | |
| 13:26:01 | stephenfin | Anyway, I'm not sure why dragging that complexity back in would be something we'd ever want to do | |
| 13:26:09 | efried | well | |
| 13:26:18 | stephenfin | This cycle, that is | |
| 13:26:20 | efried | there's a strong customer use case | |
| 13:26:22 | stephenfin | Next cycle, I'm all over that | |
| 13:26:42 | efried | tbc, the ask on you would be review, not code | |
| 13:26:50 | stephenfin | I figured there might be, aye :) | |
| 13:27:38 | efried | just not sure why we would want to say "next cycle" rather than "once cpu-resources is done" | |
| 13:27:46 | stephenfin | Tell you what, let's wait til I have code up | |
| 13:27:50 | stephenfin | Ha, jinx | |
| 13:27:54 | efried | which may wind up being the same thing, but ... yeah | |
| 13:28:04 | efried | except that spec freeze is next week | |
| 13:28:12 | stephenfin | Yeah, I'd like to wait to see how cpu-resources goes before committing to anything | |
| 13:28:21 | stephenfin | I wanted to have that up this week but unit test coupling is killing me | |
| 13:28:27 | stephenfin | and I haven't even started on the reshape | |
| 13:28:37 | efried | as you well know, approving a spec for this release doesn't "commit" us to getting it in this release. | |
| 13:29:09 | stephenfin | Technically, no, but it does send the wrong message to people that aren't as involved in nova as we are | |
| 13:29:11 | stephenfin | (PMs) | |
| 13:29:22 | efried | It would be a better story for Alex et al if they could go back and tell their downstream "approved, but considerable risk due to deps" than "no chance in Train". | |
| 13:29:33 | efried | yeah, Alex and I can manage PM expectations :) | |
| 13:29:38 | stephenfin | Suggesting we think this can land when I, for example, have very little confidence that it will | |
| 13:29:47 | stephenfin | Oh, I'm worried about my PM :P | |
| 13:30:14 | efried | okay. Alex and I can't manage your PM. | |
| 13:30:24 | stephenfin | Not sure anyone can, heh | |
| 13:30:31 | stephenfin | Anyway, not really the point | |
| 13:31:22 | stephenfin | As above, I'm not confident about landing that feature, but if the ask is to just review the spec, I can do that | |
| 13:31:54 | stephenfin | Though not today. I want to keep chipping away at these unit tests and hopefully get the first few patches pushed | |
| 13:32:26 | efried | I think it would be a good step if we can get you & sean-k-mooney agreeing to the design itself, before spec freeze. | |
| 13:33:03 | stephenfin | Yeah, that makes sense | |
| 13:33:10 | efried | Then we can armwrestle over whether it makes sense to merge it for Train with the caveat of high risk, or merge it in backlog/ | |
| 13:33:33 | stephenfin | Okay, I can set aside time to do that early next week, maybe in person with sean-k-mooney | |
| 13:33:39 | efried | thank you sir | |
| 13:33:46 | efried | and with alex_xu | |
| 13:34:14 | sean-k-mooney | sorry was away form my laptop what was the context? | |
| 13:34:14 | stephenfin | In person might be tough there, but sure :) | |
| 13:34:23 | efried | easier for you than for me. | |
| 13:34:36 | sean-k-mooney | efried: i think he ment alex | |
| 13:34:46 | efried | sean-k-mooney: we're talking about the mixed PCPU/VCPU spec | |
| 13:34:57 | sean-k-mooney | oh ok | |
| 13:35:40 | efried | TLDR, stephenfin and I both agree it would be quite high risk for Train, and need to decide whether we want to merge it with that caveat or take a hard line and explicitly punt it. But in either case, I would like to see the design sorted before spec freeze, so we merge it either to train/ or backlog/. | |
| 13:35:52 | sean-k-mooney | for what its worth i think we could do that but im concerned with the scope. e.g. if we had completed teh rest fo the cpu stuff by m2 i would have been fine with it | |
| 13:36:30 | sean-k-mooney | efried: ok | |
| 13:36:35 | sean-k-mooney | ill look at it again | |
| 13:36:41 | efried | thanks | |
| 13:36:46 | sean-k-mooney | i think at most we only need 1 extraspec | |
| 13:37:18 | sean-k-mooney | not the two that are proposed. and i would prefer it to be a new one rather then messing with hw:cpu_policy | |
| 13:37:37 | sean-k-mooney | spec freeze is wednesday right? | |
| 13:37:49 | sean-k-mooney | or thrusday? next week in either case | |
| 13:38:01 | stephenfin | I'd rather we used 'resources:VCPU' and 'resources:PCPU' but I don't recall why that wasn't chosen again | |
| 13:38:04 | stephenfin | I need to look at it again | |
| 13:38:10 | stephenfin | next week though! | |
| 13:38:37 | sean-k-mooney | stephenfin: because we never want people ot use resocues: driectly and that does not provide a way to say which cpus are the pinned ones | |
| 13:39:10 | stephenfin | That's the one | |
| 13:39:33 | stephenfin | jaypipes will be turning over in his OpenStack grave though | |
| 13:41:38 | efried | FWIW at every turn I'm finding I prefer using non-Placement-isms in the flavor, that get translated internally to Placement-isms. | |
| 13:42:06 | efried | particularly since we have the request_filter framework now. | |
| 13:42:36 | sean-k-mooney | the main disadvandate to useing the placment stuff direcly is if the modeling in placment chagnes you have to chagne your flavors | |
| 13:42:43 | efried | that too | |
| 13:43:26 | efried | another big one is that you sometimes don't know enough at flavor time to construct all the proper placement-isms. | |
| 13:43:37 | sean-k-mooney | right | |
| 13:43:48 | efried | This will become more and more true as we start splitting out NUMA, devices, bandwidth, etc. | |
| 13:43:49 | sean-k-mooney | the image can enable pinning or numa | |
| 13:43:54 | efried | yup | |
| 13:44:11 | efried | we have pieces coming together from several places and there will need to be placement syntax tying them together (e.g. affinity) | |
| 13:44:23 | efried | but you can't know that until schedule time when all the pieces are assembled. | |
| 13:44:53 | efried | gibi: you still around? | |
| 13:50:36 | sean-k-mooney | needssleep: i like the name :) i woke up today thinking it was thursday so i can agree with that statement | |
| 13:51:15 | gibi | efried: yes | |
| 13:51:52 | efried | gibi: o/ | |
| 13:51:52 | efried | What further is needed to secure your +2 on the providers.yaml spec https://review.opendev.org/#/c/612497/ ? | |
| 13:53:05 | gibi | efried: the '$COMPUTE_NODE' templating seems too much. If we simply allow to identify an RP by name then we can spare the complexity of the templating | |
| 13:53:33 | sean-k-mooney | gibi: personally i would be fine with suppport both uuid and name | |
| 13:53:54 | gibi | efried: if the rest of the team feels ok with the templating I won't stop it | |
| 13:54:43 | sean-k-mooney | you would usee uuid if you want to reference non root providers, or create them in the future and name to reference the root provider or any other named one | |
| 13:54:53 | efried | gibi: I added `name` back to the `identification` | |
| 13:55:21 | sean-k-mooney | im not oppsed to the templating by the way just my 2cents | |
| 13:55:35 | efried | gibi: and `$COMPUTE_NODE` allows us to hit ironic nodes, which (as dansmith convinced me yesterday) you wouldn't want to try to identify by hostname because the nodes managed by this compute can change when the hashring reshuffles. | |
| 13:55:40 | gibi | efried: sorry I stuck with PS12. reading PS 12 now | |
| 13:56:03 | gibi | I mean 13 | |
| 13:56:12 | efried | cool, thanks. | |
| 13:56:16 | openstackgerrit | **** proposed openstack/nova master: Nova: node should be deleted when last service is deleted https://review.opendev.org/671731 | |
| 13:57:14 | sean-k-mooney | am ^ | |
| 13:57:30 | sean-k-mooney | no ...? | |
| 13:57:49 | dansmith | lol | |