16:00:17 <rm_work> #startmeeting Octavia
16:00:18 <openstack> Meeting started Wed May 15 16:00:17 2019 UTC and is due to finish in 60 minutes.  The chair is rm_work. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:21 <openstack> The meeting name has been set to 'octavia'
16:00:26 <johnsom> o/
16:00:32 <rm_work> o/
16:00:40 <ataraday_> hi
16:00:45 <cgoncalves> o/
16:01:03 <rm_work> #topic Announcements
16:01:03 <openstackgerrit> Ann Taraday proposed openstack/octavia master: [WIP] Jobboard based controller  https://review.opendev.org/647406
16:01:07 <colin-> o/
16:01:20 <rm_work> Neutron LBaaS is dead! Long live Octavia LBaaS!
16:01:30 <johnsom> Wahoo!
16:01:48 <cgoncalves> RIP
16:01:51 <rm_work> As a result, Octavia's v1 API is also sleeping with the fishes.
16:02:54 <rm_work> There are still some remnants sitting around, so if you see them, please throw up a quick patch to remove them. I see there was some tempest stuff I missed, for example, so thanks to Adit for proposing a patch for that.
16:03:06 <johnsom> The big bit bucket in the sky...
16:04:03 <rm_work> That's really all I had, anyone else have any announcements?
16:04:52 <rm_work> #item RIP Neutron-LbaaS
16:05:00 <rm_work> I wonder if that works...
16:05:22 <johnsom> So I noticed you were keeping the stable branches. I think we should talk about that
16:05:31 <rm_work> I thought we did talk about that?
16:05:55 <rm_work> That was the decision I remember from our previous discussions... But, we can totally discuss it again.
16:06:11 <rm_work> Any other announcements? If not, we can move to that as an agenda item
16:06:18 <johnsom> We probably did. I'm just not 100% sure the reason we want to stay on the hook for those
16:06:25 <johnsom> I don't have anything
16:06:54 <rm_work> ok
16:07:16 <rm_work> #topic Neutron-LBaaS stable branches
16:07:27 <rm_work> So, you feel like we should kill those too?
16:07:48 <cgoncalves> Andreas Jaeger was also asking if we could keep stable branches, right?
16:08:08 <cgoncalves> I think we should keep them. why not
16:08:38 <rm_work> I think we'd end up with a LOT more pushback if we killed the stable branches as well... They were released, and would still be in support for two cycles or whatever, so I don't think we can just wipe those blindly (as much as it'd be nice to)
16:08:44 <johnsom> Well, it means we have to babysit them.
16:09:06 <rm_work> Plus, it has allowed me to somewhat assuage people's concerns by pointing to those branches to do builds if they need to
16:09:08 <johnsom> The point of the two cycle deprecation was to give warning, etc.
16:09:25 <rm_work> Yes, but they were official releases, and releases have a maintenance cycle....
16:10:00 <johnsom> So you are arguing to wait until they go to "Unmaintained" status in releases?
16:10:04 <nmagnezi> o/ (sorry to be late)
16:10:08 <cgoncalves> can't we just consider branches immutable/archived from now on?
16:10:22 <rm_work> Yes
16:10:29 <rm_work> (to johnsom)
16:10:41 <colin-> makes sense to me, fwiw
16:10:59 <rm_work> cgoncalves: What I mentioned on the ML was that we would not be doing anything with them unless it was absolutely critical (security patches, etc)
16:11:01 <colin-> (re: unmaintained status)
16:11:10 <johnsom> Right immutable is what I am advocating for
16:11:34 <johnsom> Immutable means we don't have to keep the gates running, etc.
16:12:13 <cgoncalves> rm_work, +1. queens to stein are deprecated releases. ideally we should even be up to bug fixing until series go EOL
16:12:18 <rm_work> It's all there... we may as well just leave it IMO
16:12:57 <cgoncalves> but a compromise could be considering them immutable, i.e. do not delete code in stable branches but stop accepting patches (+ no CI)
16:13:04 <rm_work> hmmm
16:13:12 <rm_work> I just don't see a reason to kill it
16:13:37 <cgoncalves> removing code from branches could break CI/CD or whatever other tools people use to pull code
16:13:52 <johnsom> Ok.
16:14:01 <johnsom> BTW, photos:
16:14:08 <johnsom> #link https://www.dropbox.com/sh/fydqjehy9h5y728/AABlCCHedQlB3lgqpLl5PXIKa/Octavia?dl=0&subfolder_nav_tracking=1
16:15:00 <cgoncalves> beautiful!
16:16:23 <johnsom> Darn, should have read my e-mail.  Also, the Shanghai call for presentations is open:
16:16:25 <johnsom> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006262.html
16:17:27 <colin-> i swear i was smiling
16:17:43 <rm_work> the good photo of me is when colin- has his eyes closed... >_>
16:18:04 <colin-> haha, perfect
16:21:24 <rm_work> Ok
16:21:53 <rm_work> I don't think there was anything else on the agenda officially?
16:22:13 <rm_work> Oh, we skipped this:
16:22:17 <rm_work> #topic Brief progress reports / bugs needing review
16:22:32 <rm_work> lots of good stuff showing up now that people are settling in after the PTG :)
16:22:38 <johnsom> I don't see an agenda...  https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda
16:22:56 <rm_work> me either :D
16:23:05 <rm_work> is that something I'm supposed to be maintaining? ;)
16:23:32 <johnsom> I have resumed work on fixing the None/null update APIs.  I'm through "pools" now. I will continue to work through those this week.
16:24:29 <johnsom> I saw a patch about unsetting the admin_state_up. In general I have not been including boolean settings in the "unset" work.
16:25:33 <cgoncalves> I also resume work on VIP ACL (started in Oct-Nov last year and had been on hold ever since). My Python 3.7 patch was rebased to exclude API v1 stuff, and addressed comments in the spare pool tempest patch
16:26:02 <ataraday_> I switched PoC to use redis.. and discover that it is not working as good as  with zookeper :( Spend some hours debuging - I will do some workarounds to make this work
16:26:20 <ataraday_> about jobboard taskflow stuff ^^
16:26:47 <rm_work> johnsom: i kinda agree, it's up or down....
16:26:56 <johnsom> ataraday_ Ah, that is a bummer. Thanks for the work on that!
16:27:02 <cgoncalves> ataraday_, what's not working as good as zookeeper? performance or some compatibility?
16:27:12 <rm_work> i wonder if that warrants revisiting that discussion
16:27:28 <johnsom> rm_work I guess 500 isn't good either. Maybe we still have some tests to add in addition to what I have been looking at.
16:27:30 <ataraday_> I just don't resume jobs on restart :)
16:27:35 <rm_work> we assumed the choice was not going to affect the usage, I think
16:27:46 <ataraday_> by default
16:28:03 <cgoncalves> ok. yeah, thank you a lot for working on jobboard support!
16:29:53 <ataraday_> it (redis) just don't resume jobs, yes, I was expecting it will work as zookeper, but there are some logic with claiming jobs there
16:32:03 <rm_work> ok, so do we want to follow up with that in...
16:32:07 <rm_work> #topic Open Discussion
16:32:15 <rm_work> or is that it?
16:33:33 <ataraday_> not sure I have a lot to discuss, I hope to make it work this week
16:33:44 <ataraday_> and than dig into refactor
16:34:08 <johnsom> I think the intent was to not block the development work. If you got Redis working, great. If not, maybe we just use zookeeper for now and re-address when it comes time to consider etcd, etc.
16:34:36 <johnsom> I would leave the decision to ataraday_ on the value trade off
16:34:59 <rm_work> same
16:35:45 <ataraday_> OK
16:35:53 <johnsom> I know we talked about the plans to use Redis for health manager and that some folks have Redis in their clouds already, but I don't want to slow down progress either.
16:36:40 <cgoncalves> +1
16:37:05 <colin-> will this become the default implementation?
16:38:09 <ataraday_> We wanted redis to be default - in ideal world it sould not matter what backend to use
16:38:17 <johnsom> Agreed
16:38:34 <colin-> sorry, i should have been more specific. i was referring to the jobboard body of work
16:38:54 <colin-> my question is if it is merged will it become the default deployment mondel, requiring all users to deploy a zk/redis cluster in support of octavia or not
16:39:04 <rm_work> ah, not sure actually
16:39:13 <colin-> np, early days still
16:39:20 <johnsom> It is being developed as an alternate controller driver, but I expect many will want to run it
16:39:20 <ataraday_> not it will be experimental for the begining
16:39:28 <colin-> ok
16:39:52 <rm_work> it requires more setup, so probably not? since we want to stay as simple as possible (we're already pretty complex to deploy)
16:40:09 <johnsom> We also would like to see jobboard support etcd which is an OpenStack "base service", but that is also additional work.
16:40:19 <cgoncalves> right. we discussed that at the PTG. at the time the agreement was to make it experimental and thus an offer as alternative to existing model
16:40:35 <colin-> thanks for the reminder ;)
16:42:27 <ataraday_> johnsom, you said on last meeting you will do one of refactoring change as an example - will you have time for this?
16:43:10 <johnsom> ataraday_ Ah, yes, sorry, it dropped off my radar. I will work on that this week as to not block work for others.
16:44:09 <ataraday_> johnsom, great, thanks!
16:48:31 <rm_work> cool, ok
16:48:39 <rm_work> Seems like maybe we're done?
16:48:56 <rm_work> and I can go back to sleep \o/
16:49:15 <johnsom> I don't have anything else
16:49:22 <colin-> that's all for me
16:49:34 <rm_work> Alright, thanks for coming!
16:49:36 <rm_work> #endmeeting