14:01:38 <enikanorov_> #startmeeting neutron lbaas
14:01:43 <openstack> Meeting started Thu Apr 24 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:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:47 <openstack> The meeting name has been set to 'neutron_lbaas'
14:01:55 <rm_work> hey :)
14:02:21 <sballe> just a heads up that I will not be here next week since I am goign on vacation.
14:02:26 <blogan> hello
14:02:32 <german_> hi
14:02:39 <enikanorov_> the agenda for today is to discuss the steps we need to take in order to make a progress
14:02:41 <mestery> sballe: Enjoy the time off!
14:02:43 <enikanorov_> sballe: good to know
14:02:43 <rm_work> sballe: have a good one :P
14:02:50 <berlin> hi
14:02:58 <sballe> thanks Going to Paris :-)
14:02:59 <enikanorov_> so far we had several competing API/object model proposals
14:03:27 <jorgem> enikanorov: Can we also figure out how we are going to organize at the summit sometime in the near future? Perhaps overML?
14:03:49 <mestery> Just FYI: It's looking like LBaaS will end up with 2 40 minute sessions.
14:03:57 <mestery> I'd hope we can organize as a team what we want to accomplish in those sessions.
14:03:57 <jorgem> awesome
14:03:57 <enikanorov_> jorgem: right, let's discuss the summit at the end of the meeting
14:04:15 <enikanorov_> mestery: cool!
14:04:35 <enikanorov_> so, let's get back on API discussion as I'd like to end it with some action items
14:04:55 <enikanorov_> currently we have two competing approaches, one is existing 'granular' API
14:05:01 <enikanorov_> another is 'single-call' API
14:05:13 <vivek-ebay> why can't they both co-exist ?
14:05:22 <sbalukoff> Well, technically the one I proposed is both.
14:05:28 <enikanorov_> on 'granular API' which is an evolution of existing API I'v filed a blueprint to neutron-specs
14:05:35 <enikanorov_> vivek-ebay: hold on :)
14:05:49 <jorgem> enikanorov: "the single call" also allows granularity
14:05:55 <enikanorov_> #link https://review.openstack.org/#/c/89903/
14:05:56 <rm_work> i think both are both
14:06:06 <sbalukoff> rm_work: True.
14:06:25 <mestery> So for the single call API, it just makes use of the more granular APIs underneath? Is that the case?
14:06:27 <enikanorov_> yes, so the API/obj model proposal in the link above is the API that we'll be focusing on
14:06:44 <enikanorov_> the question would be how to better converge with single-call approach
14:07:04 <rm_work> mestery: yes and no? there is some thought that it should actually speak directly with the driver to do a single call, but I am not 100% sure we need to go that deep
14:07:09 <jorgem> mestery: Our proposal allows for multiple API calls if wanted. However, provisioning can occur with a single call as well.
14:07:12 <enikanorov_> btw, by saying 'we' i mean samuelbercovici, me, sbalukoff
14:07:19 <jorgem> mestery: The choice is left up to the user
14:07:38 <mestery> Thanks for the clarification folks!
14:07:53 <jorgem> enikanorov: And by "our"/"we" I mean the Rackspace LBaaS team. Good to point out
14:08:18 <enikanorov_> so for the rest of the subteam, who would like to see single-call approach i suggest to come up with the blueprint
14:08:38 <enikanorov_> that actually explains the approach based on the object model proposed in ^^^
14:09:19 <enikanorov_> refering to the wiki with obj model description, we decided to go with 'vip-centric' approach, where the root object is VIP
14:09:24 <jorgem> To give an update, blogan sent out an email with some docs. What we are now doing is showing how the API proposal actually works with the use cases lined out in https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit#
14:09:30 <enikanorov_> and it plays loadbalancer role
14:09:40 <jorgem> using both a single call and multiple calls
14:09:59 <blogan> enikanorov: are you saying you've already decided on going with the vip centric approach?
14:10:03 <mestery> jorgem: That's on my list of reading material today in fact. :)
14:10:08 <sbalukoff> This is news to me.
14:10:11 <sballe> HP's current implementation of LBaaS uses the Atlas API so "we" like Rackspace's proposal and have decided to back that up instead of doing yet another proposal
14:10:21 <german_> +1
14:10:33 <enikanorov_> blogan: that was a consensus solution with those who originally would like to see granular api
14:10:57 <rm_work> err wait, was there a vote already that I missed? :/
14:11:03 <enikanorov_> sballe: that's fine, we need to come up with a plan on hw we can converge
14:11:05 <blogan> enikanorov: so what was the point of us doing a proposal?
14:11:08 <TrevorV> sbalukoff: what is news to you?  What jorgem was doing or what enikanorov_ said about vip-centric?
14:11:11 <sballe> I missed it too
14:11:13 <jorgem> A work-in-progress of how the use cases fit with our API is located here
14:11:15 <jorgem> #link https://drive.google.com/folderview?id=0B_x8_4x6DRLad1NZMjgyVFhqakU&usp=sharing
14:11:40 <enikanorov_> there's no vote, we need to account for everyone's need
14:11:43 <jorgem> Again, this is a WIP. I'm planning on making some diagrams for people that are visual learners
14:11:54 <sbalukoff> TrevorV It feels like a decision has been made. I thought we were still in the "let's talk about pros and cons" stage.
14:11:58 <sballe> enikanorov, I understand. I guess if we had to vote I know what proposal I would vote for. That's all I am saying
14:12:13 <enikanorov_> one of the important needs is backward compatibility and support for existing customers
14:12:15 <rm_work> sbalukoff: i also thought hat
14:12:19 <rm_work> *that
14:12:25 * rm_work though sometimes also thinks about hats
14:12:42 <blogan> enikanorov: i thought we already decided that backwards compatibility is not needed anymore and starting an API from scratch was what we were going to do going forward
14:12:50 <enikanorov_> sballe: yes, but i'm against choosing the only one. we can have both
14:12:52 <sballe> blogan, +1
14:12:53 <TrevorV> enikanorov_:  you're saying there is no reason to entertain object models that aren't vip-centric?
14:12:59 <enikanorov_> one option has been there since the beginning
14:13:27 <sballe> enikanorov, Ok but let's amke sure we don't only the vip centric one.
14:13:48 <jorgem> enikanorov: Mark McClain had suggested a new approach to the API. Perhaps allowing to run both side by side for a while is a meet in the middle compromise?
14:14:14 <mestery> jorgem: There's some overhead there, but that is one way to deprecate the older API.
14:14:32 <enikanorov_> sballe: on the object model side - it's pretty much fixed. on API side - there are options. so I actually would like to see how single-call approach fits in along with the proposed API/obj model
14:14:33 <sballe> jorgem, I like thta idea
14:14:33 <mestery> jorgem: We would have to support the old API for at least one more cycle.
14:14:58 <rm_work> yeah, jorgem +1
14:14:59 <enikanorov_> jorgem: side by side is what i'm suggesting as well. but we can't have two different object models
14:15:18 <enikanorov_> granular API is to stay.
14:15:37 <sbalukoff> That's true. But maybe it makes sense to have a different object model if there's a good reason for it.
14:15:41 <jorgem> enikanorov: K, I'm just trying to figure out how to get everyone's needs in.
14:16:00 <sbalukoff> jorgem: Have y'all created an object model diagram that works with your proposed API?
14:16:14 <blogan> if a new API is going to be made, trying to jam it into the shape of the current object model is the wrong way to go
14:16:17 <jorgem> sbalukoff: We are working on it. There is a WIP in the link I sent
14:16:23 <sballe> sbalukoff, I agree and I thougth we were revising the object model as well
14:16:36 <enikanorov_> jorgem: I think the task would be just to come up with a 'single-call' API for the resources that are proposed in the blueprint i've filed
14:16:41 <german_> snd my underdtsnding was the API would drive the object model
14:16:50 <sballe> german_, +1
14:16:51 <enikanorov_> it is not very different from the API that you have
14:16:55 <blogan> german_: that is usually the case
14:17:24 <jorgem> enikanorov: Could you link the bp?
14:17:40 <enikanorov_> https://review.openstack.org/#/c/89903/
14:17:48 <jorgem> enikanorov: thanks
14:17:56 <enikanorov_> folks, we're not doing it from scratch
14:18:28 <enikanorov_> obj model evolves, we're fixing the problems with it and with the API. it's fine to have a single call addition
14:18:39 <enikanorov_> but it's not fine to rewrite everything
14:18:58 <mestery> Do folks have serious concerns with the object model as proposed? I need to look at enikanorov_'s BP yet myself. Just curious.
14:19:14 <blogan> the current object model was derived from the current API. the current API is not liked by many, why would we try to do a new API and jam that into the shape of the current object model?
14:19:26 <TrevorV> blogan: +1
14:19:30 <german_> +1
14:19:33 <sbalukoff> Heh! To be honest, I'm trying to see where in the bp the object model diagram or other description is.  (I've not seen this bp before today.)
14:19:38 <samuelbercovici> the proposed model is in essence splitting the v1.0 VIP to VIP-->listeners
14:19:39 <TrevorV> enikanorov_: who decided the lack of a new Object Model?
14:19:57 <TrevorV> enikanorov_: why is there no replacing it?
14:19:59 <rm_work> I had some concerns, but I need to see if enikanorov_ is proposing any fixes for the specific things I had problems with, or if the objectmodel is essentially unchanged
14:20:02 <enikanorov_> sbalukoff: i can't put pictures in the text format. it refers obj model discussion
14:20:27 <mestery> enikanorov_: asciiflow.com or such. :)
14:20:32 <samuelbercovici> sbalukoff: we are working in prallel to have an graphivsl object model
14:20:33 <enikanorov_> sbalukoff: and yes, it was put out there just yesterday
14:20:38 <samuelbercovici> we will add it to the wiki
14:20:45 <blogan> mestery: i have concerns if we're keeping the same object model and we have to work around it
14:20:53 <enikanorov_> blogan: we're not
14:20:58 <sbalukoff> blogan: +1
14:21:02 <mestery> blogan: Understood.
14:21:13 <enikanorov_> we're not keepng existing object model
14:21:25 <blogan> enikanorov: but you've already decided on an object model
14:21:26 <ptoohill> ?
14:21:29 <enikanorov_> obejct model is extended to account for every case we have planned
14:21:37 <sbalukoff> It seems to me an API overhaul and object model overhaul go hand-in-hand. The question is: Are the use cases satisfied?
14:21:52 <samuelbercovici> sbalukoff: yes
14:21:57 <ptoohill> look the link jorgem provided
14:22:03 <jorgem> sbalukoff: Correct which is what I'm trying to show with the documents we are preparing
14:22:06 <TrevorV> sbalukoff: in the object model we've been working on the use-cases are a priority to satisfy.
14:22:13 * mestery admits he needs to read the use case documents and enikanorov_'s BP to see how the gaps were closed.
14:22:22 <rm_work> no use arguing about it right now, we need some time to go and actually review enikanorov_'s proposed object model in depth and verify that it works for us… but we shouldn't consider this "closed"
14:22:38 <sballe> rm_work, Agreed
14:22:43 <mestery> rm_work: +1
14:22:45 <sbalukoff> Sweet! Well... I've certainly not had time yet to add the use cases I was able to think of this last week in creating the API proposal that I made.
14:22:49 <enikanorov_> the proposed object model was there for months: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion
14:22:55 <enikanorov_> that's a VIP-centric approach
14:22:56 <sbalukoff> Sorry, I didn't know that would become a priority.
14:23:08 <blogan> yeah all I am saying is that decided in the object model shouldn't be changed drastically without everyone agreeing causes concern
14:23:11 <jorgem> enikanorov: Can you do a similar exercise that we are doing and actually document workflows on how your proposal fits with the use cases we have identified thus far?
14:23:18 <rm_work> enikanorov_: that proposed object model was one of many, including the one we were going to propose, we weren't aware that it wasn't up for debate
14:23:41 <sbalukoff> rm_work: +1
14:23:49 <german_> let's pick an API first and then revisitit the object model
14:23:58 <enikanorov_> rm_work: we've discussed these proposals for several meetings in line
14:24:07 <blogan> and now that everyone has been caught off guard on this and thought it was up for debate, why is not now up for debate?
14:24:08 <enikanorov_> and vip-centric approach was one of two primary
14:24:18 <jorgem> If everyone documents their proposals in a similar fashion I think we can then start to talk about the merits of them in a more structured fashion.
14:24:21 <rm_work> enikanorov_: yes, and the discussion has been centered around picking a good API design, and then building an obj model from it
14:24:24 <enikanorov_> along with 'loadbalancer' which is quite similar
14:24:37 <sbalukoff> jorgem: +1
14:24:58 <sballe> rm_work, +1
14:25:13 <german_> jorgem, rm_work +1
14:25:17 <mestery> The new process for Neutron BPs is to submit things into the gerrit neutron-specs repository.
14:25:28 <mestery> Nothing is set in stone until it's approved, so we can all comment on the object model in gerrit.
14:25:35 <mestery> It may be best to drive initial comments there in fact.
14:25:39 <rm_work> actually, could I ask why you have the authority to *make* this decision? I don't mean to be rude, but as a newcomer to this sort of system, I thought there was a PTL (now mestery) and… ??
14:25:41 <samuelbercovici> mestery +1
14:25:48 <rm_work> mestery: +1
14:25:54 <blogan> mestery: thanks for the information, I did not know this
14:25:56 <mestery> If people feel it's off base for their concerns, then perhaps we need to have a broader discussion.
14:26:00 <ptoohill> +1 rm_work i had the same question
14:26:06 <mestery> #link https://wiki.openstack.org/wiki/Blueprints#Neutron
14:26:32 <enikanorov_> good question on authority
14:26:43 <mestery> rm_work: It's ideal to drive consensus on gerrit, ML, and IRC. Hopefully we can do this going forward.
14:26:59 <enikanorov_> i'm accouting for opinions of the folks who already actually committed fopr the project
14:27:11 <rm_work> enikanorov_: and tallying a vote in your head?
14:27:13 <mestery> I love the passion from all the LBaaS participants! You folks have generated so many documents I'm buried catching up. :)
14:27:16 <enikanorov_> and also we try to account for everyone else's needs
14:27:23 <TrevorV> enikanorov_: are you talking about the original API or this new API we've been discussing creating?
14:27:56 <samuelbercovici> enikanorov_: +1
14:28:09 <enikanorov_> rm_work: my personal opinion that 'democracy' isn't working well in a group of 20 people and several competing proposals
14:28:10 <mestery> I also want to point out I am very happy that all the operators/providers are active in this sub-team. This is a good thing!
14:28:24 <enikanorov_> the API change was discussed long before 1.5 months ago
14:28:26 <rm_work> enikanorov_: well, we haven't ever had a "vote" so I wouldn't discount it yet <_<
14:28:37 <enikanorov_> so there are both implementations and decisions made by many
14:28:44 <sbalukoff> enikanorov_: Discussed but not decided upon
14:29:00 <enikanorov_> sbalukoff: because there was not an agreement, until recently
14:29:02 <mestery> Folks: Gerrit is where we can vote now. You all have +1/-1 authority there. :)
14:29:12 <blogan> mestery: we're excited about being a part of this and hope that we can improve the current product
14:29:25 <german_> same here
14:29:36 <mestery> I appreciate enikanorov_ pushing out a spec review in the new process. I think we should vote there, and iterate and improve things in gerrit.
14:29:41 <mestery> Thoughts?
14:29:58 <german_> let's work through the other documents first
14:30:04 <enikanorov_> yeah, basically the new process has been made specifically for that
14:30:22 <sbalukoff> enikanorov_: True, but should they be excluded because they just got involved recently? I know we have to move forward, but I also don't like excluding late-comers with valuable things to add.
14:30:33 <sballe> mestery, just like blogan we are existing about making this a better service as well
14:30:38 <mestery> german_: You mean use cases?
14:30:41 <ptoohill> +1 sbalukoff
14:30:43 <enikanorov_> sbalukoff: i'm not trying to exclude nobody!
14:30:45 <sbalukoff> For example, jorgem's idea to create a google spreadsheet listing actual usage of load balancing services and features was brilliant.
14:30:46 <rm_work> that's a good point. we can have a vote on gerrit, if we would like.
14:30:49 <enikanorov_> that's the last thing i'd do
14:30:58 <sbalukoff> I think we got a lot of valuable new information from that.
14:30:59 <blogan> mestery: a lot of us operators are new and may not have votes, but we're very committed to this project and if we do not like the BP then because we have a lack of votes we don't have much power
14:31:03 <enikanorov_> once again, we have two quite different competing approches
14:31:10 <enikanorov_> i'd like to see them developing side by side
14:31:18 <enikanorov_> not deciding between them
14:31:22 <sballe> blogan, +1 same with us
14:31:37 <samuelbercovici> enikanorov_, +1
14:31:44 <enikanorov_> the new approach has it's constraints - we can't rewrite everything from scratch, that needs to be understood
14:31:55 <blogan> enikanorov: why not?
14:31:59 <german_> +1
14:32:05 <sballe> enikanorov, Why not? If we don;t like it
14:32:08 <TrevorV> enikanorov_: exactly, what stops us from rewriting lbaas 2.0?
14:32:14 <sballe> blogan, you beat me to it ;-)
14:32:21 <enikanorov_> well.. saying with your words
14:32:28 <enikanorov_> because we don't like to rewrite it
14:32:35 <sbalukoff> enikanorov_: If we don't meet people's needs without rewriting everything from scratch, then they're going to do that themselves anyway.
14:32:37 <jorgem> At the end of the day, if we get all requirements in everyone should be happy right?
14:32:46 <mestery> jorgem: +1000
14:32:51 <sbalukoff> Which is fine, if they're willing to put forth the work.
14:32:52 <samuelbercovici> blogan: there is alraedy a large amount of work in there which is not just the API
14:32:54 <rm_work> enikanorov_: correction, *you* don't like to rewrite it :P
14:32:56 <enikanorov_> jorgem: yep
14:32:59 <rm_work> we're happy to :)
14:33:05 <sbalukoff> jorgem: Yep!
14:33:11 <sballe> enikanorov, yeah but we cannot duck-tape stuff. that will never give us the rigth product
14:33:15 <blogan> jorgem: yes i agree but its concerning that decisions are being made because they were made prior to all this new interest in the product
14:33:34 <german_> and if the current code doersn't meet requirements it has to chnage
14:33:46 <enikanorov_> i'd not call evolution a duct-taping
14:34:06 <sballe> enikanorov, yeah but if the foundation isn't right the evolution won;t be
14:34:15 <german_> +1
14:34:16 <sbalukoff> sballe: +1
14:34:24 <rm_work> sballe: +1
14:34:25 <jorgem> sballe: You have a good point. A lot of new requirements have come in which is why we are trying to start from scratch. enikanorov, the project as it is currently does not even address a lot of the operator requirements
14:34:29 <enikanorov_> may be it make sense to talk after we see some committed patches from you so you taste yourself what it takes to actually contribute :)
14:34:38 <blogan> evolving from something that had a lot of problems is not the right approach
14:34:39 <mestery> I think we're all in agreement we want to make things better in LBaaS.
14:34:40 <enikanorov_> before suggesting to rewrite everything :)
14:34:53 <jorgem> enikanorov: which I guess is why we have been proposing things from scratch
14:34:55 <enikanorov_> sballe: we're fixing foundation
14:35:06 <enikanorov_> sballe: that's the purpose of the BP
14:35:35 <mestery> How about if we all post comments on enikanorov_'s BP in gerrit.
14:35:39 <jorgem> blogan: Didn't you just code up an example?
14:35:52 <mestery> It's even possible for people to pull it down and push a new rev with changes as well, enikanorov_, would you be ok with that?
14:35:58 <enikanorov_> 'lots of problems' is just saying
14:36:08 <TrevorV> mestery: Everyone is speaking in a sense to produce a positive outcome here, however enikanorov has just now stated people without commits have no opinion or value here.
14:36:16 <sballe> enikanorov, I totally agree with you that I haven't contributed "patches" so far. I do plan to become very active and do so. I just want to contribute to the right foundation and not duck tape the old one.
14:36:20 <enikanorov_> mestery: as long as it goes along the main idea
14:36:34 <sbalukoff> enikanorov_: I'm concerned that a dictatorial approach to this problem is going to kill people's enthusiasm for improving LBaaS. If concerns aren't addressed, people will go back to what they've been doing until a couple months ago: Working on their disparate projects in a vacuum.
14:36:54 <mestery> I think enikanorov_ didn't mean it quite as it came out, and certainly we value everyone's opinion here, patch or no patch. There are many ways to measure contributions, patches being one.
14:36:57 <sballe> sbalukoff, +2
14:37:16 <blogan> sbalukoff: perhaps that is what the intention is
14:37:22 <enikanorov_> sbalukoff: yes, that's a good point. but i'm not a dicator for sure. i just want to make a progress at least with one approach. and i want to help people make progress with another approach
14:37:42 <aburaschi> +1 to reuse the good parts of the current API
14:38:02 <samuelbercovici> I have written most of the use cases and about 90% could be solved with existing API + SSL +L7 which are in very advanced state. the modification comes to address the rest.
14:38:05 <jorgem> aburaschi: I am down for reusing if it makes sense.
14:38:12 <ptoohill> have we identified what the good parts are versus the bad?
14:38:15 <sbalukoff> blogan: I hope not. Despite our disagreements, I think we can all do better working together still.
14:38:18 <enikanorov_> ptoohill: yes
14:38:19 <sballe> jorgem, +2
14:38:24 <aburaschi> sure :)
14:38:35 <enikanorov_> ptoohill: the bad pats are those which prevent us to allow advanced use cases
14:38:36 <sbalukoff> jorgem: +1.
14:38:53 <german_> jorgem +1
14:39:07 <sbalukoff> Ok, so I keep hearing this come back to use cases. Maybe we should spend some time *really* fleshing out the use cases and move forward from there?
14:39:15 <samuelbercovici> I have also reviewed the proposed single call api and belive that it can be implemented with the proposal
14:39:20 <sbalukoff> If we do that, how do we go about determining which use cases we'll support and which we won't?
14:39:38 <german_> vote in gerrit?
14:39:44 <jorgem> sbalukoff: +1. And actually showing workflows on how each proposal satisfies those use cases
14:39:45 <enikanorov_> sbalukoff: i think the single-call approach can fit well with the proposed API/obj model
14:39:48 <mestery> german_: +1!
14:40:02 <aburaschi> +1!
14:40:06 <enikanorov_> sbalukoff: and that's why i said about the agreement
14:40:07 <mestery> If someone files a use cases document in neutron-specs, that may be a really good start!
14:40:22 <sballe> I would like to suggest we look at what is Neutron Foundation e.g. Plumbing and what should be in the Advanced services. We want the integation to be clean so that Neutron can change its implementation which affecting LBaaS which is a consumer of Neutron internals. Does tha make sense?
14:40:25 <samuelbercovici> both the granular api and the single call should use the same object model whcih addresses the use cases
14:40:49 <sballe> s/whihc/without
14:40:50 <enikanorov_> samuelbercovici: that's for sure
14:40:56 <german_> +1
14:40:59 <sbalukoff> samuelbercovici: +1
14:41:00 <jorgem> We have one here that someone started ==> https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit#
14:41:02 <vivek-ebay> +1
14:41:14 <aburaschi> sballe: +1
14:41:21 <rm_work> sballe, samuelbercovici +1
14:41:50 <mestery> Not to derail, but we only have 19 minutes left. It would be good to have some actionable items come out of this meeting. It may take us 10-15 minutes to get those. :)
14:42:00 <mestery> I'd like to see everyone comment on enikanorov_'s proposal in neutorn-specs.
14:42:14 <mestery> I'd also like to see use cases added to that or a separate spec with use cases filed.
14:42:18 <german_> let's agree on use cases first
14:42:19 <mestery> It makes it easier to comment in one place.
14:42:20 <enikanorov_> #action enikanorov to extend BP with more detailed object model description
14:42:23 <samuelbercovici> so the proposal is based on 1. existing use cses 2. the ones we tried to do for icehouse want to complete forn juno 3. new uses cases that were the reason the discussion have started
14:42:45 <german_> it feels like we need to agree on use cases first
14:42:45 <mestery> I'm finding it hard to figure out which documents to read and comment on :)
14:43:02 <enikanorov_> german_: what to agree on, actually? if there's a use case, we need to support in, unless its totally don't fit into anything
14:43:03 <mestery> german_: Absolutely! Someone can take a first crack and we can suggest more in gerrit.
14:43:13 <aburaschi> I agree with mestery
14:43:15 <sbalukoff> german_: +1
14:43:16 <mestery> german_: But the gerrit review can be a starting point.
14:43:17 <enikanorov_> mestery: me too
14:43:29 <vivek-ebay> mestery: +1
14:43:44 <blogan> i will comment once I look it over, if it does satisfy our needs then I'll +1 it, however it seems like if a lot of the new people's opinions wont be heard because they more than likely dont have votes
14:43:51 <mestery> I am more than happy to help someone out who wants to drive that.
14:44:15 <enikanorov_> blogan: it's not about choice, it's about accounting for everyone's concerns
14:44:22 <rm_work> if you HAVE a gerrit account, you have a vote in gerrit, right? there's no requirements above that
14:44:24 <jorgem> enikanorov: No necessarily, the product will have natural constraints and satisfying the .00001% use case may not make sense. We need to identify major and minor use cases in order to make a good decision.
14:44:32 <enikanorov_> blogan: that what we had in mind proposing the BP
14:45:04 <enikanorov_> jorgem: that's also true
14:45:06 <mestery> rm_work: It's tied to your launchpad account, so you need one of those.
14:45:13 <enikanorov_> jorgem: but you know there are cases that affect API.obj model
14:45:19 <jorgem> enikanorov: Also, operator use cases have been largely ignored
14:45:26 <enikanorov_> jorgem: others just affect a set of constants may be
14:45:26 <rm_work> mestery: ah, well right. just saying, you don't need to have contributed a patch to neutron to vote
14:45:48 <mestery> rm_work: Correct! Anyone with a LP account can +1/-1.
14:45:50 <samuelbercovici> rm_work: correct
14:45:50 <jorgem> enikanorov: Correct, I think we are in agreement
14:45:51 <enikanorov_> jorgem: operator API is another big story, but probably less complex and requiring less discussions
14:45:53 <blogan> enikanorov: i agree everyone's concerns should be accounted for, but I'm still worried that just because there has been a surge in interest lately in this product and a lot of us are new, our opinions will not be accounted for
14:46:16 <sballe> rm_work, You can vote +1 but you cannot approve +2. Only core members can +2
14:46:20 <rm_work> blogan: we just need to do an actual vote. so far we've just been in discussion mode, but it looks like the time for that has ended
14:46:28 <enikanorov_> blogan: we're trying to account for them
14:46:31 <jorgem> enikanorov: Hmm, operating at a large scale like we do here at Rackspace comes with all sorts of new issues though.
14:46:35 <rm_work> sballe: right, but we won't be "unheard" :)
14:46:37 <mestery> blogan: We'll make sure we let everyone have a say for sure!
14:46:49 <sballe> rm_work, Agreed :)
14:46:53 <jorgem> enikanorov: I'd like to share those and address them. In the end it will really help everyone out I believe.
14:47:05 <mestery> jorgem: +1
14:47:24 <enikanorov_> jorgem: on the operator side there are a bit of unresolved issues project-wise
14:47:40 <blogan> those are going to be the most difficult to solve
14:47:45 <samuelbercovici> jorgem: please do it on https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing so at least for use cases we will have one place to look
14:47:48 <enikanorov_> but we can sort them out in parallel to tenant API
14:47:51 <samuelbercovici> the document is world wide edited
14:47:54 <jorgem> enikanorov: But for now I agree on focusing on the user requirements makes sense. I don't want to broaden the discussion right now.
14:48:03 <enikanorov_> yeah
14:48:07 <aburaschi> Is it ok to use jorgem proposed link to unify documents and use cases?
14:48:28 <samuelbercovici> aburaschi: please do it on https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing so at least for use cases we will have one place to look
14:48:30 <mestery> I would really like us to move to gerrit for all of these things as fast as we can.
14:48:33 <blogan> i thought the uses cases will be pushed to neutron-specs
14:48:35 <jorgem> aburaschi: By all means please!
14:48:37 <enikanorov_> so, going back to use cases: I'd suggest we will discuss only those, which affect object model and API
14:48:45 <mestery> I'm fine with consolidating in gdoc for now, but moving to gerrit should be a priority quickly after that.
14:48:51 <sballe> jorgem, We have the same large operator agreements as you do and I agree taht we cannot dolve them al lin once. The focus on the APi makes a lot of sense to me as a first priority
14:49:05 <blogan> mestery: that should be an action itemt hat comes out of this meeting
14:49:13 <aburaschi> samuelbercovici, jorgem: ok, thanks! great.
14:49:15 <enikanorov_> if it's TCP vs HTTP propotoc - that would not make much sense to discuss it, because implementaion will be mostly unaffected by decision
14:49:18 <sbalukoff> Will the +1'ing we do on use cases be for individual use cases?  Will that work with gerrit?
14:49:19 <blogan> mestery: that will make it a lot better
14:49:28 <sbalukoff> (We're potentially look at dozens of different use cases.)
14:49:29 <mestery> #action The team to consolidate use cases here: https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing
14:49:55 <mestery> #action The team to move the use cases to the neutron-specs repository before next week's LBaaS meeting.
14:50:01 <TrevorV> enikanorov_: When reviewing the use-cases, many of them are not just differences in protocol...
14:50:40 <sballe> TrevorV, +1
14:50:42 <sbalukoff> It's also possible that some use cases will be mutually exclusive.
14:50:45 <enikanorov_> TrevorV: yes, there are different types of cases. L7 switching for example introduces whle bunch of requirements for API and obj model
14:50:52 <enikanorov_> *whole
14:50:58 <rm_work> sbalukoff: I hope we don't run into that :(
14:51:06 <enikanorov_> and that's the kind of cases it makes sense to discuss
14:51:11 <sbalukoff> I can think of one off the top of my head. :)
14:51:23 <samuelbercovici> sbalukoff: shhot :-)
14:51:27 <samuelbercovici> shoot
14:51:32 <sballe> sbalukoff, let's hear it ;)
14:51:33 <rm_work> I have not seen anything like that yet, fortunately… what is the one you are thinking of? I guess you can explain externally
14:51:42 <rm_work> might be better handled after this
14:52:55 <sbalukoff> "User needs to ensure that the password encrypting SSL key is not stored anywhere on disk and therefore needs to be prompted for a passphrase whenever the key is used."   "Operator needs to be able to automate service stops and starts"
14:53:28 <enikanorov_> ok, that's the use cases that out of our current scope, I'd say
14:53:38 <german_> who decides scope?
14:53:40 <enikanorov_> questions are important, but not now.
14:53:52 <enikanorov_> german_: our topic
14:53:59 <enikanorov_> which is tenant API and object model
14:54:11 <jorgem> sbalukoff: Correct. Prompting for passphrase is not conducive to an API I would think.
14:54:25 <sballe> sbalukoff, This sounds to me like it would involve integration with Barbican so to me it is an advanced features of the lB. it should still be in scope for LBaaS IMHO
14:54:32 <samuelbercovici> sbalukoff: lets take it off line as although I understand this, I did not encountered it yet
14:54:39 <sbalukoff> jorgem: Yeah, see that part of the SSL stuff in the wiki has been disturbing to me this whole time. ;0
14:54:48 <enikanorov_> sballe: it is in scope, but just let's do one thing at a time
14:54:55 <samuelbercovici> sballe: correct
14:55:01 <sballe> enikanorov, I agree
14:55:34 <german_> sballe +1
14:55:36 <aburaschi> enikanorok_: +1
14:55:36 <enikanorov_> ok, we have few minutes left, lets talk about summit design tracks
14:55:38 * mestery notes we're 5 minutes from this meeting being over.
14:55:39 <sballe> enikanorov, I am just saying that we will have basic use cases and and advanced use cases and we can agree to tackle them at different times
14:55:40 <sbalukoff> In any case, this is just one possible case of conflict. And yes, we need a way to discuss how compromises are made in this case. If this can be done with gerrit, let's do it. I guess we'll see how well discussions work there.
14:55:47 <samuelbercovici> sbalukoff: this was done to support directly provisioning the certificates without any store such as barbican
14:55:51 <aburaschi> enikanorov_
14:55:55 <mestery> Any other actionable items we want for the team or individuals this week?
14:55:55 <aburaschi> +1
14:56:27 <enikanorov_> samuelbercovici and me have several topics to cover on those tracks
14:56:29 <jorgem> Show workflows on how use cases fit in proposals
14:56:31 <rm_work> sbalukoff: i assume you would comment on the specific use-case you had a problem with, -1 the whole thing, and a patchset would be proposed
14:56:35 <blogan> im unclear as to what the API proposing teams are supposed to do? get their API proposals working with the current object model?
14:56:44 <enikanorov_> if you feel something needs to be added, please send out to ML
14:57:03 <enikanorov_> and we'll think on how to merge your proposals
14:57:10 <sballe> blogan, I thouht the object-model was up for discussion too.
14:57:27 <mestery> I would strongly encourage feedback on gerrit as well.
14:57:28 <rm_work> sballe: it is if we vote in gerrit that it is :)
14:57:39 <sbalukoff> blogan: Action items so far include stuff around consolidating use cases and getting them into gerrit.
14:57:40 <mestery> Consolidating feedback there is actually quite nice and allows for fast iteration in addition.
14:58:00 <blogan> sballe: it is in gerrit, but thats why its unclear, the decision on that is the lynchpin for anything going forward
14:58:26 <mestery> The object model in gerrit is fair game for comments by any takers. :)
14:58:36 <enikanorov_> mestery: got it
14:58:43 <sbalukoff> We're almost out of time. Shall we do summit-related discussion on mailing list?
14:58:44 <enikanorov_> we'll amend the bp
14:58:53 <enikanorov_> sbalukoff: i suggest so
14:58:57 <sballe> blogan, agreed that is why I wanted to make sure we were still discussing hte object model. Making the APi work with the old object model doesn't make sense if it will change too
14:59:07 <german_> +1
14:59:23 <blogan> mestery: i like having all of this in gerrit, i think it will streamline workflows
14:59:30 <mestery> blogan: +1
14:59:36 <sballe> blogan, +1
14:59:37 <rm_work> and actual voting will be transparent
14:59:45 * mestery nods in agreement.
14:59:59 <sbalukoff> Heh! I've got just to figure out gerrit, then. XD
15:00:04 <rm_work> whelp, good meeting everyone :)
15:00:13 <enikanorov_> sballe: old object model is refined as well per BP, do don't  worry!
15:00:30 <mestery> Thanks folks!
15:00:33 <aburaschi> Thank you all. Bye!
15:00:35 <enikanorov_> ok, thanks every one for the meeting
15:00:39 <enikanorov_> you made my fingers burn
15:00:40 <enikanorov_> :)
15:00:43 <aburaschi> :)
15:00:46 <enikanorov_> #endmeeting