| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-07 | |||
| 09:03:53 | claudiub|2 | artom: hi. around? | |
| 09:15:48 | hrw | bauzas: https://paste.fedoraproject.org/paste/vUX3Ar7XAQ3J1k~Au4kzfw - something like that but with less '=unknown' values, right? | |
| 09:24:39 | lyarwood | bauzas, melwitt ; https://review.openstack.org/#/c/540679/ is another follow up to matt's https://review.openstack.org/#/c/539739/ bugfix for LM with encrypted volumes if you have time today. | |
| 09:26:12 | claudiub|2 | artom: just so you know: https://review.openstack.org/#/c/541633/ | |
| 09:28:51 | bauzas | hrw: what you're pasting is for the feature classification, good with me | |
| 09:29:09 | bauzas | hrw: there is another https://github.com/openstack/nova/blob/master/doc/source/user/support-matrix.ini to update | |
| 09:29:09 | hrw | bauzas: thx. now I know what to do | |
| 09:29:16 | hrw | sure | |
| 09:29:25 | bauzas | hrw: you can test your docs change by running tox -edocs | |
| 09:29:41 | bauzas | and then the directory build/html/ | |
| 09:30:43 | bauzas | lyarwood: okay, will look | |
| 09:31:47 | hrw | ok. refstack output is useless for that | |
| 09:32:09 | hrw | will have to check how to run tempest | |
| 09:32:09 | lyarwood | bauzas: thanks | |
| 09:47:11 | hrw | ok, got tempest running | |
| 09:50:12 | hrw | meh. whoever wrote support matrix docs was neither fan of people nor tempest | |
| 09:50:51 | hrw | tempest output gives test names. refstack gives test names from tempest. | |
| 09:51:09 | hrw | support matrix requires you to dig through tempest code to map UUID to test names | |
| 09:52:22 | hrw | why.... | |
| 09:54:59 | hrw | now to check 'operation.server-shelve' I need to dig out 1164e700-0af0-4a4c-8792-35909a88743c and c1b6318c-b9da-490b-9c67-9339b627271f uuids from tempest code to know what to look for in tempest.log | |
| 09:55:10 | hrw | what kind of #$%@$%@ wrote it that way? | |
| 09:55:48 | hrw | was it so hard to either inject UUIDs into tempest.log or use test names? | |
| 09:56:16 | openstackgerrit | sahid proposed openstack/nova stable/pike: live-mig: keep disk device address same https://review.openstack.org/541642 | |
| 10:09:11 | ameeda | Morning :) | |
| 10:09:29 | ameeda | I need +2w here https://review.openstack.org/#/c/528385/ | |
| 10:17:08 | hrw | bauzas: sorry but with this level of tools I really wonder how status matrix moves forward | |
| 10:18:45 | bauzas | hrw: sorry in a meeting | |
| 10:21:35 | hrw | np | |
| 10:21:58 | openstackgerrit | Merged openstack/nova stable/pike: Fix format in live-migration-usage.rst https://review.openstack.org/535871 | |
| 10:23:56 | openstackgerrit | jichenjc proposed openstack/nova master: Only log during pop retry phase https://review.openstack.org/541655 | |
| 10:36:43 | openstackgerrit | Leopard Ma proposed openstack/nova master: fix paused instance not support shelve https://review.openstack.org/541660 | |
| 10:50:45 | cgoncalves | sean-k-mooney: ping | |
| 10:52:01 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Make bdms querying in multi-cell use scatter-gather and ignore down cell https://review.openstack.org/541246 | |
| 10:56:33 | stephenfin | sean-k-mooney, cfriesen, efried: Just read through all that log from last night. We really need to get this information into a doc or spec somewhere | |
| 10:58:27 | stephenfin | efried: Also, as cfriesen points out, guests with multiple virtual NUMA nodes are a thing and a necessary thing at that (it's the only way you can attach multiple PCI devices to an instance, if those PCI devices aren't affined to the same socket) | |
| 11:00:32 | cgoncalves | ralonsoh: hi. do you plan to resume https://review.openstack.org/#/c/485228 ? | |
| 11:02:43 | cgoncalves | ralonsoh: also on that patch, isn't the bridge name missing in VIFOpenVSwitchPatchPort? | |
| 11:07:58 | jianghuaw | bauzas, hi. | |
| 11:16:34 | hrw | bauzas: are there plans to update support-matrix.ini cli calls to use openstackclient instead of bunch of clients per service? | |
| 11:20:58 | openstackgerrit | melissaml proposed openstack/nova master: fix link https://review.openstack.org/541675 | |
| 12:04:11 | sean-k-mooney | cgoncalves: pong o/ | |
| 12:04:59 | sean-k-mooney | stephenfin: yes it might make sense to pull together an etherpad. just got ptg approval | |
| 12:07:05 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Move resource provider objects into placement hierarchy https://review.openstack.org/540049 | |
| 12:07:06 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Isolate placement database config https://review.openstack.org/541435 | |
| 12:07:06 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 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 | cgoncalves | sean-k-mooney: hmm what if a tap attached to an ovs/lb is required? | |
| 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:51 | cgoncalves | sean-k-mooney: actually for the use case I have at hands a veth would make more sense | |
| 12:19:54 | cgoncalves | sean-k-mooney: thanks! | |
| 12:19:54 | sean-k-mooney | cgoncalves: well it can only be attached to one or the other at any one time | |
| 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 | 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:06 | openstackgerrit | Merged openstack/nova master: Address comments from I51adbbdf13711e463b4d25c2ffd4a3123cd65675 https://review.openstack.org/541455 | |
| 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 | 2.when vm state is stopped i virsh start the vm why the result is still stopped | |
| 12:29:41 | wanghongtao | 1.when vm state is running i virsh shutdown the vm state result is 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 | |