| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-18 | |||
| 21:52:08 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (21) https://review.opendev.org/576709 | |
| 21:52:38 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22) https://review.opendev.org/576712 | |
| 21:54:00 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add database schema upgrade check https://review.opendev.org/667047 | |
| 21:54:20 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add a live migration regression test https://review.opendev.org/641200 | |
| 21:54:37 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix cleaning up console tokens https://review.opendev.org/637716 | |
| 22:36:18 | dustinc_OSCON | Anyone use any tools for reviewing local diffs before pushing other than ‘git diff’? | |
| 23:17:37 | efried | dustinc_OSCON: I have in the past, don't really anymore. Long ago I used one called beyond compare. But I don't remember whether it worked with diffs (à la git) or with two actual copies of the file, probably the latter. | |
| 23:18:04 | efried | If I'm really having trouble seeing what I want to see via git diff, I'll actually just push the change to gerrit and review it there. | |
| #openstack-nova - 2019-07-19 | |||
| 00:05:06 | openstackgerrit | melanie witt proposed openstack/nova master: Avoid logging traceback when detach device not found https://review.opendev.org/671640 | |
| 01:07:08 | alex_xu | kashyap: I replied you on the maillist, looks like ceilometer still using the perf meters, include some of meter isn't just about cmt. | |
| 02:38:42 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix cleaning up console tokens https://review.opendev.org/637716 | |
| 03:09:47 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Replace "integrated-gate-py3" template with new "integrated-gate-compute" https://review.opendev.org/671551 | |
| 05:29:39 | openstackgerrit | Alex Xu proposed openstack/nova-specs master: Use PCPU and VCPU in one instance https://review.opendev.org/668656 | |
| 05:37:59 | openstackgerrit | Alex Xu proposed openstack/nova-specs master: Use PCPU and VCPU in one instance https://review.opendev.org/668656 | |
| 07:58:39 | kashyap | alex_xu: Will check; thank you | |
| 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. | |