| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-07-17 | |||
| 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 | stephenfin | :P | |
| 13:37:19 | bauzas | (you need to know about Weeds, dude) | |
| 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 | stephenfin | Right, but what about revert? | |
| 13:45:26 | sean-k-mooney | stephenfin: there is no way to convert form one type to the other | |
| 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 | 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: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: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 | |
| 13:57:55 | sean-k-mooney | https://review.opendev.org/#/c/738551/7/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py@2163 | |
| 13:57:58 | melwitt | lyarwood: sure, will do | |
| 13:58:09 | sean-k-mooney | which is also setting the openflow versions | |
| 14:01:42 | mnaser | ovs-vsctl set bridge br-int protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14,OpenFlow15 doesn't really fix much | |
| 14:02:45 | mnaser | let me restart the ovs agent after that | |
| 14:31:25 | gibi | stephenfin: regarding vTPM. We can block the resize and rebuild if that result in a loss of vTPM data as a first step. I'm fine with taht | |
| 14:43:11 | gibi | dansmith: hi! I talked to the release team about M2 and it turned out that we don't need a nova release just an os-vif and python-novaclient release and those can be made before M2. So I will propose those lib releases next week and then there is nothing to do at M2 from release perspective | |
| 14:43:37 | dansmith | gibi: I saw, cool, I *definitely* volunteer then :) | |
| 14:43:50 | gibi | cool :) | |
| 14:45:33 | gibi | dansmith: can I ask you to run the weekly meeting on the 30th? | |
| 14:46:14 | dansmith | gibi: yeah | |
| 14:46:46 | gibi | thank you | |
| 14:49:37 | gmann | gibi: zero_downtime upgrade job use zero_downtime/hooks/run_tests.sh which i did not find in git history at all when it was added/remvoed - https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/playbooks/legacy/grenade-dsvm-neutron-multinode-zero-downtime/run.yaml#L45 | |
| 14:50:08 | gmann | we do not test zero downtime upgrade (i think none of project does) in any other job | |
| 14:51:15 | gmann | so i agree to remove this broken job and if we want/do test zero_downtime in future then we write new job on zuulv3 | |
| 14:51:29 | gibi | gmann: thanks for checking | |
| 14:52:13 | gmann | none of the projects use zero_downtime upgrade TC tag https://governance.openstack.org/tc/reference/tags/assert_supports-zero-downtime-upgrade.html | |
| 14:52:54 | lyarwood | kashyap: https://review.opendev.org/#/c/741561/ - if you have time for a review before leaving for the weekend btw | |
| 14:53:13 | gmann | I will remove(once all stable branch remove the job ) the job definition also from opensatck-zuul-jobs as this job is only used by nova | |