14:01:38 <enikanorov_> #startmeeting neutron lbaas
14:01:39 <openstack> Minutes (text): http://eavesdrop.openstack.org/meetings/neutronlbaas/2014/neutronlbaas.2014-06-05-14.01.txt
14:01:40 <openstack> Log:            http://eavesdrop.openstack.org/meetings/neutronlbaas/2014/neutronlbaas.2014-06-05-14.01.log.html
14:01:41 <openstack> Meeting started Thu Jun  5 14:01:38 2014 UTC and is due to finish in 60 minutes.  The chair is enikanorov_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:44 <openstack> The meeting name has been set to 'neutron_lbaas'
14:01:49 <aburaschi> hi   o/
14:01:56 <evgenyf> Hi
14:02:03 <hyakuhei> o/ <- Rob from HP / OSSG.
14:02:03 <avishayb> hi
14:02:09 <blogan> hello
14:02:12 <crc32> hello
14:02:13 <enikanorov_> i'd like to cover few items today
14:02:15 <german__> hi
14:02:23 <mestery> o/
14:02:28 <rm_work> o/
14:02:31 <JulianCash> hello
14:02:38 <sballe> hi
14:02:40 <enikanorov_> i know there was some amount of discussions recently about various impl aspects
14:03:12 <enikanorov_> so, I'd like to start with the item that I'd name "scope of the first patch"
14:03:22 <enikanorov_> we have that API improvement blueprint
14:03:35 <enikanorov_> which in fact is quite complex if we do everything that we have planned
14:03:57 <enikanorov_> so I'd like to see that we limit the scope of each patch we produce under that blueprint
14:04:15 <enikanorov_> the goal for each patch is that it should be consistent and it should move us forward
14:04:16 <dougwig> morning
14:04:47 <blogan> so it still needs to be decided whether a new extension and plugin is created or the same one is kept and the old api is just translated to the new object model
14:04:52 <enikanorov_> by 'move us forward' i mean that it should introduce some thing valueble in the general direction that we have taken
14:04:53 <mestery> Also, each patch should be self-contained, and we need the reference driver to implement the new API as well.
14:04:58 <blogan> i believe kyle is going to bring that up on monday
14:05:04 <enikanorov_> ok
14:05:07 <mestery> blogan: Correct, at the team meeting.
14:05:11 <mestery> *neutron team meeting
14:05:34 <enikanorov_> so my personal opinion (you may refer to it then, if you want) is that we need to make a transition on existing extension
14:05:49 <sballe> blogan: I like the new extension and plug-in
14:05:51 <enikanorov_> it may lead to more bloated code, but it will be cleaned up eventually
14:06:21 <sbalukoff> I am also all for the new extension and plug-in.
14:06:40 <blogan> i think the separate extension and plugin is cleaner and allows for the clean up to be much easier later, however, i'm okay with whichever
14:06:44 <enikanorov_> i'm also fine with that, if rest of the core team finds in fine :)
14:07:03 <mestery> My personal opinion is I like the new extension and plugin model as well. :)
14:07:10 <enikanorov_> i mean, i would prefer progress rather than too long discussions
14:07:17 <rm_work> hmm, i didn't realize that was an option, but that sounds cleanest
14:07:19 <mestery> We should get consensus next Monday on this with the rest of the core team and then we can move forward.
14:07:28 <rm_work> neutron-lbaas2? >_>
14:07:48 <rm_work> that's one way to do versioning, I guess :)
14:07:53 <aburaschi> I agree on new extension is cleaner. I must ask about timings, however...
14:08:00 <sballe> This approach will alllow us to  have both APIs available for some time
14:08:16 <mestery> sballe: +1
14:08:17 <rm_work> yeah, would that be significantly more work? or would it actually be easier since no translation would be needed
14:08:38 <enikanorov_> the problem with this approach is that we have to write tons of code to get to working state
14:08:55 <mestery> enikanorov_: Yes, that's the downside, and it's a large one for sure.
14:08:56 <german__> we still will transalate at the object level...
14:08:57 <blogan> rm_work: i think it would be easier, but I'm also wondering if another version of the agent needs to be created as well, I'll defer to Eugene for that
14:08:58 <sbalukoff> Or... copy-paste a bunch of code to get to a working state.
14:08:59 <sballe> rm_work, It allows us to make sure we do the rigth thing and at the same time leave the old API/Model alone
14:09:09 <sballe> until we can transition
14:09:21 <german__> sbalukoff *shudder*
14:09:39 <dougwig> i'm pretty neutral on this, but both apis would work in both scenarios, and i'm not sure i see the "cleaner".  gnerally you fork when you need to operate on a different schedule, or because of an incompatible model.  neither is true here.  plus, what happens with drivers?  are we dup'ing them?  or will they know both models?  can vendors submit new drivers
14:09:39 <dougwig> against both models?
14:09:52 <rm_work> german__: I agree that's …. ick? but… if we literally just clone the old neutron-lbaas, rename it, and then go from there, it's pretty easy i guess
14:10:17 <enikanorov_> rm_work: i'd be concerned about mergeability of such code
14:10:36 <enikanorov_> and that's the biggest one
14:10:42 <german__> I just don't like copy*paste since I then need to do bug fixes two places (with the risk forgettingn one)
14:10:43 <blogan> and thats why I was hoping to get a quick consensus by the core reviewers
14:10:45 <sballe> enikanorov, that's what the other teams have done so there is a precedence
14:10:56 <sbalukoff> blogan: +1
14:11:07 <german__> blogan +1
14:11:08 <rm_work> german__: agreed, but ideally we'd be deprecating the original extension
14:11:18 <crc32> BLowGin: +1
14:11:23 <sballe> enikanorov, I agree since our plan is to bring the new code into Neutron
14:11:24 <blogan> i'd rather know up front whether that strategy will fail or be accepted before a lot of work is put into it
14:11:26 <rm_work> alright, so we're going to leave this one to monday?
14:11:38 <german__> yep
14:11:41 <rm_work> blogan: +1 then
14:11:42 <sballe> blogan, +1
14:11:44 <aburaschi> blogan +1
14:11:49 <german__> blogan +1
14:11:52 <mestery> blogan: +1
14:11:53 <enikanorov_> imo, (not trying to say on behalf of core reviewers, but...) if you make brogress and you're backward compatible - that should work for all of us
14:11:57 <enikanorov_> including core team
14:12:13 <mestery> enikanorov_: +1, progress and compatibility are a win-win
14:12:19 <sballe> enikanorov, agreed
14:12:47 <enikanorov_> i'm not sure about 100% bw compatibility  but i think basic scenarios can work with new api+translation
14:13:01 <blogan> yeah I feel the same way too
14:13:10 <aburaschi> quick question: achieving same level of functionality as we have now, but with the new API, by Juno, is the final goal?
14:13:12 <german__> that's what tests are for
14:13:18 <jorgem> Okay since we are moving on, can we talk about hackathon?
14:13:25 <enikanorov_> aburaschi: with translation - it could be even better
14:13:33 <enikanorov_> jorgem: yep, that's another item
14:13:53 <crc32> +1 jorgem
14:13:57 <mestery> jorgem: Yes, we need to nail down logistics there.
14:14:00 <sballe> I create the following agenda page: https://etherpad.openstack.org/p/1gsTm4GBdu
14:14:15 <sballe> I have added some items I feel we need to discuss and feel to add more
14:14:18 <jorgem> sballe: Very nice thank you
14:14:19 <enikanorov_> mestery: that's what i was going to talk about
14:14:26 <mestery> enikanorov_: Perfect!
14:14:52 <sballe> it also has some prep I feel we need to do before we meet
14:14:52 <enikanorov_> so recently we have discussed the possible implementation approach  with blogan
14:15:07 <enikanorov_> it seems that the following plan may make sense
14:15:44 <jorgem> So I have a question about the API model refactor. What functionality do we want to have exposed by the time the code freeze comes?
14:15:49 <enikanorov_> 1) introduce new object model underneath existing API - that makes sure existing scenarios work, new scenarios are limited to existing features level
14:16:05 <enikanorov_> by new object model i mean: loadbalancer and listeners
14:16:12 <enikanorov_> no major attribute changes yet
14:16:19 <enikanorov_> just to limit the scope of the change
14:16:57 <enikanorov_> so we need to do proper relationships at object model level, everything, and get it exposed via existing API
14:17:09 <enikanorov_> so, say, VIP will map to loadbalancer+its first listener
14:17:16 <blogan> yeah and thats what I have been doing
14:17:40 <blogan> even if we pivot to option #2 I know the code so much better now
14:17:47 <enikanorov_> the second patch is then introduces actual new objects in rest api layer
14:17:49 <sbalukoff> Isn't all of that affected by what we just talked about?
14:17:58 <enikanorov_> which should not be a big deal
14:18:02 <blogan> yes it is
14:18:48 <enikanorov_> so it was item #2 for the code sprint IMO
14:18:53 <sbalukoff> enikanorov_: So we can't make assumptions about the scope of that first patch until we know whether option #2 as described by blogan in the e-mail he sent out earlier this week is a viable path for us to take, according to neutron core devs' opinion.
14:18:56 <blogan> enikanorov_: I think everyone agrees with the strategy for how to implement option #1, and if we have to move option #2 a new strategy will have to be made
14:19:16 <enikanorov_> blogan: yep
14:19:40 <enikanorov_> sbalukoff: still... i'm describing the way we can leverage existing code
14:19:41 <blogan> enikanorov: i just dont want to spend too much time on this if there is consensus on what should be done and there's is a bit of uncertainty based on anotehr meeting on monday
14:19:59 <enikanorov_> that's for sure
14:20:10 <jorgem> blogan: +1, hackathon items need to be addressed since we have little time
14:20:15 <enikanorov_> but still i'd like to present my vision of how it should be delivered
14:20:17 <sbalukoff> Personally, I would like to see us concentrate on those "problem integration areas" for Neutron which cause LBaaS and other advanced services to be so tightly integrated with NEutron.
14:20:24 <crc32> +1 for hachathon and barbican discussion
14:20:26 <jorgem> I want to make sure we get to them before the meeting ends
14:20:30 <sballe> blogan, Could we discuss his on the IRC neutron-lbaas on Monday after the neutron meeting?
14:20:31 <enikanorov_> if we end with brand new extension and plugin - fine!
14:21:03 <blogan> sballe: yes that would be a good time, though that will be at 5pm cst on monday.  I'll send an email out
14:21:12 <sballe> ok
14:21:23 <mestery> blogan sballe: May make sense Tuesday morning?
14:21:24 <german__> +1
14:21:25 <rm_work> is that *late* or *early* for enikanorov_ ? >_>
14:21:39 <enikanorov_> neutron meeting ends 2am for me
14:21:41 <mestery> Tuesday morning EDT will work better for enikanorov_ as well.
14:21:47 <enikanorov_> so it's a bit...
14:21:49 <rm_work> T_T
14:21:54 <enikanorov_> -_-
14:22:14 <blogan> okay, I'll still send an email out and then we can discuss tuesday morning
14:22:22 <sballe> blogan, +1
14:22:23 <blogan> so hackathon now?
14:22:30 <enikanorov_> yes
14:22:33 <blogan> great
14:22:46 <sballe> I am really worried that we start implementation before we have an agreement on the architecture so if we can outline tasks than can be done first such as interface clean-up, etc. then we can work on these until we have agreement on the arch. I agree that API/model cn be done first.
14:22:55 <mestery> jorgem: Are you guys all set to host all of us at RAX now?
14:23:05 <mestery> jorgem: As long as we haev a room and wifi we're good I think :)
14:23:09 <jorgem> we need to finalize the number of people that are coming
14:23:10 <sbalukoff> sballe: +1
14:23:23 <crc32> I''m attending.
14:23:24 <german__> yeah, big room = better
14:23:25 <jorgem> but no worries on getting a room
14:23:27 <jorgem> :)
14:23:31 <mestery> jorgem: perfect!
14:24:02 <jorgem> so...
14:24:13 <jorgem> I'd like to briefly touch on scope
14:24:20 <tmc3inphilly> can't wait to get my hack on
14:24:20 <sballe> I see a lot of folks are looking at: https://etherpad.openstack.org/p/1gsTm4GBdu
14:24:37 <sballe> feel free to add items that you feel are important
14:24:53 <jorgem> What functionality are we going to expose via the API by the time the freeze comes along? and...
14:25:03 <JulianCash> And https://etherpad.openstack.org/p/neutron-juno-lbaas-mid-cycle
14:25:12 <enikanorov_> jorgem: I'd suggest to set realistic goals
14:25:15 <jorgem> Does the reference implementation need to be in sync with that?
14:25:19 <mestery> #link https://etherpad.openstack.org/p/1gsTm4GBdu
14:25:23 <mestery> #link https://etherpad.openstack.org/p/neutron-juno-lbaas-mid-cycle
14:25:26 <sballe> I thougth we had agree on HA
14:25:30 <jorgem> enikanorov: Correct I'd like to try and define them now
14:25:57 <enikanorov_> realistic in my opinion is to expose new  resources of the new API
14:26:02 <rm_work> sballe: isn't HA more of a backend issue? I thought that's what we decided
14:26:03 <jorgem> I have HA. I don't think SSL will happen on the backend but should it be exposed on the front end?
14:26:13 <enikanorov_> and to have meaningful logic around that
14:26:44 <vivek-ebay> As I understand, we have following main LBaaS deliverables for Juno release:
14:26:44 <vivek-ebay> 1) New Rest API and object model
14:26:44 <vivek-ebay> 2) SSL APIs and integration with Barbican
14:26:46 <vivek-ebay> 3) HA Proxy scalable reference implementation (Octavia)
14:26:50 <blogan> if the custom backend does not support a feature that the API exposes should that still go in?
14:27:07 <jorgem> + blogan Thats what I'm getting at
14:27:07 <enikanorov_> having fully implemented (1) seems a success for me
14:27:08 <rm_work> vivek-ebay: +1
14:27:23 <crc32> I'm interested in topic 2.
14:27:23 <rm_work> that is what I recall as well
14:27:26 <vivek-ebay> what is the scope for hackathon at RAX? #3 ?
14:27:39 <sballe> I like the Juno feature list but think it is ambitous
14:27:42 <rm_work> I think #1 and MAYBE #2, honestly
14:28:03 <rm_work> (should be top priorities)
14:28:05 <hyakuhei> crc32: I'm interested in #2 also
14:28:08 <vivek-ebay> We are also interested in #1 and #2
14:28:11 <blogan> #3 will not be limited by a code freeze
14:28:19 <rm_work> we can work on #3 but on the side
14:28:20 <sballe> vivek-ebay, now we are back to my worry. We haven't agreed on an arch and on how to clean-up the interfaces and we start talking about implrmenting new features
14:28:21 <rm_work> yeah
14:28:25 <mestery> blogan: Correct!
14:28:35 <blogan> another top priority will be cleaning up the integration points
14:28:38 <vivek-ebay> sballe +1
14:28:59 <sbalukoff> #3 will be limited if we don't have clean interfaces to Neutron.
14:28:59 <mestery> sballe: The integration point cleanup is something we will discuss on day-1 at the Hackathon.
14:29:24 <evgenyf> crc32: topic 2) there is updated WIKI iwth all latest changes , please review it https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL
14:29:27 <sballe> realistically I see 1/ Clean-up interface 2/ model and APIs and maybe 3/Barbican integration
14:29:27 <VijayB_> I don't see why we should postpone 2) Is the reason that haproxy is still beta on ssl termination support?
14:29:34 <sbalukoff> mestery: It would be great to have an idea where those areas are *before* the hackathon so maybe we can spend some time at the hackaton working on them.
14:29:49 <rm_work> sballe: +1
14:29:52 <german__> +1 sbalukoff
14:30:04 <blogan> VijayB: I think it is because it needs to be implemented in the reference implemenation as well as the API
14:30:05 <JulianCash> +1
14:30:07 <german__> also we will be lost of people so we might split in teams tackling different things
14:30:08 <mestery> sbalukoff: +1, now that markmcclain is done traveling, I plan to work with him later this week to get a list of that down.
14:30:24 <mestery> german__: +1
14:30:39 <sballe> german__, +1
14:30:41 <rm_work> german__: +1
14:30:45 <blogan> can we all agree that cleaning up those interfaces is a top priority?
14:30:48 <sbalukoff> mestery: Thanks!
14:30:51 <jorgem> So #3 doesn't seem like a priority for hackathon since it isn't affected by the freeze
14:30:58 <crc32> evgenyf: Yes but our discussions with the barbican team has some implications on the behavior we are expecting. For 1 their is no schema for a cert and key just a generica container thats immutable.
14:30:58 <vivek-ebay> how about we host separate  hackathon for #1 and #2 in parallel to RAX hosting for #3 ?
14:31:03 <jorgem> blogan: +1 is a big one
14:31:03 <sbalukoff> jorgem: +1
14:31:08 <JulianCash> german__ +1
14:31:16 <enikanorov_> honestly folks i think that you need to find out those "integration points"
14:31:17 <jorgem> I'm trying to focus on freeze related items
14:31:18 <sballe> blogan, 100% agree that cleaning up interface is top priority
14:31:26 <sbalukoff> jorgem: Also, #3 is the most nebulous task, which tells me we aren't yet in enough agreement there to make a lot of forward progress.
14:31:26 <enikanorov_> or otherwise how are you going to write code for neutron?
14:31:59 <sballe> enikanorov, +100
14:32:03 <tmc3inphilly> wouldn't barbican integration take place in the driver?  or is there a desire to have it in LBaaS?
14:32:04 <sbalukoff> jorgem: Also, agreed, let's get the things done first that will be affected most by the code freeze.
14:32:14 <rm_work> tmc3inphilly: it's an API-level thing
14:32:35 <rm_work> needs to be exposed at the API so the user can provide barbican container IDs
14:32:41 <jorgem> 1) New Rest API and object model - My fear with this one is that certain items don't make it in and we have to wait several more cycles to expose functionality. It's easy to expose stuff via the API but it won't get accepted unless there is at least one working implementation of it right?
14:32:45 <german__> +1 em_work
14:32:46 <blogan> we have two separate conversations going on here, can we focus on one?
14:32:48 <german__> rm_work
14:32:58 <german__> blogan +1
14:33:03 <enikanorov_> jorgem: right
14:33:14 <enikanorov_> jorgem: but basic functionality is supported by haproxy
14:33:23 <rm_work> so, we'll still be updating the haproxy namespace driver during this
14:33:26 <enikanorov_> and it won't be too difficult to imlement it
14:33:28 <jorgem> enikanorov: So what are we agreeing on to expose? Plus this means coding in the current reference implementation
14:33:37 <enikanorov_> rm_work: correct, we have to
14:33:51 <enikanorov_> jorgem: loadbalancer and listeners
14:34:01 <rm_work> enikanorov_: yeah, sorry, i meant that rhetorically, i have no problem there :P
14:34:06 <enikanorov_> and limiting attribute change as possible
14:34:15 <jorgem> enikanorov: What about things such as SSL, L7, SNI, etc.?
14:34:45 <enikanorov_> jorgem: L7 is fine to work on once we have basic api/obj model in the master
14:34:54 <crc32> evgenyf: Also we need to discuss the exected behavior for when users update their keys in barbican should barbican use an event system to alert the Lbaas service a key or cert has changed or leave it to the user.
14:35:07 <enikanorov_> ssl - probably too, but without eact merging expectations
14:35:10 <crc32> jorgem: SNI is out of scope for Juno I believe as well as rencryption.
14:35:21 <enikanorov_> eact=exact
14:35:21 <rm_work> crc32: +1
14:35:22 <jorgem> All of us said velocity was a key thing but if features are exposed via the API then that kind of defeats the purpose somewhat
14:35:28 <crc32> Jorgem: But ssl termination or offloading is still on for juno.
14:35:51 <enikanorov_> jorgem: and features are not until they're implemented on the backend
14:36:05 <german__> let's have "stretch" goals and use the hackathon to hammer them out?
14:36:06 <evgenyf> crc32: I will add this point to the doc.
14:36:18 <enikanorov_> exposing loadbalancer and listeners is simple thing which doesn't require much work on driver side
14:36:27 <jorgem> I just see a disconnect from the work octavia will be able to accomplish if it is limited by API functionality not being exposed
14:36:47 <jorgem> Does everyone see my concern?
14:36:47 <enikanorov_> jorgem: that's why i've suggested to set realistic goals
14:37:04 <enikanorov_> we may be able to produce large amounts of working code
14:37:18 <sbalukoff> jorgem: When you say "limited by API finctionality not being exposed' are you talking about Neutron API?
14:37:19 <enikanorov_> but realistically, having basic model in Juno working - that will be a good deal
14:37:31 <jorgem> sbalukoff: Yes, Neutron LBaaS API
14:37:44 <german__> we still can have an Octavia API?
14:37:48 <jorgem> I understand scope needs to be limited, at least for the backend
14:38:09 <enikanorov_> may i raise reservation against Octavia name?
14:38:10 <sbalukoff> jorgem: Yes, I agree. But I would say that not having a clean interface to work with in Neutron would limit Octavia even more than that.
14:38:15 <JulianCash> https://etherpad.openstack.org/p/LBaaS_project_name_vote
14:38:16 <enikanorov_> (sorry)
14:38:26 <crc32> evengenyf: I wanted to sync up with you rm_you and sballe after this meeeting about the barbican schema we intend to use for Certs as well as if we intend to use the event engine to communicate changes back to the lbaas servicve.
14:38:38 <enikanorov_> that's my car model name...
14:38:41 <crc32> rm_work I mean sorry.
14:38:45 <jorgem> I want to focus on getting as much functionality exposed (while cleaning up interfaces) so that Octavia can move at the speed it needs to.
14:38:46 <enikanorov_> ii want it to be a car :_
14:38:48 <JulianCash> Suggesting we pick a name via: https://etherpad.openstack.org/p/LBaaS_project_name_vote
14:38:48 <enikanorov_> :)
14:39:08 <JulianCash> Feel free to add names that you think of!  Add names BEFORE 6/8/2014 7:00am utc (midnight pst).   Then people can put their name next to project names they like (to vote).  Vote BEFORE 6/12/2014 7:00am utc The PTL/TC/Core folks will likely do the final picking and vote tallying.
14:39:12 <vjay2> Hi Everyone, Was on vacation and just joined the meeting. Still catching up on stuff.
14:39:12 <sballe> crc32, please include hyakuhei
14:39:18 <mestery> jorgem: +1 to that
14:39:23 <vjay2> Will someone kind enough to clarify? Is this cleaning of (neutron) interface meant to make LBaaS service independent? Meaning, whatever LBaaS requires of Neutron will be exposted as an API by Neutron?
14:39:46 <sballe> jorgem, +1
14:39:47 <enikanorov_> jorgem: how can we expose API without implementation?
14:39:54 <jorgem> sbalukoff: Thus I feel like we should put more focus on Neutron LBaaS before getting knee deep into octavia because of the time sensitivity.
14:40:00 <enikanorov_> i think the perception of core team is opposite
14:40:07 <rm_work> there's TWO names here -- Octavia was for the backend impl thing we were discussing, not for the new LBaaS API Project in Openstack
14:40:09 <sbalukoff> jorgem: Agreed.
14:40:10 <enikanorov_> as they tend to move from 'experimental status'
14:40:11 <blogan> vjay2: it is meant to allow lbaas to be independent yes, that independence will not happen right away
14:40:36 <jorgem> enikanorov: It doesn't seem like the community want to. On way is method not implemented but I don't think the community likes that
14:40:38 <enikanorov_> if you have an API that is not actually working - that's just not good
14:40:39 <sballe> jorgem, 100% agree. If we get the claeen-up done we can parallellise the effort around the features inOctavia
14:40:40 <JulianCash> Before we change off of name topic, are folks okay with picking the name via a vote process, as specified here: https://etherpad.openstack.org/p/LBaaS_project_name_vote
14:40:45 <vivek-ebay> rm_work: +1, its very confusing folks using it interchangably
14:40:56 <rm_work> vivek-ebay: yes T_T
14:41:00 <crc32> sballe: Are you not going to be apart of this discussion?
14:41:21 <enikanorov_> jorgem: are you going to participate monday neutron meeting?
14:41:29 <jorgem> enikanorov: yes
14:41:31 <evgenyf> crc32: I'm available after this meeting
14:41:41 <sballe> I can't have some otehr meetings. please invite german__ and hyakuhei (he is our security expert and work on barbican as well)
14:41:42 <vjay2> blogan: thanks for the reply. Yes I understand. we are doing the ground work now.
14:41:57 <enikanorov_> then please raise this again. Because what I just said is not my fantasy, you know :)
14:42:23 <jorgem> another important item related to freeze...
14:42:25 <blogan> I think implementing the features in the namespace driver will not be so hard
14:42:33 <jorgem> Is barbican affected by the freeze?
14:42:41 <crc32> hyakuhei and german_ rm_work and evengyf can you meet up in neutron-lbaas after this meeting?
14:42:44 <jorgem> Since it is in incubation?
14:42:49 <rm_work> crc32: yes
14:43:00 <jorgem> because if it is then we also need to focus on integrating with it too
14:43:07 <evgenyf> crc32: yes
14:43:08 <sbalukoff> jorgem: +1
14:43:12 <jorgem> to setup the foundation for SSL
14:43:36 <german__> crc32 irc?
14:43:41 <jorgem> mestery: Do you know if the freeze affects incubated projects?
14:43:55 <mestery> jorgem: For incubated projects, it's up to their discretion if they follow it or not.
14:43:55 <hyakuhei> crc32: I can for maybe 20 minutes or so yes
14:43:58 <rm_work> german__: yeah, just over in #neutron-lbaas
14:44:01 <sballe> jorgem, Are you talking abotu code freeze?
14:44:04 <german__> ok, will bethere
14:44:11 <jorgem> sballe: yes
14:44:22 <crc32> german__: yes freenode #neutron-lbaas or if you have a better place we can meet there.
14:44:32 <jorgem> mestery: Okay good but I'm going to error on the side that they will freeze
14:44:54 <crc32> brb
14:44:58 <sballe> jorgem, I think we sj=hould follow the openstack releases and freeze.
14:45:00 <jorgem> mestery: At least initially, which means effort needs to be put into integrating with Barbican
14:45:13 <rm_work> minimum necessary changes in Barbican should hopefully be small, so should not be a big deal anyway
14:45:15 <mestery> jorgem: Agreed 100%
14:45:20 <rm_work> but we will discuss
14:45:36 <s3wong> so we still haven't gotten to talking about the hackathon?
14:45:56 <rm_work> s3wong: i think we just finished outlining priorities for it?
14:45:57 <german__> we have an etherpad
14:45:58 <jorgem> s3wong: I'm trying to define scope of it
14:46:10 <sballe> s3wong, do you agree with waht's is inthe tehrpad?
14:46:11 <jorgem> s3wong: So that we have a goal
14:46:12 <blogan> ok so do we have a priority list for the hackathon: 1) clean integration points 2) api object model refactor 3) L7 and SSL features in API and namepsace driver
14:46:33 <mestery> blogan: We should put that on sballe's etherpad.
14:46:35 <sballe> blogan, L7 is now in there.
14:46:49 <sbalukoff> blogan: I like that list. Also, we can potentially work on those three things in parallel
14:46:50 <jorgem> blogan: Goal should also be to expose as much functionality as possible.
14:46:53 <sballe> I just put it in but wthout the L7
14:46:56 <german__> also we can work in parallel/multiple teams...
14:47:00 <jorgem> blogan: which means reference impl work
14:47:22 <s3wong> sballe: I am looking at your etherpad. So I am from the serviceVM and adv-service service insertion subteams, and would be here to help if the LBaaS subteam has further requirements on integration points
14:47:26 <mestery> sbalukoff: +1
14:47:37 <sballe> s3wong, Perfect
14:47:48 <mestery> s3wong: Are you coming to SAT in 2 weeks? :)
14:48:14 <s3wong> mestery: if needed, I will. I got mgmt approval on travel budget already
14:48:20 <sbalukoff> s3wong: Ooh! Yes, I'd like to hear what your main concerns are for integrations points (but that can happen offline, after this meeting.)
14:48:22 <mestery> s3wong: sweet!
14:48:38 <sballe> s3wong, it would be great if you can come
14:48:44 <s3wong> mestery: so I guess I will then :-)
14:48:51 <mestery> s3wong: nice and thanks!
14:48:53 <german__> neat
14:48:54 <sballe> s3wong, +1
14:49:03 <blogan> s3wong: awesome, we could use your knowledge and expertise
14:49:03 <vivek-ebay> If there are more folks in bay area interested , we can host hackathon at ebay campus too for subteams to work in parallel on other items.
14:49:32 <sballe> sballe, and HP is happy to host the enxt one in Seattle
14:49:33 <sbalukoff> vivek-ebay: That would be really cool if y'all do that.
14:49:36 <blogan> vivek-ebay: i think this is the only date in Juno that works for mestery and markmcclain
14:49:52 <mestery> blogan vivek-ebay: Maybe a parallel hackathon at ebay during the same time?
14:49:58 <mestery> vivek-ebay: that woudl let s3wong avoid travel.
14:50:00 <mestery> vivek-ebay: I like that idea!
14:50:05 <vivek-ebay> yes, same time
14:50:08 <JulianCash> FYI, timecheck.  10 minutes left in this meeting.
14:50:09 <mestery> vivek-ebay: +1 to that idea!
14:50:09 <sbalukoff> Seattle also works well for Blue Box, since we're based there, too.
14:50:12 <blogan> ah same time
14:50:14 <mestery> s3wong: would that work for you?
14:50:29 <mestery> I'd like to keep the core folks at SAT though if possible
14:50:33 <sballe> ok I am worried now. About "same time"
14:50:35 <mestery> F2F is important for this initla one :)
14:50:37 <s3wong> mestery: yes, that would also be good
14:50:41 <jorgem> sbalukoff: Seattle works for me too since I like traveling there :)
14:50:42 <vivek-ebay> I will work on getting logistics. Should not be a problem.
14:50:47 <JulianCash> <B Seattle
14:50:49 <sballe> I really think taht we need to be inthe same room for this first one
14:50:59 <s3wong> vivek-ebay: let us know (from ML) when and where the meeting is
14:51:01 <mestery> sballe: +1, at least for most folks
14:51:08 <vivek-ebay> Address would be: 2211 N First St, San Jose, CA 95131
14:51:26 <sballe> mestery, +1 We will set the direction and do all the "serial" work at this meeting.
14:51:31 <mestery> Time check: 9 minutes left.
14:51:37 <rm_work> so, next hackathon -- seattle! :P
14:51:37 <sballe> We can do parallel coding camps later
14:51:38 <mestery> sballe: Agreed
14:51:38 <jorgem> so I wanted to touch on one last agenda item
14:51:39 <s3wong> mestery: we need to make sure video link and virtual white board is in place for collaboration
14:51:48 <blogan> sballe: +1 but not everyone will be able to make it and if they are in the same area they shoudl eb able to join in and we can do a video call
14:51:53 <sbalukoff> sballe: +1
14:52:02 <sbalukoff> blogan: +1
14:52:04 <mestery> blogan sballe: +1, Google Hangouts work marginally ok
14:52:27 <JulianCash> +1 s3wong
14:52:37 <sballe> s3wong, +1
14:52:39 <aburaschi> Sorry to go back a few lines but... what are the certainties of Barbican becoming core for Juno? Or that is off topic and it is ok to integrate with incubation project right now, as old API will still be usable?
14:52:39 <jorgem> I'll probably move the barbican agenda item to the ML
14:52:59 <rm_work> aburaschi: i believe it was decided that it was acceptable
14:53:05 <jorgem> aburaschi: Barbican integration is definitely within scope
14:53:21 <jorgem> the lbaas community has aggreed to that
14:53:22 <aburaschi> jorgem, rm_work, thanks, great.
14:53:52 <jorgem> We met with the Rackspace Barbican folks yesterday and currently see two options
14:54:05 <jorgem> we are open to more options
14:54:21 <jorgem> Here are the two options:
14:54:21 <jorgem> 1.	Create an eventing system for Barbican that Neutron LBaaS (and other services) consumes to identify when to update/delete updated secrets from Barbican. For those that aren't up to date with the Neutron LBaaS API Revision, the project/tenant/user provides a secret id when enabling SSL/TLS functionality.
14:54:22 <jorgem> ◦	Example: If a user makes a change to a secret in Barbican then Neutron LBaaS will see an event and take the appropriate action.
14:54:22 <jorgem> 2.	Push orchestration decisions to API users. This idea comes with two assumptions. The first assumption is that most providers' customers use the cloud via a GUI, which in turn can handle any orchestration decisions that need to be made. The second assumption is that power API users are savvy and can handle their decisions as well. Using this method requires services, such as LBaaS, to "register" in the form of metadata to a barb
14:54:22 <jorgem> ◦	Example: If a user makes a change to a secret the GUI can see which services are registered and opt to warn the user of consequences. Power users can look at the registered services and make decisions how they see fit.
14:54:28 <jorgem> sorry for the splat :)
14:54:34 <aburaschi> hehe
14:54:57 <crc32> aburaschi: Yes barbican was expected in juno.
14:55:06 <jorgem> In the interest of time though I will start a thread on the ML with these options
14:55:14 <german__> Both are fantastic options... and I was already happy that barbican can store certs in containers...
14:55:15 <sbalukoff> jorgem: Are we going to try to discuss that now with 5 minutes left in this meeting?
14:55:20 <JulianCash> Anybody spare a +1 or -1 on this name list?  Does this idea/plan seem okay to you?  Aiming for the name voting before hackathon, but it could be changed to at the hackathon so folks could talk aobut it in person.   https://etherpad.openstack.org/p/LBaaS_project_name_vote
14:55:22 <jorgem> we can a little if you want
14:55:27 <jorgem> its the last agenda items
14:55:54 <sbalukoff> JulainCash: I think there's some confusion as to what we're naming:  The new LBaaS project, or the reference implementation for this project?
14:55:58 <rm_work> jorgem: we are meeting in #neutron-lbaas about this after this meeting as well
14:56:08 <jorgem> I think the main thing to discuss are the pros and cons of each
14:56:14 <jorgem> and decide on a direction
14:56:20 <mestery> jorgem: +1
14:56:23 <jorgem> either way will work.
14:56:50 <jorgem> However, if other teams have ideas I would love to hear them
14:57:01 <sbalukoff> JulianCash: I've been calling the reference implementation we'll be creating "Octavia" but we have yet to come up with a name for what the not-Neutron LBaaS project should be.
14:57:05 <aburaschi> I will check the list in detail after the meeting, JulianCash. I like the proposals.
14:57:12 <JulianCash> Thanks sbalukoff.  In my mind "the new LBaaS project".
14:57:23 <sbalukoff> JulianCash: But it should probably not have the same name, to avoid confusion.
14:57:31 <blogan> I think it is a bit early to even spend time on the name of the lbaas project
14:57:37 <hyakuhei> /win 8
14:58:04 <blogan> I'm interested in it too but naming things can devolve into hours of debates
14:58:15 <aburaschi> blogan +1
14:58:19 <sballe> blogan, +1
14:58:23 <jorgem> blogan: +1 new lbaas project focus comes after hackathon
14:58:24 <sbalukoff> blogan: +1
14:58:27 <crc32> and meeting spamming to it seems.
14:58:35 <mestery> blogan: +1
14:58:53 <mestery> < 2 minutes left
14:59:00 <mestery> Anything to wrapup here?
14:59:10 <jorgem> yes
14:59:12 <jorgem> one last thing
14:59:35 <jorgem> Is it possible for teams to frequently let others know what work you are focusing on?
14:59:39 <enikanorov_> #action team to follow up on neutron meeting about the implementation strategy
14:59:46 <jorgem> via ML?
14:59:51 <mestery> jorgem: Yes! That's a good idea
14:59:52 <jorgem> Just to get visibility on things
15:00:04 <sballe> jorgem, that is part of the porxess I would like to discuss the first day of the hackathon
15:00:10 <sballe> s/process
15:00:12 <aburaschi> jorgem +1!
15:00:18 <jorgem> sballe: ok good!
15:00:42 <jorgem> just to address the elephant in the room :)
15:00:43 <enikanorov_> ok, thanks everyone
15:00:46 <sbalukoff> jorgem: +1, but I would like to see what you're looking for in particular.
15:00:47 <crc32> jorgem: Yea thats what I was hoping the wednsday meetins were going to be for but ...
15:00:47 <s3wong> thanks, guys
15:00:55 <enikanorov_> #endmeeting