| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-19 | |||
| 11:45:53 | artom | And rpc.cclm_source has to happen before the claim, because the source will tell the destination if it's trying to perform a NUMA live migration | |
| 11:46:14 | artom | (We can't just check instance.numa_topology because the source might be an old compute) | |
| 11:46:24 | artom | (But that could change in a later release) | |
| 11:46:57 | artom | So really the question is, can rpc.cclm_source happen before driver.cclm_dest | |
| 11:47:36 | artom | *what | |
| 11:48:04 | artom | Ah, it's passed the dest_check_data | |
| 11:51:12 | artom | So it doesn't look like we can change the order | |
| 11:51:33 | artom | I'll put all that ^^ in gerrit :) | |
| 13:22:43 | efried | stephenfin: there's this spec https://review.opendev.org/#/c/668656 about mixing VCPU/PCPU in one instance. | |
| 13:22:49 | efried | I see you looked at it a few patch sets ago | |
| 13:23:01 | stephenfin | Yup. I really don't want that to happen this cycle | |
| 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 | |