20:03:16 <johnsom> #startmeeting Octavia
20:03:18 <openstack> Meeting started Wed Apr 10 20:03:16 2019 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:21 <openstack> The meeting name has been set to 'octavia'
20:03:36 <johnsom> Ugh, sorry folks.  Still getting back in the groove after travel.
20:04:18 <cgoncalves> hope you enjoyed it :)
20:04:21 <johnsom> #topic Announcements
20:04:39 <johnsom> Ha, well, yesterday was a long travel day.
20:05:19 <rm_work> o/
20:05:21 <johnsom> The biggest announcement I have today is:
20:05:25 <johnsom> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004899.html
20:05:30 <johnsom> Stein is released!
20:05:59 <rm_work> woo
20:06:11 <johnsom> lol, ok, that was a link to message, with a link to a message, with a link to the release.
20:06:14 <johnsom> #link https://releases.openstack.org/stein/
20:06:22 <cgoncalves> awesome! thanks to many of you for your code contributions, reviews and discussions!
20:06:51 <johnsom> Thank you to the whole team for your efforts on Octavia this cycle!
20:07:06 <johnsom> We got a lot of good work done.
20:07:14 <cgoncalves> the Octavia Stein release notes are impressive!
20:07:16 <cgoncalves> #link https://docs.openstack.org/releasenotes/octavia/stein.html
20:07:27 <johnsom> Yes!
20:07:37 <johnsom> You beat me to posting that link.
20:07:58 <nmagnezi> o/
20:08:26 <johnsom> There are also the cycle highlights for the press type people:
20:08:29 <johnsom> #link https://releases.openstack.org/stein/highlights.html
20:09:56 <johnsom> Again, thank you all for a successful release. Please raise yourself a toast!
20:10:53 <cgoncalves> https://www.benjerry.co.uk/files/live/sites/uk/files/whats-new/beer-blog.jpg
20:11:26 <johnsom> Are there any other announcements today?
20:12:15 <johnsom> Ok, just a heads up, the Summit is coming up in a few weeks.
20:12:59 <johnsom> Please remember to enter any topic ideas, etc. on the Octavia PTG etherpad:
20:13:02 <johnsom> #link https://etherpad.openstack.org/p/octavia-train-ptg
20:13:37 <johnsom> #topic Brief progress reports / bugs needing review
20:14:18 <cgoncalves> if someone cannot attend the PTG but would like to participate, please let us know. we may be able to setup a conference system
20:14:44 <johnsom> Other than traveling, I worked on cleaning up our "unset" story for the client and the API. I'm working through the API making sure that PUT calls with "None/null" are handled correctly and that we have openstack client "unset" actions available.
20:15:23 <johnsom> Yes, and please still add your topic to the list.  We can also do a coordinated IRC time if that works better for folks than attempting a video conference.
20:15:24 <nmagnezi> yeah, I had some question about one patch related to listener
20:16:20 <johnsom> I also spent some time last week working on a last minute critical bug for the release. My fix ifup patch introduced a bug that could cause the base port IP to not come up.
20:16:43 <johnsom> nmagnezi Do you want to chat about those in open discussion?
20:16:50 <nmagnezi> johnsom, sure
20:17:08 <johnsom> Cool.  Any other updates from folks?
20:17:35 <cgoncalves> progress report from my side is: active-standby tempest test is ready for reviews
20:17:42 <cgoncalves> #link https://review.openstack.org/#/c/637073/
20:17:47 <cgoncalves> as is the spare pool tempest test
20:17:51 <cgoncalves> #link https://review.openstack.org/#/c/634988/
20:18:18 <johnsom> Yay!  That Active/Standby likely would have caught the above mentioned bug.
20:18:32 <cgoncalves> I also did some important backports, namely one about performance contributed by eandersson
20:18:35 <cgoncalves> #link https://review.openstack.org/#/c/650304/
20:19:01 <eandersson> Awesome
20:19:08 <johnsom> Nice. I think you also have some stable releases up for review to get those out.
20:20:07 <johnsom> cgoncalves I know there was some talk while I was gone about a client release. Is that in progress or something I should look at?
20:20:20 <cgoncalves> yes
20:20:21 <cgoncalves> #link https://review.openstack.org/#/c/651475/
20:20:30 <cgoncalves> release Octavia Queens 2.0.5 and Rocky 3.0.3
20:20:51 <cgoncalves> johnsom, lxkong is work on the backport tomorrow his time
20:21:12 <johnsom> Ok, sounds good
20:21:22 <cgoncalves> (the "yes" was for the stable releases up for review comment)
20:22:31 <johnsom> I will also mention here, there are a number of tempest plugin patches still open for review. Some relating to flavors, etc.  It would be good to get some eyes on those so we have a stronger testing suite.
20:23:04 <cgoncalves> #link https://review.openstack.org/#/q/project:openstack/octavia-tempest-plugin+status:open
20:24:30 <johnsom> Any other updates before we move on?  (remember, this isn't just for the core team, it's a great time for anyone participating to share with the wider team)
20:24:51 <johnsom> For the week going forward,
20:25:25 <johnsom> I have some internal stuff to work on, then probably getting slides started for the Summit and continuing to work on the unset work.
20:25:34 <rm_work> i'm just looking forward to the PTG, so we can get some discussion in on priorities and roadmap for Train
20:25:41 <rm_work> and get started on the big rocks there
20:26:23 <johnsom> Yep!  Maybe in a week or so I will start working on a rough schedule for the topics.  That is unless rm_work wants to do it.
20:26:32 <rm_work> go ahead, sounds good :)
20:26:44 <cgoncalves> lol
20:26:52 * johnsom feels like the team all just took a step back
20:27:21 <cgoncalves> there is a patch up proposing a fix in our providers support
20:27:24 <cgoncalves> #link https://review.openstack.org/#/c/648853/
20:28:15 <johnsom> Yeah, I need to take a close look at that. We have a wrapper that should be handling any driver issue, so not sure how that would not have been handled.
20:28:22 <cgoncalves> the OVN team might have been hit by this issue a few weeks ago, too. they work-arounded it by creating the VIP port themselves
20:29:53 <johnsom> I will also note, the NSX driver in neutron had some release trouble because they were linking directly into Octavia and directly accessing the database. I hope the folks working on that will work with us to make sure they have what they need to be "good provider citizens" and this isn't an issue going forward.
20:30:21 <cgoncalves> +1
20:30:54 <cgoncalves> provider vendors out there listening: please reach out if you need advise/help!
20:31:11 <johnsom> It didn't look like it was any big design issue, just a few fields or new driver API methods needed.
20:31:41 <johnsom> #topic New IRC meeting time
20:32:13 <johnsom> Ok, so last week we started a doodle poll and sent e-mail to the discuss list about changing the Octavia IRC meeting time.
20:33:22 <johnsom> #link https://doodle.com/poll/9sxbzfhwirqiyqe8
20:33:32 <johnsom> That is/was the link to the doodle poll
20:33:34 <rm_work> personally i am kinda hoping it doesn't have to change :D
20:34:22 <johnsom> There was a four way tie, all of which were a new time.
20:35:18 <johnsom> The winning times were on Tuesday or Wednesday, 15:00 or 16:00 UTC.
20:35:45 <johnsom> We have a choice to make:
20:35:57 <johnsom> 1: we can do another poll, with only those time slots.
20:36:33 <johnsom> 2: We can pick the time slot based on the new PTL's choices, which would be 16:00 UTC.
20:37:24 <johnsom> Personally I think we should just use the 16:00 time slot and pick either Tuesday or Wednesday.
20:38:34 <johnsom> I would lean towards keeping it on Wednesday.
20:38:35 <cgoncalves> 16:00 UTC works for me. I'd say Wednesday to keep the same week day
20:39:30 <rm_work> Ok. Hopefully I make it to enough of those :D
20:39:50 <rm_work> is that... 9am PST?
20:39:59 <johnsom> Yes
20:41:02 <johnsom> Any comments/concerns with Wednesdays at 16:00 UTC?
20:41:32 <rm_work> johnsom: as our community manager, you're going to continue to run the meetings, right?
20:41:49 <nmagnezi> I preferred the current time. But if that works for everyone I guess that's okay
20:41:58 <rm_work> nmagnezi: did you do the poll? :D
20:42:04 <johnsom> rm_work Ummm, technically that is a PTL activity.....
20:42:04 <nmagnezi> rm_work, I did
20:42:10 <rm_work> then apparently yes
20:42:43 <rm_work> johnsom: does it say that somewhere? ;)
20:43:08 <johnsom> rm_work I have a few weeks to *make* it say so if I need....  grin
20:43:18 <johnsom> Seriously though, you can delegate that out
20:43:23 <rm_work> lol
20:44:53 <johnsom> Ok, so are we good that I should do all the paperwork type stuff to move the time to 16:00 UTC?
20:45:01 <johnsom> Going once....
20:45:17 <johnsom> going twice....
20:45:51 <johnsom> Sold! Our new IRC meeting time will be Wednesdays at 16:00 UTC (four hours earlier than our previous time).
20:46:16 * rm_work dies
20:47:19 * cgoncalves updates his calendar
20:47:54 <johnsom> I will update the OpenStack meetings page, our wiki, and send out an e-mail.
20:48:39 <johnsom> FYI, I have also opened it so you can see how folks voted now that the poll is done.
20:49:15 * nmagnezi looks
20:49:24 <johnsom> #topic Open Discussion
20:49:43 <nmagnezi> cgoncalves, you really wanted to change the time. lol
20:50:08 <cgoncalves> nmagnezi, as you can see, I was open to any time slot proposal!
20:51:32 <johnsom> nmagnezi I think you had some questions about the listener unset patch?
20:51:38 <nmagnezi> johnsom, yes
20:52:02 <nmagnezi> johnsom, wrote it as a comment https://review.openstack.org/#/c/650153/
20:52:30 <nmagnezi> just wondering why we reset to default and if we should actually do that, that's all
20:52:47 <johnsom> Yeah, sorry, I have been traveling and haven't caught up yet.
20:52:55 <nmagnezi> np
20:53:25 <nmagnezi> Just asking because another way to look at it, is as some invalid input that you ignore
20:53:50 <nmagnezi> So as I wrote, the patch itself is fine code-wise. Just wondered about the outcome
20:54:22 <johnsom> Well, the values that I reset to the default are values that don't make sense with "None" in them.  Like a timeout value, you can't really have a None timeout, we have a defined range for those. So I felt an "unset" of a timeout would translate back to the default we have set for those.  However, very  open for discussion on it.
20:55:22 <nmagnezi> Fully agree. But aren't this just for updates?
20:55:53 <nmagnezi> I mean, if you create a new listener and provided nulls I agree that defaults make sense
20:56:25 <johnsom> Ah, ok, so your question is how do they *not* set a currently set field?  I.e. Timeout A is set to 11, where the default is 10 (yes, yes, select numbers chosen).
20:57:12 <johnsom> So with the PUT API, to *not* update a field, you just don't include that parameter in the JSON document.  This is how it works today.
20:57:56 <nmagnezi> Aha, okay probably I got it wrong by looking at the "Fix listener API handling of None/null updates" topic (no need to change it)
20:58:09 <johnsom> If you want to update the "name" but not the "timeout A", you would PUT a json with just 'name': 'great' in it and not include the "timeout A" field at all.
20:58:12 <nmagnezi> I thought this is for updates
20:58:27 <johnsom> Yes, this is for updates.
20:59:03 <cgoncalves> yeah, set/unset are PUT API requests
20:59:21 <johnsom> With this patch, if you do include "timeout A" field, with "null" in it, it will now reset to the default value for that field.
20:59:51 <johnsom> (FYI, null is JSON for None in python in this case)
21:00:24 <johnsom> Ok, we are out of time because I was late, sorry.  We can continue chatting in the channel.
21:00:27 <johnsom> #endmeeting