| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-07 | |||
| 08:58:51 | hrw | hm. https://refstack.openstack.org/#/results/29ec537b-1463-4fee-b860-1329455ea5df shows what pass/fail but hides parts which can be useful to fill matrix ;D | |
| 08:59:13 | openstackgerrit | sahid proposed openstack/nova master: libvirt: disconnect volume from host during detach https://review.openstack.org/515008 | |
| 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. | |