| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-07-17 | |||
| 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 | |
| 15:06:22 | gmann | sean-k-mooney: is not load balancer should disable n-api on node which is going to be upgraded and redirect request to other api node. once first api node is upgraded then bring up the n-api and disable 2nd api node .. | |
| 15:09:18 | gmann | i mean HAProxy should be disable the request on one api node when we upgrade that so that request can be served from other api node and zero downtime on api service | |
| 15:11:52 | sean-k-mooney | gmann: no that wont work | |
| 15:18:05 | bauzas | gibi: dansmith: fwiw, sorry if I was unclear but i'll be there on week from July 27th to 30th (excluding Friday probably) | |
| 15:18:27 | gibi | bauzas: no worries. It turned out that there is nothing pressing to handle at M2 | |
| 15:18:31 | bauzas | but either way, all good if dansmith can release m-2 and lead the meeting :) | |
| 15:18:36 | gibi | :) | |
| 15:20:58 | sean-k-mooney | gmann: its not just the api its also the conductor and schuler that need to agree on the db schemes and rpc verions | |
| 15:29:25 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Support SRIOV interface attach and detach https://review.opendev.org/741601 | |
| 15:29:50 | gibi | stephenfin, sean-k-mooney: ^^ fixed up the spec | |
| 15:30:46 | melwitt | lyarwood: commented, there are some odd things in the tests (args passed but not used) and tests that are simulating non-real situations, not sure if that was intended | |