20:00:07 <johnsom> #startmeeting Octavia
20:00:08 <openstack> Meeting started Wed Mar  2 20:00:07 2016 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:10 <madhu_ak> hi
20:00:11 <openstack> The meeting name has been set to 'octavia'
20:00:16 <xgerman> o/
20:00:17 <johnsom> Hi folks
20:00:24 <pothole> 0/
20:00:30 <ajmiller> o/
20:00:35 <sbalukoff> Greetings, y'all!
20:00:51 <markvan> o/
20:00:52 <mhayden> howdy
20:00:56 <johnsom> #topic Announcements
20:01:08 <johnsom> M3 - feature freeze has come and gone
20:01:17 <TrevorV> o/
20:01:21 <johnsom> We got a bunch of stuff in, so good job everyone
20:01:48 <johnsom> Any other announcements folks have?
20:01:48 <xgerman> I think it’s still not frozen?
20:01:50 <blogan> hi
20:02:10 <johnsom> It's frozen.  All feature patches have received -2 already
20:02:11 <dougwig> please ping me if you need an FFE, but if it's not in gerrit and in reasonable shape, it's likely newton bound.
20:02:13 <pothole> We imposed our own freeze
20:02:47 <johnsom> #link http://releases.openstack.org/mitaka/schedule.html
20:02:58 <TrevorV> dougwig I should consider single-create in neutron "newton-bound" right?
20:03:01 <sbalukoff> Yeah-- I think we were just sticking to the schedule
20:03:06 <TrevorV> neutron lbaas***
20:03:16 <johnsom> RC1 is targeted for March 14th
20:03:31 <dougwig> is it feature complete and just needs final tweaks, or is it a wip?  if the latter, yep, newton.
20:04:12 <johnsom> Well, neutron-lbaas is on the neutron schedule and since Octavia is the reference implementation we need to follow closely too
20:04:43 <johnsom> So, we really want to get our bugs fixed by RC1 March 14th
20:05:08 <johnsom> #topic
20:05:08 <johnsom> Mitaka blueprints/rfes/m-3 bugs for neutron-lbaas and octavia
20:05:18 <johnsom> Speaking of bugs:
20:05:20 <johnsom> #link https://bugs.launchpad.net/octavia/+bugs?field.tag=target-mitaka
20:05:21 <sbalukoff> Heh!
20:05:23 <sbalukoff> Nice!
20:06:05 <dougwig> johnsom: i've got something here today
20:06:08 <johnsom> These are the bugs I think we should have fixed for Mitaka.  This includes bugs opened for minor issues (missing unit tests) in recent patches
20:06:10 <sbalukoff> I think my two session_persistence bugs last night will go a long way to fixing the intermittent session_persistence scenario test failure....
20:06:11 <sbalukoff> But...
20:06:25 <sbalukoff> I guess those are all broken now after the glace image ID patch merged?
20:06:30 <johnsom> sbalukoff Excellent
20:06:57 <johnsom> sbalukoff Ping me the details on those after the meeting.
20:07:01 <sbalukoff> I have something to discuss regarding those patches as well, but that can wait until open discussion.
20:07:09 <sbalukoff> johnsom: Will do!
20:07:26 <johnsom> So, if you guys have spare cycles, please grab a bug.
20:07:41 <johnsom> dougwig - Floor is yours
20:07:43 <sbalukoff> And hopefully the critical / major bugs first!
20:07:44 <dougwig> #link https://review.openstack.org/#/c/286413/
20:08:05 <dougwig> armax put up that review for status and ffe's, and it has some lbaas items. please update your stuff there, or send me the info.
20:08:20 <dougwig> i'll hunt folks down that haven't answered later today.  so go post a review on there.  :)
20:08:44 <dougwig> johnsom: done
20:08:55 <johnsom> Thanks for the heads up.
20:09:12 <johnsom> Any other bug related items?
20:09:43 <johnsom> I have gone through and closed out bugs that were fixed before the "Fix Release" change.  You may have seen updates on old bugs.
20:10:13 <johnsom> #topic
20:10:13 <johnsom> DELETION CATHARSIS (dougwig)
20:10:17 <sbalukoff> Haha!
20:10:21 <dougwig> let's start with v1.
20:10:27 <dougwig> #link https://wiki.openstack.org/wiki/ReleaseNotes/Liberty
20:10:29 <johnsom> Opps,
20:10:30 <sbalukoff> Burn it with fire.
20:10:32 <dougwig> deprecated here.
20:10:36 <johnsom> #topic DELETION CATHARSIS
20:10:48 <blogan> byebye
20:10:55 <dougwig> i think this should merge as soon as newton opens: https://review.openstack.org/#/c/286381/
20:11:05 <sbalukoff> +1
20:11:18 <johnsom> +1
20:11:23 * mhayden likes the idea
20:11:28 <xgerman> +1
20:11:34 <blogan> dougwig: will the jobs need to be removed first?
20:11:43 <dougwig> i think this one is fairly straight-forward execution of the deprecation policy.
20:11:45 <dougwig> blogan: yes.
20:12:21 <sbalukoff> Just as soooon as Newton opens...
20:12:23 <johnsom> dougwig Do you want to have a vote?
20:12:25 <dougwig> xgerman: did hp by any chance make their v1/v2 migration script public?  that's the only real missing piece, though i don't think it stops the removal.
20:12:31 <sbalukoff> Like, within minutes.
20:12:32 <xgerman> no
20:12:40 <dougwig> johnsom: i don't think this one is controversial.
20:12:55 * johnsom grins at asking dougwig for a vote
20:12:58 * dougwig waits for a sec for screaming.
20:13:18 <blogan> #startvote
20:13:20 <openstack> Only the meeting chair may start a vote.
20:13:25 <sbalukoff> Haha
20:13:30 <dougwig> ok, then let's move on to the v2 agent driver.
20:13:33 * johnsom slaps blogan on the wrist
20:13:43 <dougwig> as you can see here:
20:13:44 <dougwig> #link https://review.openstack.org/#/c/286332/
20:13:46 <dougwig> it's rotted.
20:13:52 <dougwig> look at the namespace-nv job
20:14:05 <xgerman> HP will fix it
20:14:06 <blogan> first, does anyone know of people running lbaas v1 agent?
20:14:11 <dougwig> so i'm thinking this should also go in as soon as newton opens:
20:14:13 <dougwig> #link https://review.openstack.org/#/c/286380/
20:14:30 <dougwig> and hp has volunteered to fix the rot for M.
20:14:41 <xgerman> volunteered is  a strong word
20:14:55 <blogan> voluntold is weaker?
20:14:58 <johnsom> Yeah, falls under voluntold
20:15:02 <xgerman> +1
20:15:37 <dougwig> i'm not hearing any screaming here either.  i expected a little bikeshedding, and y'all are letting me down.  i had popcorn ready and everything.
20:15:49 <sbalukoff> Woo-hoo!
20:16:16 <sbalukoff> dougwig: Reduce that amount of crufty, mostly redundant code we have to maintain? Geez, twist our arms!
20:16:22 <johnsom> Just to be clear, that would mean octavia and the vendor drivers are the only options for v2
20:16:24 <johnsom> right?
20:16:33 <dougwig> and the logging-noop driver.
20:16:39 <sbalukoff> johnsom: That is my understanding.
20:16:41 <xgerman> well, there always was blogan who wanted to retain the agent driver
20:16:43 <johnsom> Yeah, well
20:16:54 <blogan> so my argument against removing the v2 agent is it makes anyone running the v1 agent's upgrade path a lot harder
20:17:05 <blogan> v1 agent to v2 agent is much easier than v1 agent to v2 octavia
20:17:20 <sbalukoff> blogan: You think we should wait another cycle?
20:17:21 <dougwig> don't you have to script an object transfer, which makes which driver irrelevant?
20:17:29 <blogan> BUT, if no one knows of anyone who is actually using v1 agent in production, i dont care
20:17:29 <johnsom> This one seems like a bigger deal for folks, as I suspect anyone with LBaaSv2 is running that driver
20:17:32 <xgerman> well, another option is to put it into it’s own repo and make it apply for OpenStack open tent?
20:17:49 <blogan> sbalukoff: i think it would be nice to send out a thread in the ML and wait a bit to see if anyone bites and/or complains
20:17:52 <dougwig> or another repo and don't apply for the tent.
20:18:05 <xgerman> like a vendor driver
20:18:13 <blogan> dougwig: well with octavia you also need to have a bit mroe infrastructure for the VMs it'll spin up, so its still a bit more planning
20:18:19 <johnsom> I agree, we should advertise this one on the ML
20:18:20 <blogan> whereas with v1 you'd just reuse all that
20:18:46 <dougwig> ok, i'll post this one on the ML (and cross-post on ops)
20:18:51 <xgerman> k
20:19:06 <johnsom> Excellent, thanks dougwig
20:19:07 <sbalukoff> *shrug* fine by me. But it's not the reference, so in your ML thread make sure that you make it clear that anyone who wants to keep it is signing up to maintain it.
20:19:15 <dougwig> i'm pretty firmly in the delete or separate-repo camp, myself.  i'm not opposed to it sticking around, but i don't want to maintain it.
20:19:20 <johnsom> In the mean time, people can vote on the patch itself
20:19:29 <sbalukoff> dougwig: +1
20:19:40 <johnsom> dougwig +1
20:19:43 <xgerman> dougwig +1
20:20:25 <dougwig> ok, i think we have enough of a plan that we can move on.
20:20:32 <johnsom> Ok, well that was short
20:20:34 <johnsom> #topic Brief progress reports
20:20:46 <johnsom> How are things going (bug fixes I assume)?
20:20:56 <sbalukoff> Great! Need more reviews. :)
20:21:12 <johnsom> Feel free to put up some links
20:21:18 <sbalukoff> I think I have 4 or 5 bugfixes in the queue, most of which should be ready to merge...
20:21:21 <sbalukoff> Ok, hang on...
20:21:24 <bana_k> #link https://review.openstack.org/#/c/286365/
20:21:42 <sbalukoff> #link https://review.openstack.org/285160
20:21:43 <blogan> scenario job is still being a jerk
20:21:50 <johnsom> bana_k cool!  Looking forward to that
20:21:56 <sbalukoff> #link https://review.openstack.org/285192
20:22:05 <bana_k> :)
20:22:12 <sbalukoff> #link https://review.openstack.org/286410
20:22:15 <madhu_ak> #link https://review.openstack.org/#/c/284946/
20:22:16 <TrevorV> Since Rax has a dependency for single-create on neutron lbaas at this point, I'll be mainly focused on that, but the bugs are next on my priority list.  They'll be done before the bug-freeze though
20:22:18 <madhu_ak> #link https://review.openstack.org/#/c/284875/
20:22:24 <sbalukoff> #link https://review.openstack.org/285783
20:22:36 <sbalukoff> #link https://review.openstack.org/285143
20:22:56 <dougwig> a wall of review links is a little dense to parse.  maybe an etherpad of priority reviews?  (with bugs and FFE's listed first)
20:22:57 <madhu_ak> #link https://review.openstack.org/#/c/172199/
20:23:19 <johnsom> I guess I should mention, if you have an open bug against an M3 patch, and you don't get it fixed, I will revert your original patch.
20:23:20 <sbalukoff> This might need more work following a discussion:
20:23:22 <sbalukoff> #link https://review.openstack.org/287118
20:23:36 <johnsom> Well, that would be a pain, but I will hunt you down
20:23:37 <sbalukoff> Also this:
20:23:39 <sbalukoff> #link https://review.openstack.org/287004
20:23:49 <sbalukoff> And finally:
20:23:51 <sbalukoff> #link https://review.openstack.org/286372
20:23:57 <johnsom> Unless I'm having a bad day, then it is revert
20:24:37 <johnsom> #link https://etherpad.openstack.org/p/Mitaka_LBaaS_priority_reviews
20:24:44 <johnsom> I will fill this in after the meeting
20:24:51 <sbalukoff> Ok.
20:24:54 <dougwig> cool
20:25:31 <johnsom> Ok then, moving on
20:25:32 <johnsom> #topic Open Discussion
20:25:37 <sbalukoff> Ok!
20:25:49 <sbalukoff> so question on the sesssion_persistence update fix:
20:26:11 <sbalukoff> The neutron-lbaas CLI presently has no way to clear the session_persistence on a pool once it is set.
20:26:37 <sbalukoff> So, in my patch, I added a way, but it involves introducing a new session_persistence "NONE" type...
20:26:45 <sbalukoff> Which is ugly, but works around the CLI problem.
20:26:57 <sbalukoff> Reedip has a CLI update in the works which fixes this as well...
20:27:09 <sbalukoff> But that fix also overhauls much of the CLI update stuff (which really needed it anyway),
20:27:19 <sbalukoff> And as such, I'm not sure whether it's going to get in for Mitaka.
20:27:36 <sbalukoff> The problem with my workaround is that we'd have to support a session_persistence NONE type going forward...
20:27:39 <johnsom> Yeah, the CLI for session persistence is ugly
20:27:40 <sbalukoff> Which I really dislike.
20:27:46 <sbalukoff> So the question is:
20:28:11 <sbalukoff> Do I not introduce the work-around, and just leave things broken for the CLI in Mitaka...
20:28:32 <sbalukoff> Or do I introduce the work-around, and then we support session_persistence NONE type going forward indefinitely?
20:29:10 <sbalukoff> I personally agree with blogan on this that I would really rather not introduce the work-around.
20:29:22 <sbalukoff> Also worth noting:
20:29:44 <sbalukoff> session_persistence has hardly worked at all before... so leaving the CLI broken in Mitaka wouldn't be a new experience for people, IMO.
20:30:42 <johnsom> I guess there is a workaround in recreating the pool if you want to disable SP
20:30:51 <johnsom> ugly, but possible
20:31:20 <sbalukoff> Yes... if you set session_perstence, a "work around" is to blow away your pool configuration and start over if you need to clear it.
20:31:31 <sbalukoff> Not that changing it from one type to another works fine.
20:31:43 <sbalukoff> But the CLI just doesn't jive with clearing it entirely right now.
20:31:44 <johnsom> It does work
20:31:51 <sbalukoff> Er..
20:31:59 <sbalukoff> Yes, typo:  "Note that changing..."
20:32:00 <blogan> antoher workaround is just providing a curl statement :)
20:32:14 <sbalukoff> blogan: True.
20:32:30 <sbalukoff> blogan: But... really, people would probably just blow away the pool and re-create it.
20:32:45 <johnsom> Ah, so via neutron-lbaas API you can disable it?  It's just a CLI issue?
20:32:47 <blogan> sbalukoff: probably, but with shared pools i could see that being a problem for some
20:33:07 <sbalukoff> Ok, so I'm hearing: Don't introduce new "NONE" session persistence type, and if people complain we tell them about the nasty work-arounds for Mitaka.
20:33:12 <blogan> johnsom: the client has issues with setting soemthign to null
20:33:23 <blogan> json null
20:33:24 <sbalukoff> johnsom: Yes, this is only a CLI issue.
20:33:56 <sbalukoff> And again, Reedip has a patch to fix it in the works, and it's pretty-much complete... but overhauls everything about lbaas updates (which needed to be done)
20:34:07 <sbalukoff> So, I'm not sure whether to call that a bug or a feature.
20:34:40 <blogan> sbalukoff: i haven't looked at it, but if its consistent with other calls that need to basically remove an attribute by setting null then thats the right way to go
20:34:46 <blogan> the fix could go in and then backport
20:34:50 <blogan> if its after m-3
20:34:53 <sbalukoff> blogan: Yes, from what I can tell it is.
20:35:05 <johnsom> I'm in favor of fixing the CLI and if it doesn't make it, put a release note in about the workarounds (API or delete/recreate)
20:35:16 <sbalukoff> johnsom: Ok!
20:36:17 <sbalukoff> I'm not hearing any voices in favor of introducing the work-around... so out it goes!
20:36:20 <neelashah> johnsom: fyi - Heat support for LbaaS v2 is in M3, functional tests are remaining and being worked on as part of FFE for M.
20:36:20 <sbalukoff> Thanks!
20:36:40 <johnsom> neelashah Excellent!
20:36:43 <sbalukoff> neelashah: awesome!
20:36:54 <johnsom> Thank you for the work on that!
20:37:14 <xgerman> +1
20:37:32 <neelashah> thanks markvan and jonesbr as well….
20:37:54 <sbalukoff> Yes, thanks!
20:38:03 <johnsom> Ok, any other open discussion items?
20:38:32 <johnsom> Other than please work on mitaka bugs!
20:38:39 <sbalukoff> Thanks, y'all!
20:38:48 <ajmiller> I'll just put in a plug for the dashboard
20:39:02 <ajmiller> Its pretty complete now, try it out!
20:39:04 <johnsom> Cool
20:39:09 <sbalukoff> Rad!
20:39:16 <neelashah> ajmiller +1
20:39:17 <xgerman> +1
20:39:45 <xgerman> now if I can figure out how to fill out that new form so cascading_Delete can stay...
20:40:36 <johnsom> Ok, sounds like we are done
20:40:38 <johnsom> #endmeeting