| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-19 | |||
| 08:01:27 | alex_xu | kashyap: not sure how ceilometer enable those meters https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/libvirt/inspector.py#L218, since nova doesn't pass those parameter to libvirt | |
| 08:01:54 | kashyap | Yeah, was wondering the same; thanks for the code pointer | |
| 08:04:07 | cdent | alex_xu, kashyap : I seem to recall that at some point ceilometer made their own compute node agent rather than listening to nova, because nova didn't want to give all the information that ceilo wanted to get | |
| 08:04:30 | cdent | I may be remembering wrong though. Also I have zero context here so I may be butting in with info that you've already got. | |
| 08:04:57 | kashyap | cdent: No, I didn't know what you said; that's useful to know | |
| 08:05:14 | cdent | kashyap: you'll definitely want to check me on that. It's a vague memory | |
| 08:05:17 | kashyap | cdent: The context is this patch: https://review.opendev.org/#/c/669129/ | |
| 08:05:50 | kashyap | cdent: Linux kernel has removed the underlying infrastructure for Intel "CMT" | |
| 08:06:05 | cdent | seems like it's a done deal then, yeah? | |
| 08:06:10 | kashyap | Right | |
| 08:06:29 | kashyap | We already today warn if any anyone specifies the "CMT" 'performance' events via Nova's config attributes | |
| 08:06:43 | cdent | kill it! kill it with fire! | |
| 08:06:51 | kashyap | Hehe, yeah. | |
| 08:07:31 | kashyap | However there are *other* 'perf' events besides the CMT variants. So I asked on the mailing list if anyone is using them at all. | |
| 08:07:54 | kashyap | [While bearing in mind -discuss list audience does not represent all users ever :D] | |
| 08:13:47 | alex_xu | kashyap: we can write other event than cmt https://github.com/openstack/nova/blob/master/nova/conf/libvirt.py#L785 | |
| 08:14:26 | kashyap | alex_xu: Right, I wrote that documentation :-) | |
| 08:14:48 | kashyap | I was merely wondering if there are real-world users who are using these other events at all | |
| 08:15:06 | alex_xu | kashyap: I missed understand that conf only can can fill cmt, mbm..etc | |
| 08:15:26 | kashyap | No, not really -- any of the allowable `perf` events by libvirt | |
| 08:15:35 | alex_xu | kashyap: yes, that is always a question hard to answer | |
| 08:15:35 | kashyap | Hence my question on the list about *non-CMT* events | |
| 08:15:44 | kashyap | Right | |
| 08:17:03 | alex_xu | oops | |
| 08:19:08 | kashyap | alex_xu: Sorry if I didn't phrase it clearly. | |
| 09:29:26 | openstackgerrit | zhangyangyang proposed openstack/nova master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/671694 | |
| 10:32:22 | openstackgerrit | zhangyangyang proposed openstack/nova master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/671694 | |
| 11:35:10 | artom | alex_xu, still around? I figure we can talk here rather than on gerrit, about vpmem and NUMA LM | |
| 11:44:57 | artom | So the current flow is driver.cclm_dest -> rpc.cclm_source -> claim -> driver.numa_config | |
| 11:45:19 | artom | The claim has to happen before driver.numa_config, and presumably before driver.vpmem_config or whatever you'd call it | |
| 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 | |