| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-18 | |||
| 20:32:06 | artom | Exactly | |
| 20:32:08 | efried | But as a warning, not sure if it's really worthwhile or not. | |
| 20:32:17 | artom | When it turned into a warning, is it really useful? | |
| 20:32:26 | efried | I'm not sure | |
| 20:32:34 | efried | it depends how the cold migration failure manifests | |
| 20:32:54 | efried | if it's one of those things where it's really hard to figure out why it happened, unless you have this warning, then we might want to keep it around. | |
| 20:33:27 | efried | then again, are you really going to notice this warning waaay back in the logs while you're investigating your cold mig failure. | |
| 20:36:17 | artom | To set migration.dest_host | |
| 20:36:27 | artom | (Which AFAICT isn't actually used for anything) | |
| 20:36:56 | artom | Ah, no, it's passed to migrate_disk_and_power_off | |
| 20:38:49 | artom | And then is used in the actual cleanup catch-all Exception handler | |
| 20:38:51 | artom | So yeah, problems | |
| 20:56:51 | efried | nova meeting in 4 minutes in #openstack-meeting | |
| 21:49:38 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (13) https://review.opendev.org/576020 | |
| 21:49:53 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (14) https://review.opendev.org/576027 | |
| 21:50:15 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (15) https://review.opendev.org/576031 | |
| 21:50:36 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (16) https://review.opendev.org/576299 | |
| 21:50:50 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (17) https://review.opendev.org/576344 | |
| 21:51:02 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (18) https://review.opendev.org/576673 | |
| 21:51:20 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (19) https://review.opendev.org/576676 | |
| 21:51:43 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (20) https://review.opendev.org/576689 | |
| 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 :) | |