| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-07 | |||
| 17:12:25 | mriedem | dansmith: now that we have all of this stuff that depends on having computes at a certain version | |
| 17:12:25 | mdbooth | lyarwood mriedem: rebuild also disconnects twice. Once explicitly in compute manager, once again in the driver during destroy. | |
| 17:12:34 | sfinucan | So there's merit in keeping around the use_ipv6 option for building VIF filters in libvirt | |
| 17:12:43 | sfinucan | e.g. https://libvirt.org/formatnwfilter.html | |
| 17:12:44 | sfinucan | ? | |
| 17:13:08 | sean-k-mooney | sfinucan: am im not sure but i dont we use that and i dont think we should | |
| 17:13:09 | dansmith | mriedem: might be good to abstract it a bit if we do.. so report "LATEST" and "OLD" or something | |
| 17:13:33 | sean-k-mooney | sfinucan: i would like to completely remove libvirt form our port binding if we can | |
| 17:13:50 | mriedem | dansmith: yeah, was just thinking about a doc that armax is working on for get me a network and we don't have a way to tell you if your computes are new enough to use that | |
| 17:14:14 | sfinucan | sean-k-mooney: I don't think we can, assuming we want to keep the interface firewalls https://github.com/openstack/nova/blob/master/nova/virt/libvirt/firewall.py#L138-L179 | |
| 17:14:30 | dansmith | mriedem: aye, although they log the service version on startup I think so we could also just rely on that for the short term | |
| 17:14:31 | sean-k-mooney | sfinucan: the only place we use libvirt for port binding currently is the non hybrid plug case for ovs. that really should be done by os-vif | |
| 17:15:12 | sean-k-mooney | sfinucan: no we can we just need to not add the interfaces as an openvswithc interface in the libvirt xml. just add it as a generic tap | |
| 17:15:13 | lyarwood | mdbooth: ewww, we can't really remove the compute layer call as other virt drivers might not do that right? | |
| 17:15:30 | sean-k-mooney | sfinucan: then have os-vif add it to the ovs bridge | |
| 17:15:35 | mdbooth | lyarwood: Presumably not | |
| 17:15:42 | lyarwood | mdbooth: as mriedem said before I think it's just another case of us assuming that nothing bad will happen if you disconnect_volume twice :| | |
| 17:16:01 | mriedem | i said that? | |
| 17:16:02 | sean-k-mooney | sfinucan: where is _get_instance_filter_parameters used | |
| 17:16:18 | lyarwood | mriedem: something along the lines of that if I understood correctly, maybe I didn't | |
| 17:16:38 | sfinucan | sean-k-mooney: Here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/firewall.py#L181-L193 | |
| 17:16:39 | mriedem | if it was smart, then yes i said it | |
| 17:16:45 | mdbooth | hehe | |
| 17:16:59 | sfinucan | sean-k-mooney: Which is in turn called here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/firewall.py#L112-L136 | |
| 17:17:43 | sean-k-mooney | yep tracking back now. im trying to figure out if this code is still executed with os-vif | |
| 17:18:06 | sfinucan | sean-k-mooney: I think it is. It's called in a few places in the libvirt driver.py | |
| 17:18:09 | mdbooth | mriedem: So, I've been through the ERRORs generated against my NFS patch with a fine toothed comb. There are 2, and they're both existing errors where we're double-calling disconnect from higher up. They cause no ill effects other than the log message. | |
| 17:18:10 | sean-k-mooney | basically i think we could move this to os-vif if it was still needed | |
| 17:18:21 | cburgess | mriedem Sorry missed your messages yesterday, yes we use live_migration_progress_timeout why? | |
| 17:18:43 | mriedem | cburgess: https://review.openstack.org/#/c/429798 | |
| 17:18:46 | mdbooth | I originally made them ERROR because I didn't expect the errors higher up, which with hindsight perhaps I should have. | |
| 17:19:02 | mdbooth | I suggest I turn them into warnings and file bugs about them, but that we go with the NFS patch anyway. | |
| 17:19:07 | nikeshm | hi | |
| 17:19:11 | sean-k-mooney | sfinucan: so it is really called here https://github.com/openstack/nova/blob/417dac50364357000c479bb2cb7c71773172a930/nova/virt/libvirt/driver.py#L1371 | |
| 17:19:20 | nikeshm | i am getting this error libvirtError: Requested operation is not valid: pivot of disk 'vdb' requires an active copy job | |
| 17:19:30 | mriedem | lyarwood: ^ | |
| 17:20:28 | cburgess | mriedem Oh cute... thanks for the heads up. This might actually explain some issues we saw recently. | |
| 17:20:39 | nikeshm | tempest.api.compute.admin.test_volume_swap.TestVolumeSwap.test_volume_swap [416.350838s] ... FAILED | |
| 17:20:41 | mdbooth | lyarwood: If mriedem is looking for a detailed second opinion, I don't mind walking you through the logs in the morning. | |
| 17:20:50 | mdbooth | Would probably take an hour or so. | |
| 17:20:55 | lyarwood | mdbooth: sure | |
| 17:20:57 | sfinucan | sean-k-mooney: Yup | |
| 17:21:11 | sean-k-mooney | sfinucan: so this si currently called after plug but im not sure its valide to call it here in all cases. | |
| 17:21:13 | sfinucan | and it's used for "MAC, IP, and ARP spoofing protection" | |
| 17:21:18 | lyarwood | nikeshm: what virt_type are you using? | |
| 17:21:25 | mdbooth | lyarwood: Thanks! It's a date. | |
| 17:21:31 | sean-k-mooney | sfinucan: i dont think this will have any effect for vhost-user for example | |
| 17:21:46 | sfinucan | sean-k-mooney: No? How come? | |
| 17:22:10 | nikeshm | lyarwood: virt_type = qemu | |
| 17:22:16 | sean-k-mooney | how would that function configure mac,arp,ip spoofing on a vhost-user interfaces | |
| 17:22:30 | sean-k-mooney | sfinucan: that would have to be done in ovs | |
| 17:22:33 | lyarwood | nikeshm: and which verison of qemu? | |
| 17:22:41 | sfinucan | sean-k-mooney: aha, correct | |
| 17:22:48 | sfinucan | that is for IPTables only | |
| 17:23:03 | sfinucan | it's part of the IptablesFirewallDriver | |
| 17:23:09 | sean-k-mooney | sfinucan: it is for when you are using the old nova firewall not neutron security groups | |
| 17:23:23 | sfinucan | sean-k-mooney: danpb suggested otherwise though | |
| 17:23:25 | sean-k-mooney | sfinucan: it basically part of nova networks i think | |
| 17:23:36 | sean-k-mooney | sfinucan: i could be wrong | |
| 17:23:46 | mdbooth | lyarwood: Plan is to walk through the errors reported here: http://logs.openstack.org/09/395709/6/check/gate-tempest-dsvm-full-devstack-plugin-nfs-nv/c8091c2/logs/screen-n-cpu.txt.gz?level=ERROR | |
| 17:24:06 | sean-k-mooney | sfinucan: but i dont think this will have any eefect with the conntrack firewall driver in neutron for example | |
| 17:24:12 | dansmith | mriedem: you want me to replicate that multiline warning on each help string for transport and db? | |
| 17:24:43 | mriedem | dansmith: well they'd be slightly different but yeah, i don't think the actual docstring gets dumped in the cli help | |
| 17:24:45 | mriedem | i can check quick | |
| 17:25:15 | dansmith | oh I thought it did | |
| 17:25:18 | sean-k-mooney | sfinucan: looking at https://github.com/openstack/nova/blob/d5f113de34589933c23a7cecc25ca0bf5f47207d/nova/virt/libvirt/firewall.py#L117-L120 | |
| 17:25:22 | dansmith | that's the point of putting return value stuff in there right? | |
| 17:25:23 | mriedem | the help for the args is printed out, | |
| 17:25:31 | sean-k-mooney | sfinucan: it will disable this code if securty groupd are enabled | |
| 17:25:36 | mriedem | but i don't think the docstring gets into the help output for the command | |
| 17:25:45 | mriedem | and i guess i don't have a test vm handy to verify | |
| 17:25:50 | mriedem | but i had that issue with the nova-status stuff | |
| 17:25:55 | mriedem | which is why i also pushed for man pages | |
| 17:26:36 | dansmith | hmm | |
| 17:26:58 | dansmith | mriedem: remember you making me document the return values for the new cells commands there? I thought that was because the user, you know, sees that shit :) | |
| 17:27:38 | mriedem | do you have a devstack you can verify quick because i don't | |
| 17:27:42 | lyarwood | nikeshm: feel free to write this up in a bug btw if it's easier - https://bugs.launchpad.net/nova/+filebug | |
| 17:28:14 | dansmith | mriedem: I have an old one only, but let me look | |
| 17:28:46 | mriedem | just do like: nova-manage cell_v2 create_cell -h | |
| 17:29:01 | dansmith | it's too old for that :) | |
| 17:29:08 | sfinucan | sean-k-mooney: Yeah, all the guides I'm seeing suggest that nwfilter - the thing that reads that config - is only for ebtables | |
| 17:29:11 | sfinucan | i.e. not OVS | |
| 17:29:14 | sfinucan | https://www.redhat.com/archives/libvir-list/2013-November/msg00234.html | |
| 17:29:23 | dansmith | mriedem: my liberty system doesn't show that text at least | |
| 17:29:27 | dansmith | so unless something has changed... | |
| 17:29:37 | mriedem | nova-manage db sync -h | |
| 17:29:47 | mriedem | would show "Sync the database up to the most recent version" if it worked | |
| 17:30:08 | mriedem | it should show the help on the --version option though "Database version" | |
| 17:31:26 | sean-k-mooney | sfinucan: yes so this code should really only be run for linuxbridge or macvtap binding | |
| 17:31:47 | sean-k-mooney | so it proable should be moved into the linuxbridge pluging for os-vif | |
| 17:31:55 | sfinucan | sean-k-mooney: ...and even then, doesn't neutron have its own anti-spoofing stuff? | |
| 17:32:01 | sfinucan | e.g. http://kimizhang.com/neutron-ml2-port-security/ | |
| 17:32:03 | sean-k-mooney | for ovs yes | |
| 17:32:09 | sean-k-mooney | for linux bridge proably | |
| 17:32:13 | sean-k-mooney | not sure though | |
| 17:32:24 | sean-k-mooney | again i think this is mainly for nova-networks | |
| 17:32:25 | sfinucan | that blog suggests yes for linucbridge | |
| 17:32:31 | sfinucan | *linuxbridge | |
| 17:32:42 | openstackgerrit | Dan Smith proposed openstack/nova master: Add an update_cell command to nova-manage https://review.openstack.org/430354 | |
| 17:33:05 | sean-k-mooney | if you are using nova-netwokrs this code would be needed for firewall support because you would not have nova | |