Earlier  
Posted Nick Remark
#openstack-nova - 2018-07-19
13:28:47 mriedem oh i guess probably not,
13:28:58 mriedem assertResourceRequestsEqual is about comparing the request to the flavor right?
13:29:09 mriedem i thought it was weird that they had to set expected.is_limit
13:29:14 mriedem sean-k-mooney: yeah
13:29:54 sean-k-mooney im not sure we would want to depend on a z stream release to delete that code
13:30:15 mriedem sean-k-mooney: it's likely not going to happen in stein anyway - that removal from nova
13:30:19 mriedem *rocky
13:31:16 sean-k-mooney oh ok well in either case its not blocked anymore so it can be done when it makes sense
13:34:09 openstackgerrit Matt Riedemann proposed openstack/nova master: Implement migrate_instance_start method for neutron https://review.openstack.org/556334
13:34:10 openstackgerrit Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423
13:34:11 openstackgerrit Matt Riedemann proposed openstack/nova master: Add VIFMigrateData.get_dest_vif https://review.openstack.org/566931
13:34:12 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: factor out pre_live_migration plug_vifs call https://review.openstack.org/566932
13:34:13 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: use dest host port bindings during pre_live_migration https://review.openstack.org/566933
13:34:14 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: use dest host vif migrate details for live migration https://review.openstack.org/551370
13:34:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Annotate flows and handle PortBindingDeletionFailed in ComputeManager https://review.openstack.org/551371
13:34:16 openstackgerrit Matt Riedemann proposed openstack/nova master: Port binding based on events during live migration https://review.openstack.org/434870
13:34:17 openstackgerrit Matt Riedemann proposed openstack/nova master: conductor: use port binding extended API in during live migrate https://review.openstack.org/522537
13:57:41 efried mriedem: I noodled with it a bit and came up with something that I think is a little cleaner and more explicit.
13:57:58 openstackgerrit Eric Fried proposed openstack/nova master: Disable limits if force_hosts or force_nodes is set https://review.openstack.org/576693
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

Earlier   Later