14:00:05 <jorgem> #startmeeting neutron lbaas
14:00:06 <openstack> Meeting started Thu Jul 31 14:00:05 2014 UTC and is due to finish in 60 minutes.  The chair is jorgem. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:09 <rm_work> o/
14:00:09 <blogan> sballe_: thief! thats mine
14:00:10 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:14 <blogan> \\o//
14:00:17 <johnsom_> hello
14:00:20 <vjay> Hi
14:00:31 <sballe_> blogan, yeah I really like the \o/
14:00:33 <crc32> hello
14:00:41 <jorgem> First off does anyone have anything else to add to the agenda #link https://wiki.openstack.org/wiki/Network/LBaaS#Meeting_31.07.2014
14:00:46 <sballe_> I do
14:01:02 <jorgem> sure thing
14:01:18 <sballe_> 2. LBaaS related talk submissions
14:01:18 <sballe_> * https://etherpad.openstack.org/p/Kilo_LBaaS_talk_submissions
14:01:19 <sballe_> * Please add your submissions and VOTE!! VOTE!! VOTE!!! And forward to other so they can VOTE!
14:01:43 <jorgem> added
14:02:04 <jorgem> Okay let's get going #topic Review Updates
14:02:04 <sballe_> I also have two items I things we need to talk about but maybe not today
14:02:05 <ctracey> morning
14:02:15 <sballe_> 1. Design sessions.
14:02:15 <sballe_> * Do we want to prepare for 3? One on Octavia, one on Flavor framework (with Advanced Services team), and on one Neutron LBaaS.
14:02:15 <sballe_> * When are the deadlines for design sessions so we don�t miss it.
14:02:15 <sballe_> * Also should we talk at the next summit about prioritization of the K work? Should we have some specs/BP submitted prior to the Paris summit?
14:02:17 <xgerman> https://review.openstack.org/110824
14:02:22 <sballe_> 3. Mid-cycle meetup.
14:02:22 <sballe_> * I have noticed that Neutron has their mid-cycle meetup right before juno-2 and nova had it this week. What is the best time for us to have our next meetup? Before kilo-2 or right after?
14:02:34 <sballe_> apology for messing up the flow
14:02:52 <jorgem> no worries, actually do you mind updating the agenda wiki with all of that? lol
14:02:59 <sballe_> sure
14:03:03 <jorgem> thanks
14:03:10 <jorgem> Okay on to the first topic
14:03:11 <jorgem> #topic Review Updates
14:03:29 <jorgem> Any reviews need attention?
14:03:33 <xgerman> https://review.openstack.org/110824
14:03:39 <xgerman> ok, now it's time
14:03:48 <blogan> We need to start gettnig the 3 log jammer reviews merged in
14:03:54 <ctracey> jorgem: I will have a whole bunch of them
14:04:06 <jorgem> Let's link them all out here
14:04:10 <blogan> the first one, the extension, can get merged in asap
14:04:19 <jorgem> using the hastag link feature
14:04:30 <xgerman> #link https://review.openstack.org/110824
14:04:54 <blogan> xgerman: ah awesome getting that updated
14:05:05 <xgerman> Min did the work :-)
14:05:21 <sballe_> +1 for Min
14:05:22 <jorgem> Everyone please add your links and let us know if there is a particular area you'd like the community to review or if you just need a general review.
14:06:26 <blogan> #link https://review.openstack.org/#/c/105331
14:06:31 <sbalukoff> blogan: I don't suppose there's a particular order you're looking to get yours done in?
14:06:52 <blogan> sbalukoff: well they have to be done in order of the dependencies
14:07:08 <sbalukoff> Right
14:07:11 <blogan> the link above is the beginning of the chain
14:07:20 <jorgem> nice any other reviews?
14:07:37 <blogan> #link https://review.openstack.org/#/c/105609
14:07:48 <ptoohill> #link https://review.openstack.org/#/c/106867/26
14:07:49 <crc32> https://review.openstack.org/#/c/109849/ <-- I'd kinda like to get this one rail roaded through so we can start parallel development.
14:07:53 <rm_work> #link https://review.openstack.org/#/c/107845/
14:07:59 <blogan> made some changes last night to that one above, thats another topic though
14:08:03 <ptoohill> #link https://review.openstack.org/#/c/106867/27
14:08:37 <jorgem> okay, I just wanted all the links so we can easily go through the chat logs :)
14:08:39 <jorgem> thanks
14:08:43 <jorgem> moving on...
14:08:47 <jorgem> #topic Octavia Work
14:08:48 <rm_work> ah yeah, needed to discuss the link crc32 provided with evgeny
14:09:01 <jorgem> So...
14:09:21 <evgenyf> https://review.openstack.org/#/c/109035/ will be ready for review later today after I will fix migration issues
14:10:00 <jorgem> For those that are interested in Octavia work it would be nice if you could do some research on what network topologies you think you'll be using in production.
14:10:03 <sballe_> evgenyf, ping folks on openstack-lbaas and i'll be happy to review
14:10:21 <rm_work> evgenyf: I pushed a change to one of your reviews (the barbican/TLS stubs), can you take a look and see if that looks ok to you? I have been the one doing the barbican development, and that is the flow I see to be necessary
14:10:55 <jorgem> One area of concern right now is how exactly will Octavia plug in to our respective networks
14:11:00 <evgenyf> rm_work: I saw it and pushed a fix for pep8 issue. I will comment inline
14:11:09 <rm_work> ah k
14:11:11 <rm_work> thanks
14:11:13 <evgenyf> rm_work: Thank you
14:11:52 <jorgem> Anyone have questions about this? So far, BB, HP and Rackspace are doing this. Ebay/Paypal?
14:11:56 <crc32> so how do we work on this in parrallel though? It seems like each pathch set is treated as a brand new commit in gerrit.
14:12:27 <evgenyf> crc32: we have dependencies
14:12:55 <sballe_> jorgem, Do we agree that Octavia needs to support OpenStack supported network setup
14:13:01 <sbalukoff> On jorgem's point: I'm hoping similarities in needs will emerge here so that there are a limited set of topologies that we need to solve for.
14:13:06 <rm_work> it will make things easier if we get some of these things pushed through <_<
14:13:38 <jorgem> evgenyf: crc32: Let me bring up your topic next
14:13:43 <sbalukoff> sballe_: I'm not sure what an "unsupported" OpenStack network setup would look like. But for now, let's just gather the data on what people need here.
14:13:52 <jorgem> Sorry I kind of rushed the reviews :/
14:14:05 <sballe_> sbalukoff, I just want to make sure that we are assuming Neutron is there.
14:14:13 <jorgem> sballe_: Yes agreed.
14:14:17 <xgerman> +1
14:14:20 <sbalukoff> sballe_: Yes, we're working with Neutron.
14:14:33 <sballe_> and aren't planning for Octavia to support other networking packages
14:14:39 <jorgem> sballe_: I would say that's the default if that's even a concept here
14:14:45 <sbalukoff> sballe_: Not initially.
14:14:45 <xgerman> but the only Neutron reference implementation I know is devstack
14:14:58 <sballe_> jorgem, ok just making sure we are all in agreement :-)
14:15:09 <sballe_> xgerman, and HP Public cloud
14:15:35 <jorgem> The idea is for production networks.
14:15:47 <sballe_> jorgem, Makes sense.
14:16:07 <sbalukoff> Again, let's just gather the data for now, eh. :)
14:16:08 <xgerman> jorgem, agreed.
14:16:24 <jorgem> #action Interested parties in Octavia to research their respective network topologies by next week.
14:16:49 <jorgem> Also, the Octavia folks are going to start up the meetings again next week
14:17:06 <sbalukoff> Same bat time, same bat channel.
14:17:27 <jorgem> sbalukoff: Correct, until we deem otherwise right?
14:17:37 <sbalukoff> So, Wednesdays at 1:00pm PDT (20:00 UTC), iniitally via video chat using A10 networks webex.
14:17:47 <sbalukoff> jorgem: Yep!
14:17:58 <sbalukoff> Also, Doug says we can plan on using that webex indefinitely.
14:18:06 <jorgem> cool, anything else related to Octavia?
14:18:09 <sbalukoff> (Thank you, Doug!)
14:18:14 <jorgem> +1
14:18:16 <sbalukoff> Oh!
14:18:19 <sballe_> dougwig, +100
14:18:24 <sbalukoff> Please review...
14:18:30 <blogan> so if octavia has its own meeting essentially, should we not discuss in detail octavia in here?
14:18:37 <sbalukoff> This:
14:18:39 <jorgem> that makes sense
14:18:40 <sbalukoff> #link https://review.openstack.org/#/c/110563
14:18:41 <sballe_> sbalukoff, can you send an invite out with the info ?
14:19:22 <sbalukoff> sballe_: Yes. Can those interested in attending that meeting contact me directly? sbalukoff@bluebox.net
14:19:34 <sbalukoff> We should eventually get this into a wiki.
14:19:49 <jorgem> Okay, ready for next topic?
14:20:27 <jorgem> #topic Parallel TLS Work
14:20:37 <jorgem> crc32: evgenyf ?
14:20:41 <evgenyf> Yes,
14:20:43 <rm_work> and rm_work
14:20:52 <jorgem> and rm_work :)
14:21:16 <evgenyf> TLS is now depending on the whole tree of blogan (extension, DB, tests) and on Barbican common module as well
14:21:24 <crc32> I'm just wondering how we all work together with gerrit so that the end work doesn't look like one confusing Patchset with a single author when it gets merged into github.
14:21:38 <evgenyf> I made some mistaken commits there, sorry for that
14:21:40 <blogan> and its a redwood tree!
14:21:42 <evgenyf> now it seems OK
14:21:43 <rm_work> well, stubbing like this is one way
14:22:00 <rm_work> my work is mostly in one file, and crc32's will be in another
14:22:02 <blogan> evgenyf: no problems, we're in uncharted territory for many people
14:22:10 <blogan> evgenyf: hopefully my email helped out
14:22:24 <evgenyf> blogan:It helped me, thank you
14:22:27 <crc32> Its like the last if one person adds a single line and are the last ones to modify the patchset then poof when it the commit gets merged it looks like that single person wrote the entire commit. How do we resolve this?
14:22:34 <rm_work> unless we are not planning to merge the stubs, and actually need to do the code in this one CR...
14:22:38 <ptoohill> rm_work are you doing the plugin integration?
14:23:05 <jorgem> crc32: We have an agenda item that dougwig added about that.
14:23:06 <rm_work> ptoohill: I probably will do everything in barbican_utils.py, which is to say, I think yes?
14:23:09 <blogan> im pretty sure you're supposed to do the code
14:23:45 <ptoohill> ok, was asking more about the work that will need to be done in the plugin, which i may work on if needed
14:24:14 <rm_work> I'll be working on providing the raw methods that other people will need to use to get certificate data
14:24:19 <blogan> evgenyf: you're intention was not just for the stubs to get merged in, but for rm_work and crc32 to actually implement the code in that review correct?
14:24:32 <ptoohill> gotcha, then ill be using what your working on ;) thank you
14:24:39 <evgenyf> blogan: right
14:24:57 <evgenyf> I only pushed the skeleton with API
14:25:19 <evgenyf> And integrated a call to it in TLS patch
14:25:22 <rm_work> k, well then crc32 i don't see a way around it, one person will end up getting "credit", but does it really matter? don't think any of us are still in need of ATC status or anything
14:25:29 <rm_work> and we can add co-authored-by
14:25:47 <xgerman> well, there is a way to add up to 5 people
14:25:54 <xgerman> yep co-authored
14:26:00 <xgerman> they should get credit, too
14:26:01 <ptoohill> stacklytics still tracks each commit even though the one that makes it 'in' is by one author i believe
14:26:21 <rm_work> yeah, i don't know if i care whose name pops up next to the line in a git-blame :P
14:26:45 <rm_work> heck, if it's NOT me, then people might bug me about it less in the future :)
14:27:30 <rm_work> we'll just have to coordinate when making patchsets for that CR
14:27:46 <crc32> ok I'll ask my questions about gerrit on the mailing list.
14:27:47 <blogan> i just want it merged in
14:28:33 <jorgem> #action Send email to ML on parallel dev with Gerrit
14:28:43 <jorgem> Okay, ready for next topic?
14:28:57 <sballe_> sure
14:29:02 <jorgem> k
14:29:06 <jorgem> #topic Change to move handling of ACTIVE/ERROR/DEFERRED and db deletes out of drivers
14:29:23 <jorgem> dougwig: ?
14:30:08 <blogan> well i'm sure I can take this one
14:30:10 <sbalukoff> I've not seen him say anything this morning yet.
14:30:16 <sbalukoff> Go for it, eh!
14:30:35 <xgerman> go, blogan, go
14:30:43 <jorgem> you can do it blogan!
14:30:49 <blogan> basically, in v1 the drivers were responsible for deleting the actual entities out of the database, and setting the correct status when the operation was complete or failed
14:31:27 <blogan> following this same workflow with the new models meant that there's is just a ton of status management and db management for every driver to do, and every driver can do it differently
14:32:09 <ptoohill> dougwig said he may have some issues getting to meeting today, just fyi
14:32:35 <blogan> so I pushed up code last night in which the plugin takes care of the db deletes and status management, and the driver's only duties are to do waht they do best, and raise exceptions when bad things happen
14:32:49 <jorgem> blogan: I think that's nice and clean
14:32:52 <avishayb> blogan: only the driver can set the status - no one else - right?
14:32:56 <sbalukoff> I like the idea, but it seems a little unfair to impose that on vendors without anyone here being a voice for a vendors in this...
14:33:14 <johnsom_> I like this model too
14:33:16 <sbalukoff> Oh hey!
14:33:17 <blogan> avishayb: now the driver shouldn't set the status, if an error happens driver needs to throw an exception
14:33:19 <sballe_> blogan, +1
14:33:25 <sbalukoff> avishayb is here!
14:33:42 <blogan> avishayb: otherwise it is assumed everything went well and ACTIVE will happen
14:33:48 <xgerman> blogan +1 Exceptions good
14:34:20 <xgerman> blogan, there was alaso the mixin
14:34:25 <xgerman> how do they relate
14:34:38 <blogan> this logic should get more robust as time goes on as well
14:34:42 <sbalukoff> avishayb: What do you think of blogan's proposal?
14:34:43 <avishayb> Radware driver is async - he can 'decide' about the status 2 min after the call to the driver is done.
14:34:45 <blogan> xgerman: mixin?
14:35:04 <xgerman> I thought dougwig had some set_sttaus mixin at one point
14:35:10 <jorgem> blogan: So if exception go into ERROR status, otherwise go into ACTIVE (or similar) status?
14:35:12 <sbalukoff> I suspect the Radware driver won't be the only async one.
14:35:15 <vjay> if it is a long operation for the driver, what is recomended for the driver to do??
14:35:30 <blogan> hmm i looked at radware's and didn't think it looked like it was async
14:36:10 <avishayb> let me share with you what we are doing - we return ASAP to the caller plugin and doing activity in the bg
14:36:15 <jorgem> vjay: Same concern (potentiall) for Octavia as well.
14:36:28 <blogan> is the driver doing a periodic check?
14:36:41 <avishayb> yep
14:36:44 <jorgem> callbacks???
14:36:58 <sbalukoff> Aah-- so that's where we can hook in
14:37:10 <blogan> well that's a monkey wrench in gears
14:37:43 <xgerman> I thought the plan was to offer the mixin and then fill in code to put it on a queue, in DB, whatever
14:37:45 <avishayb> radware driver has a thread that takes care of the bg work. this thread does the state management
14:37:59 <vjay> netscaler also falls in similar model to radware. the driver will return almost instantaneously..
14:38:20 <blogan> okay we need to discuss this further then because drivers takign care of all the status management will be insane because one driver will do it one way and another do it another
14:38:34 <vjay> Once the operation is complete driver should be able to mark the operation COMPLETE
14:38:39 <jorgem> Sounds like a topic for ML.
14:39:02 <xgerman> the whole status thing is a can of worms
14:39:09 <blogan> sounds like a brain storm needs to happen after this meeting if people can
14:39:25 <jorgem> xgerman: hmm I remember saying something about this...
14:39:28 <jorgem> lol
14:39:45 <avishayb> another point about status - as for now it is an open set in DB. Every driver can push in whatever he likes too - right?
14:39:58 <blogan> you mean it can be any string?
14:40:01 <xgerman> that's another thing we like to change
14:40:01 <avishayb> too == to
14:40:18 <avishayb> yep - any string.
14:40:40 <blogan> yeah that is true, no enums in the db
14:40:42 <avishayb> its not DB Enum
14:41:26 <avishayb> those points are part of a bigger discussion - 'state management' - right?
14:41:35 <blogan> yes indeed
14:41:39 <xgerman> + 1
14:41:45 <sballe_> +1
14:41:47 <vjay> +1
14:41:50 <blogan> and who should have that responsibility
14:42:02 <xgerman> tate management might be another design session ;-)
14:42:07 <xgerman> tate=state
14:42:10 <jorgem> okay ML it is for this then. Let's move onto next topic cause this one is a big one
14:42:20 <avishayb> It is out of J scope for sure.
14:42:23 <sballe_> jorgem, agreed
14:42:30 <avishayb> so lets wake it up in ML
14:42:38 <jorgem> #topic Don't let gerrit overwrite dependent commits
14:42:56 <jorgem> dougwig brought this up but is not here so….blogan?!?
14:43:14 <xgerman> is there a way we can technically prevent that?
14:43:16 <jorgem> I don't think we can force gerrit to do this.
14:43:30 <jorgem> at least, without affecting everyone in openstack
14:43:46 <jorgem> == probably not going to happen quickly
14:43:46 <xgerman> so we are talking convention
14:43:52 <blogan> anyone who is doing gerrit dependent reviews should read this email: #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/041470.html
14:44:03 <sbalukoff> Would it be helpful to publish a 'best practices' guide to avoid accidentally doing this?
14:44:20 <sbalukoff> (Something like what blogan sent to the ML)
14:44:21 <evgenyf> When adding dependencies for the first time and commiting, every dependencies get an empty commit, next times - no
14:44:23 <sbalukoff> Dang, I'm slow.
14:44:26 <ptoohill> cherry-pick is friend, following those practices in mail makes things easier without the mess as i can attest
14:44:54 <blogan> im pretty sure everyone has overwritten a dependent commit
14:45:05 <blogan> its the initiation process
14:45:09 <sballe_> blogan, Can we add this to the wiki?
14:45:17 <xgerman> +1
14:45:20 <sbalukoff> +1
14:45:21 <xgerman> in red and blinking
14:45:22 <blogan> yeah that'd be good
14:45:36 <jorgem> #action blogan to add best practices for gerrit to wiki
14:45:50 <jorgem> okay next topic?
14:45:57 <sbalukoff> I would recommend adding it to the gerrit workflow wiki page.
14:46:05 <blogan> yeah ill do that
14:46:05 <xgerman> +1
14:46:06 <sbalukoff> So it's easy for everyone to find.
14:46:13 <jorgem> agreed
14:46:19 <sballe_> +1
14:46:20 <jorgem> #topic LBaaS related talk submissions
14:46:28 <jorgem> sballe_: floor is yours
14:46:33 <sballe_> thx
14:46:47 <sballe_> I just want to make sure we get as many LBaaS related talks in as possible.
14:47:00 <crc32> #link is https://etherpad.openstack.org/p/Kilo_LBaaS_talk_submissions
14:47:10 <sballe_> So I asked folks to list them on the etherpad and then we all need to VOTE!
14:47:27 <sballe_> please ask your friends to vote too!
14:47:40 <sballe_> that is pretty much it
14:48:05 <jorgem> I made posters for the lbaas campaign and put them up at the public library :)
14:48:16 <xgerman> go cube to cube...
14:48:19 <sballe_> jorgem, sounds great +1
14:48:26 <sbalukoff> Haha!
14:48:28 <jorgem> lol
14:48:43 <jorgem> okay next topic
14:48:51 <jorgem> #topic Design Sessions
14:49:04 <jorgem> sballe_: all you again!
14:49:07 <sballe_> ok so mestery told me the deadline is late September
14:49:11 <sbalukoff> Submission deadline for that is Sebtember right?
14:49:17 <sballe_> so we migth be a little early here ;)
14:49:18 <jorgem> specifically which date?
14:49:26 <sballe_> he didn;t say
14:49:34 <xgerman> assume 9/1
14:49:42 <xgerman> then we waon't miss it
14:50:06 <sballe_> I just want to make sure we get sessions in on time and that we know what sessions we want to prepare for.
14:50:28 <sballe_> Also do we want to prepare spcs/BP to talk about during htese sessions?
14:50:56 <sbalukoff> Yep
14:51:05 <sballe_> Anyway this was just a heads up that we still have to submit the design sessons and think about how we want to proceed
14:51:39 <xgerman> +1
14:51:47 <xgerman> last time session space was pretty scarce
14:51:50 <sballe_> jorgem, maybe we should do a status on this one every week
14:52:09 <jorgem> sballe_: Should we add it to the weekly standup?
14:52:42 <sballe_> this is a group thing so I am not sure how the weekly standup would wotk.
14:52:52 <jorgem> We can just add it to the top I'm thinking
14:52:53 <sballe_> I believe we need the following 3 sessions: One on Octavia, one on Flavor framework (with Advanced Services team), and on one Neutron LBaaS.
14:53:15 <sballe_> jorgem, ok at the top would work
14:53:16 <jorgem> I don't disagree with that
14:53:18 <sbalukoff> jorgem: +1
14:53:48 <jorgem> sballe_: Would you like to own that then?
14:53:56 <blogan> sballe_: won't eugene or mark be the one's who create that design session?
14:54:11 <blogan> i mean teh flavor framework one
14:54:17 <sballe_> blogan, Not sure. Why Eugene>
14:54:26 <xgerman> we can suggest sessions :-)
14:54:35 <sballe_> the flavor one will need to e cross team. I agree
14:54:35 <xgerman> Kyle will schedule
14:54:35 <blogan> isn't he the one doing the implementation of the flavor framework?
14:55:09 <sballe_> jorgem, I am fine with putting me on as the owner for that. I'll coordinate :)
14:55:23 <jorgem> sballe_:  K thanks
14:55:36 <jorgem> #action sballe_ to coordinate design sessions
14:55:59 <jorgem> k, last topic with 5 mins left!
14:56:00 <sballe_> jorgem, blogan xgerman i'll reach out to the Advanced Services team to make sure we have a session on flavors
14:56:09 <jorgem> #topic Mid-cycle meetup.
14:56:32 <sballe_> This is more a retrospective thing and we don;t have to address it today
14:57:29 <sballe_> I would like for us to figure out whta worked and didn;t work for us with our meetup being so early in the cycle compared to other groups. Also I was wonderign if we should have scheduled a second one after juno-2 to make sure we get the last coding done
14:58:09 <sballe_> Maybe we can discuss this at the paris summit in person at the neutron pod
14:58:26 <sbalukoff> sballe_: +1
14:58:27 <sballe_> that's it for taht topi
14:58:33 <blogan> sballe_: im sure that will work
14:58:33 <sballe_> s/topic
14:58:35 <jorgem> okay
14:58:38 <xgerman> okay
14:58:39 <sbalukoff> Discussion at the paris summit to decide this makes sense.
14:58:58 <sbalukoff> Is that it? Done with a minute to spare
14:58:59 <sbalukoff> ?
14:59:02 <vjay> blogan: w.r.t. extension review, if you get the code back to where it was earlier (driver doing the DB update, extension giving the functions for help)  it will be easier to get it through. what do you think?
14:59:15 <vjay> just one last thing :-)
14:59:34 <vjay> i can take it up on openstack-lbaas
14:59:36 <sbalukoff> vjay: Mailing list!
14:59:40 <rm_work> o/
14:59:40 <xgerman> +1
14:59:44 <blogan> vjay: im afraid ill be gong that route
14:59:52 <xgerman> blogan +1
15:00:07 <blogan> vjay: but the extension review wasn't affected by this so it can get in still
15:00:16 <xgerman> o/
15:00:18 <jorgem> alrighty I believe we are out of time ladies and gents
15:00:23 <blogan> later
15:00:24 <sbalukoff> Thanks y'all!
15:00:27 <jorgem> move to lbaas channel?
15:00:28 <vjay> thanks!
15:00:33 <vjay> sure
15:00:34 <jorgem> see you guys!
15:00:35 <vjay> !
15:00:37 <jorgem> #endmeeting