20:00:07 #startmeeting Octavia 20:00:08 Meeting started Wed May 30 20:00:07 2018 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:11 The meeting name has been set to 'octavia' 20:00:19 Hi folks 20:00:50 Pretty light agenda today 20:01:00 hi 20:01:19 o/ 20:01:26 #topic Announcements 20:02:00 I don't have much for announcements. The summit was last week. There are lots of good sessions up for viewing on the openstack site. 20:02:31 Octavia was demoed and called out in a Keynote, so yay for that! 20:02:48 :-) 20:02:58 We also came up in a number of sessions I attended, so some good buzz 20:03:16 Nir, I think you have an announcement today.... 20:03:22 :) 20:03:32 I'm happy to announce that TripleO now fully supports Octavia as a One click install. 20:03:39 That includes: 20:03:44 1. Octavia services in Docker containers. 20:03:50 2. Creation of the mgmt subnet for amphorae 20:04:00 3. If the user is using RHEL/CentOS based amphora - it will automatically pull an image and load it to glance. 20:04:15 Additionally, the SELinux policies for the amphora image are now ready and tested internally. Those policies are available as a part of openstack-selinux package. 20:04:26 some pointers (partial list): 20:04:38 1. I'll find the related tripleO docs and provide it next week (what we do currently have is release notes ready for Rocky 20:04:47 2. SELinux: 20:04:53 #link https://github.com/redhat-openstack/openstack-selinux/blob/master/os-octavia.te 20:05:11 o/ 20:05:25 Many people were involved with this effort ( cgoncalves amuller myself bcafarel and more) . And now we can fully support Octavia as an OSP13 component (Based on Queens). 20:05:41 Ok, cool! So glad to see SELinux enabled for the amps 20:05:59 +1 20:06:17 +1000 There are people looking for it. I also mentioned OSP 13 a number of times at the summit 20:06:24 I do expect this to drive up Octavia adoption pretty significantly 20:06:40 :-) 20:07:15 yup. I'm sure operators that are still using the legacy n-lbaas with haproxy will migrate 20:07:15 it takes less than 2 people to deploy octavia with tripleo now 20:07:16 Way to go RH/TripleO folks. I know it's been a journey, but it is great to have the capability. 20:07:53 2 people? I thought it was one-click? One to click the mouse and one to open the beverages? 20:08:20 grin 20:08:32 haha 20:08:40 johnsom, I said "less than" ;) one is enough to do both jobs :) 20:08:49 Nice. Any other announcements today? 20:09:41 #topic Brief progress reports / bugs needing review 20:10:05 I was obviously a bit distracted with the summit and presentation prep. 20:10:39 yup :) 20:10:48 We have started merging the provider driver code and the tempest plugin code. We are co-testing the patches as we go. 20:11:08 o/ 20:11:25 rm_work Did point out a race condition in my amp driver last night, so he is working on fixing that. 20:12:08 It's kind of a migration issue, as I wanted to incrementally migrate the amphora driver over to the new provider driver ways. 20:12:32 Today my focus is on adding the driver library support (update stats/status). 20:12:58 I have been chatting with Kobi in the mornings about the VMWare NSX driver, which it sounds like is in-progress. 20:13:22 Nice! 20:13:29 He has been giving feedback that I have been including in the cleanup patch. 20:14:27 Along the lines of drivers, it's not clear when we will get an F5 driver. They have had some re-orgs from what I gather, so it may delay that work. 20:15:07 good to know. at least we have feedback from one vendor for now. 20:15:42 Yeah, sad that the vendor that was the key author of the spec may not be able to create their driver right away 20:15:47 Adam Harwell proposed openstack/octavia master: Allow DB retries on controller_worker creates https://review.openstack.org/571107 20:16:43 Any other progress updates today? 20:17:17 yes 20:17:24 I had some cycles, so I finished my Rally patch to add support for Octavia. it is ready for feedback now and worked okay for me: https://review.openstack.org/#/c/554228/ 20:17:46 In case you are really bored, here is the link to my project update. Feedback welcome. 20:17:48 #link https://youtu.be/woPaywKYljE 20:18:08 johnsom, i watched it. you did a great work with this. 20:18:58 Thanks 20:19:22 Rally, cool. I need to look at that and refresh my memory of how those gates work 20:19:25 #link https://review.openstack.org/#/c/554228/ 20:19:51 johnsom, yeah. the scenario i add now is a port of the existing n-lbass scenario to Octavia 20:19:59 I'm guessing it is the "rally-task-load-balancing" gate I should look at? 20:20:00 next up we can add more stuff 20:20:25 johnsom, yup 20:20:36 Cool, I will check it out 20:21:07 thanks! 20:21:30 Any other updates? 20:22:02 cgoncalves I saw the grenade gate was failing, but didn't have much time to dig into why. Are you looking into that? 20:22:43 johnsom, I submitted new patch set today (yesterday?) to check what's going on when we curl. it fails post-upgrade 20:23:01 Yeah, odd 20:23:15 not sure why yet. it successfully passes the same curl pre and during upgrade 20:23:34 it started failing out of the sudden 20:24:13 Well, let us know if we can provide a second set of eyes to look into it. 20:24:22 I really want to get that merged and voting. 20:24:27 thanks! 20:24:35 So we can start the climb on upgrade tags 20:24:47 Also, we discussed fast-forward upgrades a bit at the summit. 20:24:47 yes! 20:25:39 I'm thinking we need to setup grenade starting with Pike (1.0 release) and have gates for Pike->Queens, Queens->Rocky, etc. to prove we can do a fast-forward upgrade 20:26:28 I guess I am jumping ahead... grin 20:26:38 #topic Open Discussion 20:28:22 fast-forward is running each upgrade sequentially to move from an older release to current. This is different from leap-frog which is a direct jump Pike->Rocky. It sounds like fast-forward is going to be the supported plan for OpenStack upgrades 20:29:10 fast forward sounds like... a normal upgrade process 20:29:25 Right, just chained together 20:29:32 and... fast :) 20:29:43 unless they add stuff like "you don't have to start/stop the control plane at each stage" 20:29:44 Eh, as long as we have a plan and a test I will be happy. 20:29:48 but yeah 20:30:20 I think it's the script of what is required to do that. 20:30:28 Other topics today? 20:30:34 IIUC, we could try that now in the grenade patch by changing the base version from queens to pike: https://review.openstack.org/#/c/549654/33/devstack/upgrade/settings@4 20:31:30 cgoncalves that would be a leap frog thought right? 20:31:43 if there are upgrade issues (e.g. deprecated configs), we create a per version directory with upgrade instructions 20:32:05 johnsom, ah right 20:32:45 yeah, we need to write up an upgrade doc that lays out the steps. Maybe from their link to any upgrade issues or just link to the release notes 20:33:44 * johnsom notices the room going quiet.... 20:33:50 lol 20:34:18 everyone like docs.. 20:34:20 :) 20:34:42 In fairness, I think we can just pull the grenade back to the Queens branch and set it up. This would give us the FFU gates we need. 20:34:53 Once we get it stable on master 20:35:19 +1 20:36:27 yup. sounds right 20:38:00 Ok, if there aren't any more topics, have a good week and we will chat next Wednesday! 20:38:02 something is nagging at me about that... but sure, probably 20:38:26 o/ REVIEW STUFF 20:38:52 Yes, please. I really hope to do a client release soon 20:39:03 Would love to get some reviews on that 20:40:00 #endmeeting