| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-07 | |||
| 12:52:29 | wanghongtao | now vm is stopped in hypervisor and in nova | |
| 12:54:54 | sean-k-mooney | wanghongtao: yes and before you stoped it with virsh stop it was active in nova correct | |
| 12:55:35 | sean-k-mooney | if nova sees a vm is running and is marked as stopped in its db it will stop the vm. | |
| 12:56:22 | sean-k-mooney | if nova think a vm is running and discovers its stopped i think it updates it db to mark it as off. | |
| 12:58:02 | sean-k-mooney | so what i think happended is nova and libvirt both agreed the vm shoudl be running, then you stoped it with virsh and nova noticed and updated its db. then you started it with virsh and nova stopped it because it thinks it should not be running. | |
| 12:58:17 | sean-k-mooney | wanghongtao: have you tried starting it with nova | |
| 12:58:53 | cgoncalves | sean-k-mooney: agreed. what I don't get is what if hybrid_plug=True and consider the usecase I presented? what should be the ovs vif type created? not VIFInternal | |
| 12:59:26 | lyarwood | stephenfin: https://review.openstack.org/#/c/540679/ - if you have time can you take a look at this, a test only follow up for the native LUKS decryption spec. | |
| 13:00:35 | sean-k-mooney | cgoncalves: hybrid_plug=True proably VIFbridge with should_provide_port=true not sure | |
| 13:03:22 | sean-k-mooney | cgoncalves: if we just used VIFbridge is there any reason you could not use the bridge interface for octavia | |
| 13:03:47 | sean-k-mooney | cgoncalves: i would prefer not to use should_provide_port=true for interface that will not be used by vms | |
| 13:05:46 | cgoncalves | sean-k-mooney: ah, good one. using the bridge interface should suffice ;) | |
| 13:06:21 | cgoncalves | sean-k-mooney: I'll refactor by introducing VIFInternal. thanks! | |
| 13:15:09 | artom | claudiub|2, heya | |
| 13:15:15 | artom | claudiub|2, yeah, saw the Jenkins email | |
| 13:15:20 | artom | Will try to take a look today :) | |
| 13:17:51 | openstackgerrit | Andreas Jaeger proposed openstack/nova master: Make the InstanceMapping marker UUID-like https://review.openstack.org/539323 | |
| 13:23:37 | efried | stephenfin: Is the multi-numa-node guest thing only crucial for the PCI device aspect? | |
| 13:24:32 | efried | stephenfin: And in that case, you don't want anti-affinity for anti-affinity's sake; you just want the ability to get your devices from different NUMA nodes as necessary (cause otherwise you wouldn't have enough / the right ones available). Right? | |
| 13:24:50 | sean-k-mooney | efried: i think he is at lunch but there are other reason to use multi numa node guest | |
| 13:25:14 | sean-k-mooney | efried: e.g. large guest with more cpus then are availabel on a singel numa node when useing hugepages | |
| 13:25:38 | sean-k-mooney | efried: increased memory bandwidth | |
| 13:25:55 | efried | sean-k-mooney: So what, in that CPU case you would want affinity for "as many CPUs as possible" but allow the rest to bleed into other NUMA nodes? | |
| 13:26:15 | efried | sean-k-mooney: Or would it be sufficient in that case to say "no CPU affinity" and just let 'em spread out? | |
| 13:26:35 | sean-k-mooney | efried: no in the flavor extraspec you can specify how many cpus are assigned to each virtual numa node | |
| 13:26:56 | efried | sean-k-mooney: By what, naming the NUMA node? | |
| 13:27:17 | efried | So you could still get away with something that finicky using traits. | |
| 13:27:31 | efried | You could even do it so you didn't necessarily have to target a specific host, possibly. | |
| 13:27:40 | sean-k-mooney | efried: nameing the virtual numa nodes we have a nodeX sysntax where X is an integer starting at 0 | |
| 13:27:57 | sean-k-mooney | the virtual number has no baring in phyical numa nodes on the host | |
| 13:28:02 | efried | sean-k-mooney: Just so - use a trait for that, plus granular request groups, and you can get away with that. | |
| 13:28:17 | efried | sean-k-mooney: You wouldn't use the affinity concept at all in that case. | |
| 13:28:46 | sean-k-mooney | efried: you would use affinity to tie memory form a numa node to cpus for a numa node | |
| 13:29:41 | sean-k-mooney | e.g. 8 vpcu with 2G or ram guset with 2 numa nodes each with 4 cores and 1G of ram | |
| 13:29:44 | efried | sean-k-mooney: I have to run, but would you mind scribbling down a concrete use case or two for this? | |
| 13:30:23 | efried | I want to make sure we can cover it one way or the other. | |
| 13:30:52 | cdent | (more scribbling)++ | |
| 13:31:03 | sean-k-mooney | efried: sure stephenfin may have more to had but ill try to add a few flavor exampels to an eterhpad | |
| 13:31:11 | efried | Thank you | |
| 13:33:31 | openstackgerrit | Merged openstack/nova master: placement doc: Conflict caveat for DELETE APIs https://review.openstack.org/540919 | |
| 13:35:19 | sean-k-mooney | efried: this is one of the multi-numa flavor i use for my own testing http://paste.openstack.org/show/664744/ | |
| 13:36:20 | efried | sean-k-mooney: Roger that. I'll have some questions about it later on. gtg | |
| 13:37:19 | sean-k-mooney | efried: ill use that as a base however that is not the best example as i am depending on alot of implict behavor. ill work on smaples here https://etherpad.openstack.org/p/multi-numa-samples-for-placement talk later o/ | |
| 13:38:45 | jianghuaw | bauzas, gibi May you help to look at this support matrix doc for vGPU? https://review.openstack.org/#/c/540808/ | |
| 13:39:12 | jianghuaw | Hope it's not late for rc1. | |
| 13:39:14 | jianghuaw | thanks. | |
| 14:26:45 | ameeda | mriedem: I still need +2w here https://review.openstack.org/#/c/528385/. can you please help ? | |
| 14:27:32 | bauzas | jianghuaw: will look today, promised. | |
| 14:28:34 | jianghuaw | bauzas, thanks very much:-) | |
| 14:31:27 | openstackgerrit | Jacek Tomasiak proposed openstack/python-novaclient master: Fix listing of instances above API max_limit https://review.openstack.org/534222 | |
| 14:32:23 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Adds view builders for keypairs controller https://review.openstack.org/347289 | |
| 14:32:31 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Adds view builders for keypairs controller https://review.openstack.org/347289 | |
| 14:32:38 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: Provide basic data for AArch64 support matrix/functionality https://review.openstack.org/541728 | |
| 14:32:53 | hrw | bauzas: please take a look | |
| 15:20:42 | kashyap | sean-k-mooney: Wonder if you have thoughts on my last two comments on the design here: https://review.openstack.org/#/c/497457/18 | |
| 15:20:45 | kashyap | (No hurry.) | |
| 15:27:00 | mriedem | o/ | |
| 15:27:54 | cdent | o/ | |
| 15:28:46 | openstackgerrit | Lajos Katona proposed openstack/nova master: WIP: Add nested resources to server moving tests https://review.openstack.org/527728 | |
| 15:28:52 | hrw | http://logs.openstack.org/28/541728/1/check/build-openstack-sphinx-docs/7a3bf19/html/user/support-matrix.html is nice. had no idea that zuul will make it available | |
| 15:28:56 | lyarwood | \o morning | |
| 15:30:20 | dansmith | mriedem: so we just merged another compute rpc bump that breaks my patches | |
| 15:30:28 | dansmith | mriedem: surely we should be in lock down for that except for critical bits | |
| 15:30:33 | stephenfin | ltomasbo: Two comments left on https://review.openstack.org/#/c/540679/ | |
| 15:30:42 | stephenfin | Ooops, lyarwood ^ | |
| 15:30:45 | stephenfin | Sorry ltomasbo :) | |
| 15:31:21 | ltomasbo | :D | |
| 15:31:43 | mriedem | dansmith: it was likely gibi's evacuate late affinity check bug patch, | |
| 15:31:48 | dansmith | yup | |
| 15:31:48 | mriedem | which we wanted to get in since we can't backport it | |
| 15:32:08 | mriedem | that's the last thing i'm aware of | |
| 15:32:22 | dansmith | mriedem: ack, well, it broke a lot of stuff I just got done fixing, so I want to make sure we're done before I fix this again | |
| 15:33:09 | mriedem | i'm not aware of any other patches for rc1 that require rpc version bumps | |
| 15:33:38 | dansmith | okay | |
| 15:34:18 | kashyap | dansmith: Something less grumbly: As 'promised', I've spent a couple of hours this morning digging into the 'bandwidth' parameter. I also got the source reviewed by 2 upstream libvirt devs. Noted the review. Refer my latest two comments on the change: https://review.openstack.org/#/c/497457/ | |
| 15:34:29 | dansmith | kashyap: I've already replied | |
| 15:34:37 | kashyap | Ah, didn't even see yours! | |
| 15:34:52 | kashyap | dansmith: So here's even _more_ source-code deep dive discussion with Eric Blake, on that parameter: https://kashyapc.fedorapeople.org/virt/libvirt-bandwidth-API-parameter.txt | |
| 15:35:09 | kashyap | I cleaned up IRC conversation with Eric (libvirt / QEMU dev) on OFTC. And posted it there. | |
| 15:35:32 | kashyap | I learnt interesting things. I'm going to post an upstream libvirt API doc. These semantics should be documented. | |
| 15:35:35 | dansmith | kashyap: yep, the line of code sahid quoted makes it pretty clear which takes precedence | |
| 15:35:59 | kashyap | Eagle eyes there | |
| 15:37:52 | kashyap | So, your suggestion is also reasonable to me (instead of flipping the sequence of calls). Just setting it first, and run it _without_ setting the bandwidth parameter | |
| 15:41:57 | kashyap | Ah, I said the samething as you in the psuedo code - i.e. not supply the 'bandwidth' parameter on the second call. | |
| 15:43:05 | lyarwood | stephenfin: thanks updated, we don't do anything with the return in both cases. | |
| 15:44:48 | stephenfin | ltomasbo: Sweet. +2 from moi | |
| 15:47:39 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: wip: minimal qemu/libvirt for aarch64 https://review.openstack.org/541756 | |
| 15:50:02 | stephenfin | Anyone want to introduce some of that NUMA goodness into their day? Could do we another set of eyes on https://review.openstack.org/#/c/537363/ and the patches either side of it | |
| 15:52:45 | mriedem | efried: on https://bugs.launchpad.net/nova/+bug/1747511 - i was thinking, could we maybe try to rule out glanceclient as being an issue by doing a straight image API request to GET /images/{image_id} using KSA? | |
| 15:52:45 | openstack | Launchpad bug 1747511 in OpenStack Compute (nova) "server create fails with "Can not find requested image" when CONF.glance.api_servers is not set and [service_user] is set" [High,Confirmed] | |
| 15:53:36 | hrw | mriedem: maybe 3.6.0 libvirt a bit high but it is first version which worked nicely with nova without any extra changes | |
| 15:54:16 | efried | mriedem: Yeah, mordred would love you for that. | |
| 15:54:24 | mriedem | hrw: my point in that comment was i don't think docs is good enough, which is why we have the min version check per arch when the driver starts up | |
| 15:54:42 | mriedem | efried: i was thinking that /v2/v2/images thing is the issue as you pointed out, but you said it shouldn't be | |
| 15:54:45 | hrw | mriedem: sure. | |
| 15:55:02 | hrw | mriedem: the docs patch is something to start with | |
| 15:55:02 | mriedem | hrw: obviously introducing a min version check like that in the code would require an upgrade release note | |
| 15:55:04 | efried | mriedem: I said what? | |
| 15:55:12 | mriedem | hrw: i'd do it in the same patch | |
| 15:55:27 | mriedem | efried: i thought you said that glanceclient bug where the double versions are in the URL wouldn't be an issue for our ksa adapter code | |