| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-07 | |||
| 12:31:18 | sean-k-mooney | stephenfin: any comments ^ | |
| 12:33:19 | sean-k-mooney | cgoncalves: having should_provide_port in the port profile may be useful as a seperate change to help address https://bugs.launchpad.net/nova/+bug/1747496 in the future but should not be need for your usecase | |
| 12:33:21 | openstack | Launchpad bug 1747496 in OpenStack Compute (nova) "MTUs are not set for VIFs if using kernel ovs + hybrid plug = false" [Medium,Confirmed] - Assigned to sean mooney (sean-k-mooney) | |
| 12:34:14 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [placement] Add sending global request ID in put (3) https://review.openstack.org/531280 | |
| 12:35:33 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [placement] Add sending global request ID in get https://review.openstack.org/531299 | |
| 12:35:43 | cgoncalves | sean-k-mooney: yeah, that is what I am considering (the refactor part). a gap there would be lack of security group for that port, I guess | |
| 12:36:29 | sean-k-mooney | wanghongtao do you see any error in the libvirt instance log? it should be under /var/log/libvirt/qemu/instance... | |
| 12:36:57 | cgoncalves | sean-k-mooney: FYI this is what i would like to get rid of by leveraging os-vif: https://github.com/openstack/octavia/blob/master/devstack/plugin.sh#L316-L344 | |
| 12:38:27 | sean-k-mooney | cgoncalves: well os-vif would be setting the neutron port uuid for the port in the external_id filed of the ovsdb so neutron shoudl add the security groups if you are using the openvsiwthc security gorup driver. | |
| 12:38:49 | sean-k-mooney | cgoncalves: but you are correct if you were using iptables you would need to do hybrid_plug | |
| 12:39:49 | sean-k-mooney | cgoncalves: e.g. crate tap/veth in linux bridge and connect that lb to ovs | |
| 12:39:58 | sean-k-mooney | via a veth | |
| 12:44:58 | cgoncalves | sean-k-mooney: right. in that case it would make much sense to name the vif VIFInternal because there would be any ovs internal port created | |
| 12:46:02 | wanghongtao | log no any error the vm is running in the hypervisor in the nova is shutdown | |
| 12:48:12 | sean-k-mooney | wanghongtao: ah nova has a periodic check in the compute to see if vms are still running. if it finds that they are not i belive it updates the state in the db to reflect that but i dont think it work the other way? dansmith melwitt stephenfin might be able to confirm | |
| 12:50:00 | sean-k-mooney | cgoncalves: well a os-vif vif object is not the same as a neutron vif type. the neutron vif_ovs + hybrid_plug=false is mapped to VIFOpenvswitch but vif_ovs + hybrid_plug=true is VIFBridge | |
| 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 | mriedem | which we wanted to get in since we can't backport it | |
| 15:31:48 | dansmith | yup | |
| 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. | |