| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-19 | |||
| 13:57:59 | efried | mriedem: ^ | |
| 13:58:04 | efried | aaaand I'll stop voting on it. | |
| 13:59:58 | mriedem | efried: so i guess it was needed for assertResourceRequestsEqual yeah? | |
| 14:04:59 | efried | mriedem: No, it wasn't before, but it is now. | |
| 14:05:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Disable limits if force_hosts or force_nodes is set https://review.openstack.org/576693 | |
| 14:05:12 | alex_xu | mriedem: efried this patch sounds pretty close https://review.openstack.org/#/c/560317/24, appreciate you can help on it | |
| 14:05:18 | mriedem | yeah i looked at assertResourceRequestsEqual and see it's checking _limit | |
| 14:06:53 | efried | mriedem: But it wasn't checking is_limit/_limit_candidates | |
| 14:07:05 | mriedem | efried: yup i noticed later | |
| 14:07:07 | mriedem | +2 | |
| 14:07:07 | efried | mriedem: We good with this now? | |
| 14:07:21 | mriedem | alex_xu: yup i'd also like kashyap to be ok with the extra cpu mode flags | |
| 14:07:24 | efried | mriedem: Should I approve it or hold off since I mucked with it significantly? | |
| 14:07:45 | mriedem | alex_xu: hmm, has anyone looked into the powerkvm ci result failures on that? | |
| 14:08:28 | mriedem | Jul 19 11:35:55.551312 devstack-xenial-ppc64-284262 nova-compute[24588]: ERROR nova.compute.manager libvirtError: internal error: Unknown CPU model ppc64le | |
| 14:08:51 | mriedem | mmedvede: ^ | |
| 14:09:26 | kashyap | mriedem: Is there a full log for it? | |
| 14:09:32 | mriedem | https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/17/560317/24/check/tempest-dsvm-full-xenial/a80ccf4/screen-n-cpu.txt.gz | |
| 14:09:44 | kashyap | That's fast; thanks | |
| 14:19:53 | kashyap | mriedem: Two things seem very off there: | |
| 14:20:20 | kashyap | First, the binary name is: 'qemu-system-ppc64' not: 'qemu-system-ppc64le' for both 'ppc64' and 'ppc64le'. | |
| 14:20:46 | kashyap | Second, talking to a colleague who does PPC stuff, he says: | |
| 14:20:52 | kashyap | For Power8 guests, <cpu mode='host-model'><model>power8</model></cpu>; for Power9 guests, s/8/9/. | |
| 14:21:06 | kashyap | So the CPU model 'ppc64le' doesn't make sense at all. | |
| 14:21:35 | mriedem | that's not the model in this config | |
| 14:21:40 | mriedem | cpu_model is None | |
| 14:21:42 | mriedem | cpu_mode='none' | |
| 14:21:47 | mriedem | virt_type='kvm' | |
| 14:21:55 | mriedem | arch is ppc64le | |
| 14:23:24 | kashyap | Ah, I was looking at the capabilities; that said, but they aren't using CPU _mode_ there in the guest XML | |
| 14:25:46 | kashyap | No, the mode is 'none'; /me goes back to the logs | |
| 14:26:38 | kashyap | Actually, Nova didn't even get to generating the guest XML there. | |
| 14:27:33 | kashyap | Because, it failed right before, when the baselineCPU() API is called with 'ppc64le' and libvirt complained. | |
| 14:30:19 | mriedem | yup | |
| 14:30:21 | openstackgerrit | Eric Fried proposed openstack/nova master: Docs for reporting CPU traits feature https://review.openstack.org/582902 | |
| 14:39:20 | openstackgerrit | do3meli proposed openstack/nova master: docs: add nova host-evacuate command to evacuate documentation https://review.openstack.org/578040 | |
| 14:40:10 | alex_xu | kashyap: so for the power, they are running guest with a different arch with host? | |
| 14:40:42 | alex_xu | mriedem: sorry, miss the powerkvm ci | |
| 14:42:44 | kashyap | alex_xu: Just added a comment in the review, based on a further chat with a libvirt dev who sometimes works with Power guests. | |
| 14:42:50 | kashyap | (On PS:24) | |
| 14:42:59 | alex_xu | kashyap: thanks a lot | |
| 15:01:33 | mriedem | https://github.com/openstack/nova/commit/2b7e2e8c1479fd2931ad6d99a9c1865976e44c21 | |
| 15:01:36 | mriedem | old school | |
| 15:04:14 | kashyap | mriedem: There are more gems in the Nova source: look for commit messages: "start of day" and "end of day" | |
| 15:04:55 | mriedem | i was just chasing a specific comment in the libvirt driver for it's origin | |
| 15:04:58 | mriedem | *its | |
| 15:06:06 | lei-zh1 | Hi mriedem kashyap, I just reply your comments, to see if I understand the case correctly | |
| 15:16:03 | openstackgerrit | Chen proposed openstack/python-novaclient master: Fix inconsistency https://review.openstack.org/572770 | |
| 15:21:36 | kashyap | lei-zh1: I'm on a call, will check the review once done. | |
| 15:22:29 | lei-zh1 | sure, no hurry | |
| 15:27:29 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Validate huge pages https://review.openstack.org/399653 | |
| 15:27:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: create functional test base class https://review.openstack.org/407055 | |
| 15:34:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix accumulated nits from port binding for live migration series https://review.openstack.org/583994 | |
| 15:38:23 | mriedem | lei-zh1: "From the conf Matt pasted, with cpu_mode not specified" | |
| 15:38:28 | mriedem | cpu_mode *is* specificed | |
| 15:38:30 | mriedem | *specified | |
| 15:38:33 | mriedem | but with value "none" | |
| 15:38:39 | mriedem | which is not equal to None | |
| 15:40:30 | mriedem | lei-zh1: my understanding is libvirt devs are recommending that the powerkvm ci should configure nova to use cpu_mode='host-model' with cpu_model='power8' | |
| 15:40:36 | mriedem | which isn't something you can control | |
| 15:40:45 | mriedem | and why i was trying to get a hold of mmedvede | |
| 15:41:38 | lei-zh1 | mriedem, ok, I got it | |
| 15:41:46 | mriedem | we can see that the host model in the capabilities is <model>POWER8</model> | |
| 15:45:20 | lei-zh1 | but I still need to handle the conf you mentioned, suppose it's a valid case, I should make a guess and set the model to power8, right? | |
| 15:45:25 | mriedem | i mean, we could hack something in here like, if cpu_mode='none' and arch == ppc64le, use cpu_mode='host-model' and cpu_model='power8' but it would be blatantly ignoring what's in nova.conf | |
| 15:48:20 | mriedem | lei-zh1: i left a couple of comments | |
| 15:48:30 | mriedem | you might just need to change 2 things: | |
| 15:48:37 | mriedem | if cpu.mode is None or cpu.mode == 'none' | |
| 15:48:47 | mriedem | 2. if arch == ppc64le: mode = 'power8' | |
| 15:50:47 | mriedem | efried: i think https://review.openstack.org/#/c/564440/ was originally part of https://review.openstack.org/#/c/564452/ and then split out | |
| 15:51:32 | efried | mriedem: It was originally like really early in the series and then moved up, but I don't think it was moved far enough to make dansmith happy. | |
| 15:51:47 | mriedem | > This is now at the end of the series. I've kept it separate from the "populate the thing" patch but that's to keep this readable. I can combine them if you don't mind the larger diff | |
| 15:51:55 | efried | mriedem: His original complaint - that we have dead conf options that say they do a thing they don't do - would still apply. | |
| 15:51:57 | mriedem | that's an old comment from stephenfin now too | |
| 15:52:06 | efried | mriedem: Yeah, I saw that, but it's not actually at the end of the series. | |
| 15:52:12 | mriedem | right | |
| 15:52:18 | efried | mriedem: Rule of thumb, I would think, is that the conf options ought to be in the same patch as the reno3 | |
| 15:52:23 | efried | s/3/./ | |
| 15:52:50 | stephenfin | efried: I can squash it with the following patch but https://review.openstack.org/#/c/564441/ is already quite beefy | |
| 15:53:00 | mriedem | so, | |
| 15:53:06 | stephenfin | Sorry, https://review.openstack.org/#/c/564452 | |
| 15:53:07 | mriedem | the other thing we can do, and we've done before, | |
| 15:53:18 | mriedem | is we don't approve the bottom thing until we've got +2s lined up on the thing to use it | |
| 15:53:36 | efried | yeah, that would be fine by me. | |
| 15:53:43 | mriedem | let's WIP the bottom thing then | |
| 15:54:04 | mriedem | done | |
| 15:54:20 | mriedem | i was just pulling this up coincidentally | |
| 15:54:34 | efried | I mean, I really don't feel it matters if we have a situation like this where conf options exist but don't work for a couple commits on the master branch during active development. | |
| 15:54:45 | efried | As long as we make sure we don't hit a release boundary with it. | |
| 15:54:48 | mriedem | right | |
| 15:54:53 | mriedem | and with 1 week to FF, it's risky | |
| 15:55:01 | mriedem | i'll review the rest of the series now | |
| 15:55:04 | mriedem | been meaning to anyway | |
| 15:56:23 | lei-zh1 | mriedem, please see my comments in the patch | |
| 16:02:20 | mriedem | gibi: i threw an idea in https://review.openstack.org/#/c/583347/ as an alternative for unsetting the spec_obj.instance_uuid while filtering hosts to get alternates, see what you think | |
| 16:02:43 | mriedem | either is a hack, but the alternative i just said might be a less impactful hack to any out of tree filters that rely on spec_obj.instance_uuid | |
| 16:05:28 | gibi | mriedem: those filters that rely on spec_obj.instance_uuid has the same issue as the anti-affinity one for multicreate alternates, that spec_obj.instance_uuid is actually invalid for the alternate scheduling. So I think the current patch fixes their issue as well | |
| 16:06:18 | mriedem | gibi: well, anything will explode in that path if it tries to access an unset spec_obj.instance_uuid | |
| 16:06:27 | mriedem | since we don't lazy-load that field in the RequestSpec object | |
| 16:06:46 | mriedem | i agree that filters shouldn't rely on that field *because* of multi-create | |