16:02:54 #startmeeting Octavia 16:02:55 Meeting started Wed Oct 16 16:02:54 2019 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:03:00 The meeting name has been set to 'octavia' 16:03:12 Hi folks, sorry for the delay.... 16:03:15 hello octavians 16:03:21 hi 16:03:25 Hi 16:03:27 hi 16:03:34 hi 16:03:38 cgoncalves Thanks for the poke. 16:03:48 #topic Announcements 16:03:56 Train released today! 16:04:04 #link https://releases.openstack.org/train/highlights.html 16:04:31 Thank you to everyone for your contributions. Code, reviews, otherwise! 16:05:44 In our patch review push we merged 106 patches. 16:06:11 Congrats!! 16:06:51 many more patches were merged. those 106 patches were the ones we at some point prioritized :) 16:07:26 Right, absolutely correct. There was more than just the 106, but the 106 was our priority list. 16:07:41 johnsom: congrats! how did you calculate it? just from my curiosity. 16:08:10 amotoki We created a "priority review list" around MS2: 16:08:12 #link https://etherpad.openstack.org/p/octavia-priority-reviews 16:08:30 wow! 16:08:50 It helps us stay on top of patch dependency ordering and priority for the release. 16:08:53 Ann Taraday proposed openstack/octavia master: Convert Lb flows to use provider dicts https://review.opendev.org/671725 16:09:21 cool 16:09:44 Looking forward, the PTG is coming up in a few weeks. 16:09:55 We have an etherpad up to gather topics: 16:10:03 #link https://etherpad.openstack.org/p/octavia-shanghai-U-ptg 16:10:11 $ git rev-list --count 4.0.0..5.0.0 -> 258 patches merged between Stein GA and Train GA 16:10:26 Nice. 16:10:36 We are a small team, but we can get stuff done. lol 16:11:12 Please add any topics to the list that you think the team should discuss at the PTG. 16:11:32 There will be three Octavia cores attending, so a good quorum. 16:12:26 If you are interested in other project team etherpads for the PTG, the list is being managed here: 16:12:28 #link http://ptg.openstack.org/etherpads.html 16:13:14 Octavia is booked to have a room/table for two and a half days. 16:13:35 (it sounds like there may not be rooms at this PTG) 16:14:22 Any other announcements today? 16:15:30 #topic Brief progress reports / bugs needing review 16:16:32 I have been working on a bug around barbican outages/secrets being deleted. I have a patch up for review on that. There is one more part of the bug I'm trying to reproduce. I should have that wrapped up today/tomorrow-ish. 16:17:04 I created this #link https://storyboard.openstack.org/#!/story/2006627 some time ago, and pushed one patch, look forward some thoughts on this 16:17:05 I also took a mental break and put up some docs patches updating the cookbook for some of the new TLS capabilities we added. 16:17:23 I had the devstack already setup for barbican, so it seemed like a good time to check those off the list. 16:18:11 Jobboard is in progress, convert patches are ready, working on the main change #link https://review.opendev.org/#/c/647406/ 16:18:21 ataraday_, thanks for working on that! I have a question/ask for feedback if that is okay 16:18:37 ataraday_ Ah, yes! Adding ciphers and protocols was on my short-term wish list. I will take a look and give feedback. I have put some thought into this as well. 16:18:56 should it be set in the configuration file or made available to LB owners via API? 16:19:15 I assumed we were adding it to the listener API 16:20:04 I proposed adding default cipher setting via config, and one change will add setting specific cipher on each listener 16:20:24 via listener API 16:20:51 Ok, so a default in config and then optional listener API setting. Yeah, that aligns to my idea as well. 16:21:33 what if the admin wants to limit ciphers? e.g. not permit SSL v1 and v2? 16:22:07 I also think our default should follow: 16:22:09 #link https://cheatsheetseries.owasp.org/cheatsheets/TLS_Cipher_String_Cheat_Sheet.html 16:23:00 I was leaning towards suite B 16:23:35 Yeah, it probably is valid to have a way for an operator to set a required "minimum" protocol level. Maybe even a blacklist for ciphers 16:23:43 agreed 16:24:29 via API or via config? 16:24:43 Those are all separate requests/patches however. They don't all need to be in this initial patch. 16:25:09 I think the minimum and blacklist would be config file settings that the API input is validated against. 16:25:13 for our use cases a minimum protocol level would satisfy most concerns, fwiw 16:25:48 sounds good! 16:26:09 nice, we are all in agreement \o/ 16:26:57 ataraday_ If you don't mind, after the meeting I can capture my thoughts in the storyboard story. 16:27:10 We can break it down into different tasks 16:27:49 johnsom, It is highly appreciated! 16:27:56 Cool. 16:27:57 thanks! 16:28:25 After I wrap up this barbican story, I'm back to working on the failover flow I started before my vacation. 16:28:32 Still a lot of work to do there. 16:28:36 nothing to report from my side. reviewing patches and working on tripleo 16:30:18 Any other updates? If not I will move on to open discussion 16:30:26 mostly sharing for visibility but did open this and may take a stab at an implementation for you folks to review if i can get it working https://storyboard.openstack.org/#!/story/2006653 16:31:15 colin- Cool, thanks for working on that. Let us know if we can answer questions, etc.... 16:31:23 nice! 16:31:58 appreciate it, the links to the existing bodies of work where other timeouts were implented was super helpful 16:32:33 #topic Open Discussion 16:32:56 One thing I would like us to start thinking about is how we currently handle TLS offload listeners. 16:33:40 The existing implementation is protocol "TERMINATED_HTTPS" 16:33:59 However, we can support other protocols wrapped in TLS. 16:34:39 I have been thinking about should we add a "tls_enabled" boolean and move away from long lists of protocols, or just add more "TERMINATED_*" protocols. 16:35:09 Not something I can work on any time soon, but something to think about for a future discussion. 16:35:40 For example, we could support "TERMINATED_TLS_TCP" now if we added it.... 16:36:13 Anyway, any other topics for today? 16:36:17 fair point, not sure which i prefer but certainly worth noodling on 16:36:30 i do kind of like the idea of a boolean 16:36:50 what would be the benefit of adding a boolean? protocols would still need to be added to the list 16:37:09 abstracting that characteristic away from the listener protocol i guess 16:37:35 True, but we wouldn't be adding two for each. I.e. SMTP and TERMINATED_TLS_SMTP (bogus example, but...) 16:37:51 so then an HTTPS type listener would either terminate or pass-through their HTTPS traffic based on that, if i am conceptualizing it correctly 16:38:29 Right, we would need to come up with a "how to do the right thing with the legacy protocol list" 16:38:47 would users be allowed to update "tls_enabled"? I think there would be some amount of implications we would need to take care of in the server side 16:39:13 hm yeah that would be difficult to make mutable 16:39:24 right now to be it seems easier to both users and devs to keep adding TERMINATED_* protocols to the list 16:39:33 I think it could be possible to update to a tls_enabled state. As long as the validation passes, i.e. certs exist, etc. 16:40:37 mutating that boolean flag would incur anyway in short downtime and breakage of open connections, no? 16:41:05 Yeah, changing protocols underneath a connection is going to break it. for sure.... 16:42:33 right. so I am not certain of the value it would bring. I'd need to understand this better, I guess 16:43:56 I just wanted to raise the discussion. Like I said, not on my short term roadmap at the moment 16:44:25 yeah it's a good thing to start considering 16:45:09 Any other topics today? 16:46:53 Ok then, thank you! Nice work on Train. We did some great work there. 16:47:02 Merged openstack/octavia master: Add client authentication to the LB cookbook https://review.opendev.org/688776 16:47:06 #endmeeting