| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-07-17 | |||
| 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 | |
| 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 | |
| 14:53:33 | kashyap | lyarwood: Hiya, definitely | |
| 14:54:20 | gibi | gmann: cool | |
| 14:57:45 | kashyap | lyarwood: Looks good; also bonus marks for the nice reproducer write-up! | |
| 14:58:06 | sean-k-mooney | gmann: im not sure that any of the service got to the poitn where they could have contol planes on two differetn versions did they | |
| 14:58:33 | sean-k-mooney | that would be the main issue for nova | |
| 14:59:15 | sean-k-mooney | n an n+1 would expect diffferent db version and potatiall rpcs version so we cannot run both in parralel | |
| 14:59:31 | sean-k-mooney | even if we can upgrade the contoelr indepently of the comptue nodes | |