| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-07-17 | |||
| 13:22:55 | sean-k-mooney | ah ok | |
| 13:23:34 | mnaser | sean-k-mooney: but firewall driver is defined in neutron? and this is happening inside nova? | |
| 13:23:53 | mnaser | does nova become somehow aware from what firewall driver is being used? | |
| 13:24:23 | sean-k-mooney | yes | |
| 13:24:50 | sean-k-mooney | the vif binding_details has a hybrid_plug atribute | |
| 13:25:01 | mnaser | ah gotcha | |
| 13:25:07 | sean-k-mooney | its true for iptables and false for contrac | |
| 13:25:21 | sean-k-mooney | os-vif just does what neutron tells it to do | |
| 13:25:33 | mnaser | and so when donig the PUT for the binding | |
| 13:25:39 | mnaser | we get the info back telling us how to do it | |
| 13:25:44 | sean-k-mooney | yep | |
| 13:25:55 | mnaser | ok i see. i wonder if i can restart straight into openvswitch firewall driver | |
| 13:26:05 | sean-k-mooney | we use that respocne both to generate the libvirt xml and pass it to os-vif to tell it how to add the port | |
| 13:26:16 | sean-k-mooney | not quite | |
| 13:26:28 | sean-k-mooney | you can but the ports on exiting vms wont be rebound | |
| 13:26:28 | mnaser | i've looked at the code and it seems like it does have some code which 'remanages' it fwiw | |
| 13:26:45 | sean-k-mooney | so you need to live migrate teh vms or shelve and unshelve them | |
| 13:27:00 | sean-k-mooney | i guess any move operation but hardreboot wont fix it | |
| 13:27:18 | mnaser | sean-k-mooney: have you seen this code? https://github.com/openstack/neutron/blob/master/neutron/agent/linux/openvswitch_firewall/iptables.py | |
| 13:27:39 | mnaser | i guess i don't really care that much if the existing vms stay hybrid plugged | |
| 13:28:11 | sean-k-mooney | so wehn you change it i think that code is nolonger loaded or run | |
| 13:28:12 | mnaser | as long as the new ones don't use hybrid plugging which likely will result in faster os_vif plug time | |
| 13:28:48 | sean-k-mooney | so i thnk you will lose the ablity to manage security group rules on the exsting vms | |
| 13:29:53 | sean-k-mooney | i cant remeber if it was stien we added multiple port bining but when we started using that in nova we got the ability to live migrate between hosts with different firewall driver | |
| 13:30:09 | sean-k-mooney | which will allow you to change in a rolling upgade style | |
| 13:31:44 | mnaser | sean-k-mooney: i think looking at the code, switching can work, it removes the iptables rules and then just starts applying the rules on the existing qvo iface | |
| 13:31:50 | mnaser | https://github.com/openstack/neutron/blob/master/neutron/agent/linux/openvswitch_firewall/firewall.py#L614-L636 | |
| 13:32:11 | sean-k-mooney | ah ok ya i just notice it did not change the hybridg plug state | |
| 13:32:23 | sean-k-mooney | if it actully removes the iptable rules then it will work fine | |
| 13:32:45 | sean-k-mooney | the existging vm will keep using hybrid_plug untill there ports are rebound | |
| 13:32:46 | mnaser | we've switched them in the past and it wasn't an issue | |
| 13:32:58 | mnaser | yep, but the firwall rules will apply on the qvo instead of tap | |
| 13:33:12 | sean-k-mooney | cool | |
| 13:33:16 | mnaser | and new plugs will plumb tap in and eliminate qbr/qvo/qvb | |
| 13:33:28 | sean-k-mooney | yep | |
| 13:33:33 | mnaser | which will significantly reduce the number of ports on the system | |
| 13:33:47 | sean-k-mooney | it will devide it by 3 | |
| 13:33:55 | stephenfin | lyarwood: replied on https://review.opendev.org/#/c/699291/ | |
| 13:34:01 | mnaser | also i think tap interfaces won't have a random ipv6 addr show up | |
| 13:34:15 | sean-k-mooney | that is also likely | |
| 13:34:26 | sean-k-mooney | well maybe not | |
| 13:34:37 | sean-k-mooney | let me check | |
| 13:34:49 | mnaser | dmesg shows ADDRCONF events for qvb and qvo | |
| 13:34:52 | mnaser | but none for tap | |
| 13:35:01 | sean-k-mooney | they still get link local adresses | |
| 13:35:24 | sean-k-mooney | that siad it is some thing that we could disable in os-vif | |
| 13:35:46 | stephenfin | yo, bauzas. Want some d̶r̶u̶g̶s̶ patches? https://review.opendev.org/#/c/729595/ https://review.opendev.org/#/c/729596/ | |
| 13:35:49 | sean-k-mooney | actully no we cant | |
| 13:36:42 | sean-k-mooney | when os-vif creates the port on ovs its before qemu has created the tap | |
| 13:36:55 | bauzas | stephenfin: https://media.tenor.com/images/a2b7c73a67cf6c1a775466e6ad87d8b7/tenor.gif | |
| 13:37:19 | bauzas | (you need to know about Weeds, dude) | |
| 13:37:19 | stephenfin | :P | |
| 13:37:40 | stephenfin | I know GIFs | |
| 13:38:19 | bauzas | could I provide a French spec ? :p | |
| 13:38:59 | stephenfin | Sure! Just hope you're happy with artom being the only one reviewing it | |
| 13:41:07 | mnaser | sean-k-mooney: check this out -- https://github.com/openstack/neutron/blob/23e3213a07eb0b0fcdd2a1da36a847dde9beba57/neutron/tests/fullstack/test_firewall.py | |
| 13:41:17 | mnaser | neutron tests switching to openvswitch with agent restart :) | |
| 13:42:59 | stephenfin | lyarwood: Also, in case you didn't know already, I removed the auto-branch naming feature from git-review. If you want topics for e.g. https://review.opendev.org/#/c/741561/ you need to create the branch yourself | |
| 13:43:50 | sean-k-mooney | mnaser: cool | |
| 13:44:07 | sean-k-mooney | mnaser: that makes the upgrade path much smother | |
| 13:44:20 | stephenfin | sean-k-mooney, gibi, (others): Need input of vTPM design. What should we do if we resize and the new flavor has a different vTPM config? | |
| 13:44:44 | sean-k-mooney | that was in the spec | |
| 13:45:12 | sean-k-mooney | we have 2 option reject the resize or what the spec says is we recreat it with the new format lossing all data | |
| 13:45:26 | sean-k-mooney | stephenfin: there is no way to convert form one type to the other | |
| 13:45:26 | stephenfin | Right, but what about revert? | |
| 13:45:39 | stephenfin | Is resize expected to be a destructive operation? | |
| 13:45:44 | stephenfin | I know rebuild is | |
| 13:45:49 | stephenfin | but didn't think resize was | |
| 13:45:53 | sean-k-mooney | it should not be an issue unless we are talking about same host resize | |
| 13:46:35 | stephenfin | Well it's awkward to implement, hence why I'm asking :) | |
| 13:46:57 | stephenfin | I need to stash the ID of the old key stored in the key manager service | |
| 13:47:01 | sean-k-mooney | well we dont want to destoy the old tpm untill resize confimr or reviert | |
| 13:47:17 | sean-k-mooney | yes you would | |
| 13:47:53 | sean-k-mooney | but you can do it the same way we do for flavors | |
| 13:48:46 | sean-k-mooney | stephenfin: basically what we said in the spec was pretend it really hardware | |
| 13:49:14 | stephenfin | Can't we just block it like we do for NUMA | |
| 13:49:26 | sean-k-mooney | for reall hardware if we swapped the mother board which is what a resize is then it would be lose the data | |
| 13:49:39 | sean-k-mooney | stephenfin: yes we could that was option 1 | |
| 13:50:04 | stephenfin | I'm tempted to suggest we do that anyway, since I think this is unlikely to be used much in practice | |
| 13:50:06 | openstackgerrit | Merged openstack/nova stable/queens: libvirt: Don't delete disks on shared storage during evacuate https://review.opendev.org/732717 | |
| 13:50:15 | stephenfin | so long as I explicitly block it like you did for NUMA | |
| 13:52:05 | sean-k-mooney | if you block it for resize i assume the same will be true for rebuild | |
| 13:52:17 | sean-k-mooney | rebuild is not ment to be destuctive | |
| 13:52:24 | stephenfin | that would be my thinking, yes | |
| 13:52:31 | sean-k-mooney | but it would be if an only if you cnaged the type | |
| 13:52:35 | stephenfin | config from flavor + image meta must be identical | |
| 13:52:56 | sean-k-mooney | yep whcih is exactly what we do for numa | |
| 13:53:00 | sean-k-mooney | on rebuild at least | |
| 13:53:32 | sean-k-mooney | but before going down this route | |
| 13:53:39 | sean-k-mooney | do you need to have 2 keys | |
| 13:53:54 | sean-k-mooney | could you not just use the same key for both vtpms | |
| 13:54:09 | stephenfin | that's an interesting point | |
| 13:54:38 | stephenfin | we could indeed, given the owner has changed | |
| 13:54:55 | stephenfin | let me see how that works | |
| 13:55:24 | stephenfin | twas all garbage anyway | |
| 13:55:36 | openstack | bugzilla.redhat.com bug 1782834 in openvswitch "Changing protocols in Bridge table doesn't take effect" [High,New] - Assigned to aconole | |
| 13:55:36 | mnaser | sean-k-mooney: fyi, you might find this interesting -- https://bugzilla.redhat.com/show_bug.cgi?id=1782834 and neutron workaround https://review.opendev.org/#/c/733674/ for ovs 2.12 | |
| 13:55:50 | sean-k-mooney | if that proves difficutl to implement we can use that as justification for blocking and move the two thing you tried into alternitives | |
| 13:57:33 | sean-k-mooney | mnaser: huh that inconveniant | |
| 13:57:53 | sean-k-mooney | mnaser: strangly enough i was asked to look at this patch earlier today | |