16:01:10 #startmeeting Octavia 16:01:11 Meeting started Wed Feb 3 16:01:10 2021 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:15 The meeting name has been set to 'octavia' 16:01:20 #chair rm_work 16:01:21 Current chairs: johnsom rm_work 16:01:29 hi 16:01:29 o/ 16:01:30 Hi everyone 16:01:31 o/ 16:02:03 #topic Announcements 16:02:14 My weekly nag about the upcoming feature freeze: 16:02:22 Final client release is first week in March 16:02:28 Feature freeze for everything else is the second week in March 16:02:38 #link https://releases.openstack.org/wallaby/schedule.html 16:02:50 Any other announcements this week? 16:03:37 #topic Brief progress reports / bugs needing review 16:04:13 I am mostly focused on TripleO things currently, so a bit distracted. Mostly just doing reviews and helping folks with questions, etc. 16:04:15 Hey, FYI I cleaned up and have updated the Priority Review list 16:04:23 #link https://etherpad.opendev.org/p/octavia-priority-reviews 16:04:39 Oh, nice! 16:05:38 Yep, quite the list, but we have done it before! 16:06:12 lots of merge conflicts, I don't know whether the owners will update their patches 16:06:18 Thank you gthiemonge! 16:06:44 Feel free to ask folks on IRC. 16:06:55 * johnsom notes he probably has a few in that category as well 16:08:20 Any other updates this week? 16:09:46 #topic vip_subnet_id access bug (gthiemonge) 16:09:52 You have the floor.... 16:09:57 thanks 16:10:51 So a bug was reported this week: a user can create a load balancer plugged into the subnet of another user, by using the subnet UUID 16:11:21 there was an attempt to fix it in the past, but only the vip_network_id and vip_port_id were fixed 16:11:51 I have a small patch that fixes this issue: https://review.opendev.org/c/openstack/octavia/+/773798 16:12:19 basically it verifies that the user provided vip_subnet_id belongs to the user 16:12:41 but this patch triggers an interesting bug in octavia-tempest-plugin 16:12:45 Thank you for the patch 16:13:11 octavia-tempest-plugin uses a private subnet that is owned by the admin user for its IPv6 VIP test 16:13:24 #link https://opendev.org/openstack/octavia-tempest-plugin/src/branch/master/octavia_tempest_plugin/tests/test_base.py#L328-L329 16:13:43 so now, tempest is failing because it cannot create an IPv6 LB 16:14:08 I would like to have your opinion about that 16:14:21 if someone sees a way to fix or to work around this issue 16:14:48 Ah, yeah, we preference the IPv6 subnet that the tempest framework creates. I think this is because tempest also makes sure that subnet is routable (but I might be remembering that part wrong). 16:14:52 gthiemonge: can we do the obvious and create an ipv6 subnet owned by the user? 16:15:23 haleyb: yeah this is what I was thinking about 16:15:29 Yeah, that might be the right answer 16:15:47 haleyb: we can create it in the octavia-tempest-plugin's devstack plugin.sh file 16:15:56 No 16:16:10 it needs to be routable 16:16:26 It should be created in the tempest plugin setup so it is removed correctly and is present for runs outside of devstack. 16:16:35 can we create it right there in that code? just rip-out the private check? 16:17:04 it would go in here: 16:17:04 but we need to add a route from the tempest controller to the ipv6 subnet 16:17:06 #link https://github.com/openstack/octavia-tempest-plugin/blob/master/octavia_tempest_plugin/tests/test_base.py#L143 16:17:27 Yeah, that is going to be the tricky part really. 16:17:41 It may require a change in tempest proper 16:18:02 yes that's not easy 16:18:28 The question is really, should tempest be setting that IPv6 subnet to "shared" 16:18:55 johnsom: the name of the network is "private" 16:18:56 In that case the user would have access 16:19:11 Yeah, but private networks can be marked as "shared" too.... 16:19:57 yes, but I guess the intent is to have a non-shared private network :D 16:20:02 Is there a "public" ipv6 we should be using instead? 16:20:38 I vaguely remember there was a tempest bug that caused only that private network to be routable, so the tests failed when using public 16:20:45 there is a public ipv6 network 16:22:05 So, maybe give that a go and see if it works, if so, public is probably the right answer anyway. I think we use public for the IPv4 test VIPs 16:22:31 ok, I'm going to try the public network 16:22:37 anyways 16:22:46 there is an ipv6-public-subnet by default in devstack, but it's not directly viewable by a user 16:23:02 it will probably fix the tests in devstack, but octavia-tempest-plugin might start failing with other deployment tools 16:23:03 shared=False 16:24:02 i still don't understand why we can't just create a lb_member_vip_ipv6_subnet, someone will have to hit me with the clue bat 16:24:24 we already create an ipv4 one... 16:24:50 haleyb: we are sending requests to the VIP address from the devstack node, so the ipv6 address have to be routable 16:25:03 haleyb: it would require an explicity 'ip route add' call 16:25:07 explicit 16:25:29 oh, because the ipv4 one is for floating IPs? 16:25:42 yes, we have FIPs for ipv4 16:25:43 Our plugin should not be messing with the test host routes, that should be managed by tempest, etc. 16:27:12 * haleyb has smoke coming out his ears trying to think about an IPv6 fix 16:28:12 Well, if the public subnet doesn't work, maybe take the root of that issue to the qa team for ideas. 16:28:34 public is supposed to be reachable from the tempest tests 16:29:16 ok Guys, I will explore the many options we have listed here 16:29:20 thank you 16:29:30 +1 16:29:36 I'll probably ping haleyb ;-) 16:29:43 #topic Open Discussion 16:29:47 just don't ask for floating IPv6 :) 16:29:49 Any other topics today? 16:30:04 haleyb That is easy, it's a no-op. grin 16:30:07 nothing here 16:31:17 nothing from me 16:32:24 Ok then, thanks for joining and the conversation. Have a great week! 16:32:31 #endmeeting