| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-07 | |||
| 12:07:06 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 12:07:06 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Isolate placement database config https://review.openstack.org/541435 | |
| 12:12:23 | cgoncalves | sean-k-mooney: I'd like to check if my understanding from your review of https://review.openstack.org/#/c/533713 is correct. instead of extending VIFBridge and VIFOpenVSwitch you're saying adding a new VIFTap. if that is the case, the should_provide_port would not be needed at all as the TAP device (VIFTap) would be created | |
| 12:13:37 | cgoncalves | sean-k-mooney: request of attachment of the TAP device (or VIFVeth, VIFGre, etc) would be by setting vif.network.bridge, right? | |
| 12:14:23 | sean-k-mooney | cgoncalves: oh hi sorry i have been meaning to get back to that review. am no i have some draft commets that ill publish later but in essence the os-vif vif objects are ment to carry only the infomation reqiured by a vif that is independet of the network backend that vif is uesed with | |
| 12:14:58 | sean-k-mooney | cgoncalves: so instead of putting the should_provide_port in the VIF it should in in the port profile as the port porfiled is backend specific | |
| 12:16:44 | sean-k-mooney | my comments regrading VIFTap vs VIFBridge and VIFOpenVSwitch is in regrades to what if anything the tap is connected to | |
| 12:17:32 | sean-k-mooney | VIFOpenVSwitch means it should be direcly attached to ovs VIFBridge means its attached to a linux bridge and VIFTap means its not attached to any bridge | |
| 12:19:09 | sean-k-mooney | cgoncalves: i just published the comments i had pending but not sure if i finished them but does that make sense? | |
| 12:19:09 | cgoncalves | sean-k-mooney: hmm what if a tap attached to an ovs/lb is required? | |
| 12:19:51 | cgoncalves | sean-k-mooney: actually for the use case I have at hands a veth would make more sense | |
| 12:19:54 | sean-k-mooney | cgoncalves: well it can only be attached to one or the other at any one time | |
| 12:19:54 | cgoncalves | sean-k-mooney: thanks! | |
| 12:20:22 | sean-k-mooney | cgoncalves: what is the usecase? | |
| 12:20:43 | cgoncalves | sean-k-mooney: one cannot attach a tap to an ovs and then the app connects to the tap device?? | |
| 12:21:15 | sean-k-mooney | cgoncalves: you should be able to do that | |
| 12:21:51 | sean-k-mooney | when you say application are you talking about a application on the host or a vm | |
| 12:22:02 | ameeda | bauzas: can you please give this review https://review.openstack.org/#/c/528385/ +2w | |
| 12:22:15 | cgoncalves | sean-k-mooney: application on the host | |
| 12:22:35 | sean-k-mooney | cgoncalves: in that case you want to use an ovs internal port. | |
| 12:22:45 | cgoncalves | sean-k-mooney: the use case is the octavia health manager that listens for heart beats sent from service vms connected to a neutron network | |
| 12:23:10 | cgoncalves | sean-k-mooney: correct, hence the should_provide_port in VIFOpenVSwitch that would create such ovs internal port | |
| 12:23:55 | sean-k-mooney | cgoncalves: yes and no. we wanted to have a different vif object for internal ports | |
| 12:24:06 | openstackgerrit | Merged openstack/nova master: Address comments from I51adbbdf13711e463b4d25c2ffd4a3123cd65675 https://review.openstack.org/541455 | |
| 12:24:06 | cgoncalves | sean-k-mooney: os-vif would take care of L1-l2 (incl. set of mac addr) and the app would set IP addressing | |
| 12:24:28 | cgoncalves | sean-k-mooney: right, that was what I get from your review | |
| 12:25:53 | cgoncalves | sean-k-mooney: so in that case a VIFOpenVSwitchInternalPort obj would make sense, plus the vif.network.bridge (or vif.profile.bridge?) set so that the plugin knows where to create the port | |
| 12:26:24 | cgoncalves | the same would be valid for e.g. VIFTap, VIFGre, VIFVeth, etc | |
| 12:26:34 | sean-k-mooney | cgoncalves: an ovs internal port cannont be use by a vm which is why it would be different form VIFOpenVSwitch with should_provide_port set in the port profile | |
| 12:27:33 | cgoncalves | sean-k-mooney: I'm not looking to use an ovs internal port by a vm, but by an app in the host | |
| 12:27:37 | sean-k-mooney | cgoncalves: yes VIFOpenVSwitchInternalPort wiht bridge set in the os-vif network object would be correct way to go | |
| 12:28:10 | sean-k-mooney | or perhap VIFInternal the name is long enough as it is | |
| 12:29:41 | wanghongtao | 1.when vm state is running i virsh shutdown the vm state result is stopped | |
| 12:29:41 | wanghongtao | 2.when vm state is stopped i virsh start the vm why the result is still stopped | |
| 12:30:55 | sean-k-mooney | cgoncalves: if you refactor your review to introduce a VIFInternal object and modify the ovs plugin to support it i will be happy with that. | |
| 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:-) | |