16:00:08 <dougwig> #startmeeting neutron lbaas
16:00:09 <openstack> Meeting started Tue Feb 17 16:00:08 2015 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:13 <openstack> The meeting name has been set to 'neutron_lbaas'
16:00:13 <dougwig> #topic roll call
16:00:18 <xgerman> o/
16:00:19 <ajmiller> Good Morning
16:00:20 <dougwig> agenda:
16:00:21 <dougwig> https://wiki.openstack.org/wiki/Network/LBaaS#Agenda
16:00:25 <rm_work> o/
16:00:27 <TrevorV> o/
16:00:30 <johnsom> o/
16:01:38 <evgenyf> Hi
16:02:07 <dougwig> #topic Announcements
16:02:19 <dougwig> Summit talk info
16:02:31 <dougwig> gathering thoughts for our summit stuff here:
16:02:32 <dougwig> https://etherpad.openstack.org/p/lbaas-vancouver-talks
16:02:39 <ptoohill> o/
16:02:40 <dougwig> And a few talks to consider voting on:
16:02:52 <dougwig> our friends at haproxy:
16:02:53 <dougwig> http://www.openstack.org/vote-vancouver/presentation/cool-haproxy-tips-you-want-to-know
16:02:53 <fnaval> o/
16:03:05 <dougwig> ours:
16:03:05 <dougwig> http://www.openstack.org/vote-vancouver/presentation/load-balancing-as-a-service-temp
16:03:12 <dougwig> http://www.openstack.org/vote-vancouver/presentation/neutron-mitosis-and-the-l7-services-roadmaps
16:03:15 <sballe__> morning
16:03:20 <dougwig> any others folks want to highlight for this group?
16:03:39 <Aish> o/
16:04:45 <dougwig> Last announcement from me: Kilo-3 is coming up fast (code proposal deadline is 3/5).  Vendor drivers especially, the earlier you submit the higher chance we'll have review cycles.
16:05:12 <dougwig> you realistically want to be a week before the 5th, in case there need to be a few roundtrips (find code is about 5 days after that)
16:05:21 <dougwig> /find/final/
16:06:08 <dougwig> any other announcements?
16:06:20 <rm_work> going to squeeze this in as it's somewhat time sensitive: it would be super useful if people would go +1 this (if you haven't already): https://review.openstack.org/#/c/156623/ (would like to have a decent number of +1s by the time we discuss this at the Barbican meetup)
16:06:38 <dougwig> that's the castellan tis library stuff, fyi.
16:06:42 <rm_work> yes
16:06:43 <dougwig> tls
16:06:51 <rm_work> So the thing I've been promising for a while now :)
16:06:59 <dougwig> :)
16:07:04 <dougwig> #topic v2 update
16:07:09 <rm_work> There's discussion about whether to include Certs in it or not -- the "not" case would be sucky for us
16:07:12 <dougwig> How our agent driver coming?  Any blocking issues?
16:07:20 <blogan> yes these reviews
16:07:32 <blogan> https://review.openstack.org/#/c/155545/
16:07:42 <blogan> https://review.openstack.org/#/c/155051/
16:08:35 <dougwig> great.  i'll put them on my list for today.  other eyeballs would also be good.
16:08:39 <dougwig> Testing...  how are we doing?
16:08:44 <santosh> hi All
16:08:54 <blogan> after those, the agent driver base is ready to be reviewed, the actual agent is being worked on by jorge, phil and myself so we can get it knocked out
16:09:14 <fnaval> dougwig: we have some outstanding PRs that are in the process of getting fixed
16:09:29 <fnaval> I think we'll be done with the initial API tests by the end of the week.
16:09:32 <dougwig> great.  how far do you think we are from a jenkins job?
16:09:41 <dougwig> you are telepathic.  :)
16:09:52 <dougwig> TLS & L7?
16:09:54 <fnaval> I'm currently researching how to do the scenario tests.  but ran into some issues with connectiing a network to a server in devstack
16:10:18 <dougwig> fnaval: does the existing v1 scenario test help at all?
16:10:24 <evgenyf> TLS & L7 - waiting for reviews
16:10:34 <evgenyf> https://review.openstack.org/#/c/145085/
16:10:37 <dougwig> evgenyf: can you link them here if you have them handy?
16:10:41 <evgenyf> https://review.openstack.org/#/c/148232/5
16:10:41 <fnaval> dougwig:  it does - i'm basing off the test I'm writing off of it
16:11:10 <fnaval> dougwig: i'm sure how to go about in setting up a jenkins job for it externally.
16:11:13 <dougwig> fnaval: you might want to ping mtreinish and get his opinion.  there are things he doesn't like about that test.
16:11:22 <dougwig> fnaval: i can help with that when the code is ready.
16:11:26 <dougwig> evgenyf: thank you
16:11:27 <fnaval> dougwig: ok thanks
16:11:51 <dougwig> Docs? I think HP was taking those on?
16:12:06 <xgerman> yep, mwang2 was working on those
16:12:11 <blogan> https://review.openstack.org/#/c/148687/
16:12:26 <blogan> needs some reviews and address comments
16:12:43 <xgerman> ok, I will let Min know
16:12:50 <dougwig> do we have install or cli usage docs, like v1?  are we planning those?
16:13:02 <dougwig> blogan: thanks for the link
16:13:26 <dougwig> Devstack?  I saw that Al had new reviews up.
16:13:35 <blogan> dougwig: if anyone wants to tackle thsoe, it would add value fo rsure
16:13:50 <ajmiller> Yes.  I need to post an update to the readme, but otherwise I think it is ready to go.
16:14:10 <dougwig> here's the lbaas side of ajmiller's review:
16:14:11 <dougwig> https://review.openstack.org/#/c/155540/
16:14:30 <ajmiller> And this is the devstack side:
16:14:31 <ajmiller> https://review.openstack.org/#/c/153079/
16:14:41 <dougwig> Any takers for install or CLI docs?  Anyone awake yet?  :)
16:14:52 <xgerman> Aish?
16:15:18 <dougwig> xgerman: can you coordinate finding an owner for that?
16:15:30 <xgerman> yep, we will find someone
16:15:35 <dougwig> xgerman: thank you.
16:15:48 <dougwig> Stats?  blogan had comments here.
16:16:48 <blogan> so the stats are currently just a total for a load balancer
16:17:08 <blogan> i believe we had discussions where the stats would be split up by listener
16:17:16 <xgerman> yep, that would be better
16:17:37 <Aish> yes.. German..?
16:17:51 <dougwig> if we're going to change anything, let's finalize a decision *today*.
16:17:54 <xgerman> Aish, Al + I will take it offline
16:18:01 <blogan> even if it is split up by listener, the REST API will still have the stats call off the load balancer
16:18:05 <Aish> okay.
16:18:08 <blogan> and the body will have to split it up by listener
16:19:13 <xgerman> worlks for me
16:19:26 <dougwig> fine by me as well.
16:19:28 <blogan> so option 1) dont split up now, add that in later since that is just additional fields in the response body, so its not backwards incompatible
16:19:29 <TrevorV> Blogan you mean you'll have a list of listener stats where each object in the list will include the id of the listener they pertain to?  Sorta thing?
16:19:38 <blogan> yes TrevorV
16:19:41 <TrevorV> kk
16:20:18 <blogan> option 2) split up now, which requires a change in how the drivers return their stats
16:20:36 <blogan> if someone thinks they can do option 2 now, great go for it
16:20:48 <dougwig> or 1+2) split it now for ref, allow the listener data to be optional for others.
16:20:59 <xgerman> dougwig +1`
16:21:00 <blogan> but id still like the REST stats call body to return total stats for a load balancer
16:21:35 <xgerman> so why can't we do that?
16:21:37 <blogan> so if its optional, the REST call returns nothing for the listeners?
16:21:40 <xgerman> return both?
16:21:42 <dougwig> i'm not seeing an incompatible change here, so if we have time, let's do it.  if not, we can add it later?
16:21:46 <blogan> xgerman: we can
16:22:00 <blogan> dougwig: yeah its not incompatible if we add it later
16:22:25 <xgerman> let's try to squeeze it in -- if not we do it later...
16:22:28 <blogan> it might be a change for the drivers though, but if we go with the mentality that listener stats is optional for a driver then that works
16:22:39 <blogan> well to squeeze it in, someone needs to do it
16:22:54 <dougwig> i think we can add methods to the object managers and it's not backwards incompatible with the drivers.
16:23:30 <dougwig> we just have to write the plugin to cope with a default base class return value.
16:23:51 <blogan> yeah, there's a few way to skin it
16:24:08 <dougwig> ok, i'm calling this horse dead.  :)
16:24:17 <dougwig> #topic The future of this meeting
16:24:24 <blogan> unless someone wants to volunteer to give CPR to that horse
16:24:51 <xgerman> I am trying to volunteer people but they are not responding...
16:25:02 <blogan> you mean voluntell people eh?
16:25:11 <xgerman> like jorgem
16:25:14 <dougwig> this topic is to get folks thinking.  after kilo, without v2, we won't have much to talk about.  so, options are: 1) we get a new big feature list brainstormed at vancouver, 2) we fold this meeting into the neutron on-demand agenda, 3) we fold together lbaas and octavia, or 4) we keep getting up early because we enjoy the sunny conversation.
16:25:22 <jorgem> hey now
16:25:34 <rm_work> #vote 3
16:25:38 <johnsom> Hahaha
16:25:51 <jorgem> #4
16:26:01 <dougwig> is this community ready for another big rush of features, or do we need time to assimilate v2?
16:26:01 <johnsom> I think once V2, TLS, and L7 are cooked we go for #3
16:26:03 <blogan> #vote 3, we'll have a lot to talka botu to implement sharing, but i think that will all be implementation discussions
16:26:08 <xgerman> fold ocatvia in lbaas?
16:26:22 <dougwig> xgerman: merge those two meetings.
16:26:24 <sballe__> I like #3
16:26:51 <jorgem> #3 too.
16:27:07 <kobis> #3 makes sense. #1 is ideal, dunno about realistic :)
16:27:12 <xgerman> jorgem, you can hve #3 and #4 :-()
16:27:20 <dougwig> i'm not in a hurry to make a decision, but something else to consider: which meeting slot do we use if we merge?  it'd be better for our overseas members to not do US afternoon.
16:27:31 <rm_work> T_T
16:27:31 <jorgem> :)
16:27:38 <sballe__> dougwig: +1
16:27:42 <blogan> i think #1 will need to happen after everything has settled down and stabilized
16:27:55 <sballe__> blogan: I agree with you
16:28:00 <kobis> blogan: +1
16:28:02 <dougwig> no fans of using the neutron on-demand format?  (you add topics to the wiki when you have something to talk about, use their rotating slots.)
16:28:17 <xgerman> I don't ven know when the neutron meeting is
16:28:21 <dougwig> lol
16:28:28 <rm_work> yeah what is this Neutron thing
16:28:33 <dougwig> we are, technically, part of the neutron project.  :)
16:28:39 <blogan> dougwig: not at this moment, but if we get to a point where we have nothing to talk about in many meetings then that would make sense
16:28:59 <rm_work> I thought we revolted and made our own country
16:29:01 <TrevorV> dougwig I'm a fan of the on-demand one
16:29:12 <xgerman> well, we finish lbaas meeting and octavia meeting often early so combining wpould make sense
16:29:14 <rm_work> $@$% it TrevorV
16:29:18 <rm_work> lol
16:29:19 <kobis> so we have to monitor the neutron agenda? how does it work?
16:29:31 <jorgem> rm_work: We are like the Texas of manifest destiny
16:29:35 <blogan> kobis: same as lbaas, just longer
16:29:47 <xgerman> link?
16:29:47 <sballe__> rm_work: +1
16:30:00 <dougwig> kobis: yes. their decisions affect us quite a bit, so I go to those anyway (in addition to being interested in neutron in general, anyway.)
16:30:28 <blogan> https://wiki.openstack.org/wiki/Network/Meetings
16:30:30 <dougwig> here's neutron's agenda:
16:30:30 <dougwig> https://wiki.openstack.org/wiki/Network/Meetings
16:30:40 <dougwig> scroll down to the "On Demand" section.  anyone can add any topic in there.
16:31:00 <dougwig> most of the neutron meeting is usually stuff from that part of the agenda.
16:31:06 <kobis> that would make sense only if lbaas+octavia won't fill a weekly meeting in any case
16:31:31 <blogan> yeah, i think the natural evolution is to first combine lbaas into octavia, and then to the on-demand
16:31:42 <dougwig> or if the crowds involve diverge.
16:31:43 <xgerman> +1
16:31:47 <kobis> towgan: +1
16:31:51 <blogan> lol
16:31:52 <dougwig> lol
16:31:53 <rm_work> so, merge for now, revisit later
16:31:53 <xgerman> lol
16:32:00 <xgerman> +100
16:32:15 <blogan> dougwig: crowds involve diverge?
16:32:27 <dougwig> let's decide at or after vancouver.
16:32:44 <sballe__> perfect
16:32:49 <dougwig> blogan: if the folks involved in octavia and neutron lbaas start to diverge.  right now, they are very similar.
16:33:01 <blogan> ah ok i see
16:33:11 <dougwig> #topic Open discussion
16:33:21 <xgerman> so you don't think we can assimilate...
16:33:40 <kobis> Q: do we have/want to set any convention for how to hold lbaas v1/v2?
16:33:55 <dougwig> parse failure.
16:33:58 <dougwig> kobis:
16:34:08 <kobis> e.g under <vendor>/v1/driver <vendor>/v2/driver
16:34:20 <kobis> or <vendor>/driver_v1
16:34:21 <kobis> etc?
16:35:02 <blogan> kobis actually the new agent changes addresses that
16:35:08 <dougwig> i was planning $vendor/driver_v{1,2}, but i'm pretty neutral on the subject.
16:35:27 <dougwig> oh right.  blogan, do you want to describe that?
16:35:32 <Chitr> Can you share status for SSL/Offload and L7 Switching changes to plugin? Will it be available by Kilo3?
16:35:51 <dougwig> Chitr: see the log at 9;10am
16:36:00 <blogan> so basically, there's no reason to have the services.loadbalancer naemspace since we arent in neutron's tree
16:36:02 <dougwig> 23 minutes ago, for those not in the mountain time zone
16:36:16 <sballe__> :-)
16:36:19 <blogan> so v2 code should go into the neutron_lbaas.* namespace
16:36:30 <blogan> so v2 drivers would be in neutron_lbaas.drivers
16:36:41 <dougwig> (yay!)
16:36:43 <blogan> v1 drivers remain in neutron_lbaas.services.loadbalancer.drivers
16:36:55 <kobis> so each vendor code is scattered between here and there?
16:37:21 <evgenyf> currently v1 drivers code is copied to neutron-lbaas
16:37:24 <blogan> unless you think having neutron_lbaas.drivers.v1/v2 makes sense
16:37:35 <kobis> whouldn't it make sense to keep a reference in the old namespace for backward compatibility
16:37:42 <dougwig> yes, though v1 is effectively dead from a dev perspective, so we're planning the tree based on how it should be laid out when that code is gone.
16:37:53 <xgerman> +1
16:37:59 <kobis> and have it all in neutron_lbaas.drivers?
16:38:04 <dougwig> blogan: which review is this in, so folks can comment on the new layout scheme or give feedback?
16:38:44 <evgenyf> radware does services/loadbalancer/drivers/radware/v2/
16:39:10 <blogan> https://review.openstack.org/#/c/156131/ but it might make sense to just have a review that does it explicitly
16:39:22 <blogan> bc this is the agent driver base review
16:39:38 <blogan> evgenyf: can that not be changed before it gets merged?
16:39:48 <dougwig> kobis: we weren't planning to move the v1 plugin and such.  moving them and leaving a placeholder means we hit name collision issues and have to propagate the v2 on every module, which will be irritating once v1 is actually removed from tree. that'd be the biggest drawback.  drivers are much easier to do what you're suggesting, though.
16:40:22 <dougwig> though i'd rather just let them die than churn them, IMO.
16:40:26 <evgenyf> blogan: not be changed or changed?
16:40:38 <blogan> evgenyf: can it be changed?
16:40:44 <xgerman> yeah, dead to v1!!
16:40:52 <evgenyf> blogan: sure
16:41:02 <blogan> v1 wont be dead, it'll just be quarantined :)
16:41:16 <dougwig> separate but equal?
16:41:27 <dougwig> wait, isn't that how lbaas is with neutron?  :)
16:41:29 <kobis> yep - for that miserable dude who actually uses it and won't migrate :(
16:41:30 <evgenyf> so going for drivers/<vendor>?
16:41:42 <blogan> lbaas is separate yes, equal? i dont think so
16:41:55 <blogan> evgenyf: yes
16:41:57 <xgerman> some projects are more equal than others...
16:42:08 <blogan> woudl a more explicit review that pushes this change in be better for everyone?
16:42:21 <dougwig> blogan: yep, soundsl ike
16:42:27 <blogan> it'll just be setting up the new structure
16:42:58 <blogan> i dont think we should move the code that has been merged just yet though
16:43:10 <blogan> such as the v2 plugin
16:43:34 <blogan> but id like to at some point
16:43:38 <blogan> before kilo 3
16:43:52 <blogan> bc that changes how people point to hte plugin in the config
16:44:30 <blogan> any opinions on moving the v2 specific code that has already merged?
16:44:39 <dougwig> i'm in favor of moving it.
16:44:44 <xgerman> +1
16:44:46 <blogan> all o fit?
16:44:57 <kobis> +1
16:45:02 <dougwig> v2 to the new scheme?  yes.
16:45:04 <blogan> id prefer to do it in a separate review then
16:45:20 <blogan> just so the new structure can go in quickly and driver writers can get to it
16:45:34 <dougwig> you'll likely need a placeholder for the service plugin until we can unwind the old location from devstack.
16:45:51 <blogan> yeah that can just be a redirect
16:46:07 <blogan> through inheritance
16:46:08 <dougwig> we will eagerly await for gerrit review.
16:46:21 <xgerman> +1
16:46:29 <dougwig> or just set "blah = new.spot.blah"
16:46:34 <blogan> in the interest of getting +2's can someone else do this?
16:46:53 <ajmiller> I'm into devstack right now, would it make sense for me to do it?
16:47:08 <xgerman> I altreday volunteered you for stats
16:47:10 <blogan> i dont know, would it al?
16:47:40 <ajmiller> Hmm, well what xgerman said, I don't want to get spread too thin.
16:48:17 <xgerman> we will find somebody - moving code looks like a easys ATC
16:48:19 <dougwig> i'll assume towgan can find a victim offline.
16:48:20 <blogan> okay someone from our team will do it
16:48:36 <dougwig> any other open discussion items today?
16:49:06 <dougwig> i'm going to end by repeating this, for the later risers among us:
16:49:07 <dougwig> Last announcement from me: Kilo-3 is coming up fast (code proposal deadline is 3/5).  Vendor drivers especially, the earlier you submit the higher chance we'll have review cycles.
16:49:17 <dougwig> thanks, folks
16:49:29 <sballe__> have a great day
16:49:33 <kobis> bye
16:49:38 <dougwig> #endmeeting