14:00:18 <dougwig> #startmeeting neutron lbaas
14:00:19 <openstack> Meeting started Thu Aug 21 14:00:18 2014 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:22 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:29 <a2hill> mornin'
14:00:38 <rm_mobile> Morning
14:00:41 <jorgem> morning
14:00:47 <dougwig> #chair jorgem
14:00:48 <openstack> Current chairs: dougwig jorgem
14:00:54 <dougwig> #topic Documentation for V2 needs to be postponed and V1 re-instated
14:01:10 <samuelbercovici> hello
14:01:11 <blogan> #link http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext.html
14:01:27 <blogan> since v2 is going into incubator, v1 docs need to be put back in
14:01:42 <xgerman> so, where do the incubator docs live?
14:01:46 <samuelbercovici> is going to incubation final?
14:01:50 <jorgem> hey dougwig, do you want to run the agenda today? I'm guessing the meeting started right before I joined?
14:01:51 <dougwig> who do we contact, or file a bug, or?
14:02:00 <blogan> xgerman: that is something to be determined, we need more details o nthat
14:02:09 <dougwig> jorgem: i set you as an extra chair, so you can take over if you want.
14:02:15 <xgerman> Min talked about a doc chnage
14:02:16 <blogan> xgerman: definitely should get min to save that doc work somewhere though
14:02:17 <dougwig> but np either way
14:02:32 <dougwig> who wants the action item to follow this up?
14:02:32 <xgerman> https://review.openstack.org/#/c/107603/
14:02:33 <jorgem> dougwig: I'll let you take a stab at it today ;)
14:03:14 <blogan> xgerman: im not sure if she needs to file a bug or a new review for this
14:03:30 <samuelbercovici> guys. is moving to incubation final?
14:03:33 <dougwig> #action dougwig follow-up on doc reversion
14:03:46 <blogan> samuelbercovici: i'd say its a 99.999% certainty
14:03:54 <sbalukoff> samuelbercovici: blogan: +1
14:03:54 <dougwig> samuelbercovici: let's transition to that...
14:03:55 <xgerman> dougwig, why would we reverse - we can just say in incubation?
14:04:20 <dougwig> xgerman: because unless we hear differently, v1 is still going to be supported in juno.
14:04:30 <dougwig> #topic Update on incubator
14:04:51 <blogan> xgerman: from what I have read about the incubation, is that the docs shouldn't change until graduation, either way, v1 docs still need to be there
14:05:04 <dougwig> mestery: are you around for a quick incubator update?
14:05:25 <xgerman> ok, I only read about experimental things being in horizon
14:05:27 <blogan> or markmcclain
14:05:30 <samuelbercovici> why should it move to incubation? is there anyone who prefer this over waiting on review queue until we get into trunk?
14:05:52 <blogan> samuelbercovici: no one preferred it, it's just what is happening with neutron
14:06:01 <blogan> sameulbercovici: kind of a new policy for new extensions
14:06:16 <samuelbercovici> blogan: but lbaas is not a new extension
14:06:17 <dougwig> samuelbercovici: it's been made clear that we're not far enough along with v2 for Juno.
14:06:29 <blogan> samuelbercovici: v2 technically is
14:06:58 <samuelbercovici> dougwig: then I think it is better to remain on review queue for Kilo than get moved to incubation
14:07:20 <dougwig> i don't think we're going to be given that choice.  nor is gbp.  we're still waiting final word.
14:07:31 <blogan> sameulbercovici: we argued the points for a while now, and I think we've all accepted its going to happen.  Other features/extensions that are actually more mature than v2 are also going into the incubator
14:07:36 * TrevorV late but here, sorry
14:07:48 <samuelbercovici> lbaas is different than gbp. I think that the api is in consensus
14:08:16 <xgerman> samuelbercovici +1
14:08:32 <sbalukoff> samuelbercovici: You'll get no argument from me on that, but I don't think we're going to change the minds of the core devs on this.
14:09:06 <blogan> samuelbercovici: we're just saying, the debate has been had, we have no choice
14:09:18 <sbalukoff> As I've ranted about extensively in other places, I think this is a political thing, and LBaaS has become a pawn in the battle.
14:09:40 <sbalukoff> Well, LBaaS v2, I mean.
14:09:47 <blogan> but we shall move forward now, and not look to the past, right? right?
14:09:53 <sbalukoff> Right.
14:10:08 <dougwig> samuelbercovici: if you check out last week's minutes for this meeting, kyle and mark joined and spoke at length about the incubator.  i don't think us not doing it was on the table.
14:10:31 <blogan> mestery_: ping
14:10:32 <rm_work> samuelbercovici: yeah, they were soliciting comments and arguments last week, until the end of the meeting when they said the patch was about to go in to do it, and I asked if the decision had already been made, and they said yes >_>
14:10:34 <sbalukoff> Speak of the devil!
14:10:49 <rm_work> specifically mestery_ said yes. welcome mestery_ :)
14:11:00 <dougwig> he's been pinging in and out of IRC since i woke up.  not sure if he's still at linuxcon.
14:11:00 <blogan> that's probably an auto rejoin
14:11:14 <sbalukoff> Oh, haha!
14:11:16 <blogan> anywho, back to the docs
14:11:19 <xgerman> also mestery announced the incubator officially at liunuxcon
14:11:19 <rm_work> yeah :(
14:11:30 <samuelbercovici> dougwig: already did so.
14:11:46 <vjay5> What is the fate of V1. There were talks about moving V1 as well to incubation?
14:11:54 <jschwarz> (where can we find last week's minutes?)
14:12:06 * mestery is lurking while at Linuxcon in Chicago at the moment.
14:12:13 <dougwig> #link http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/
14:12:19 <blogan> xgerman: do you think Min can follow up on at least getting V1 docs re-instated and at least getting V2 marked as preview/experiemental/incubated?
14:12:20 <samuelbercovici> so the incubation is going to be the dump bin for any code whic is not core?
14:12:28 <sbalukoff> Oh he is here! Sorry to have implied you were the devil earlier. ;)
14:12:35 <xgerman> bloga, yes, I can ask her
14:12:49 <blogan> xgerman: okay thanks, because v1 docs really do need to remain
14:13:00 <xgerman> nah, everybody should use v2
14:13:12 <dougwig> samuelbercovici: it's not supposed to be.  we have been assured it is not.
14:13:29 <rm_work> samuelbercovici: despite what dougwig says, I'm pretty sure you're right :P
14:13:36 <sbalukoff> Yeah, the hope is that that doesn't happen with incubator.
14:13:41 <jorgem> xgerman:  lol
14:13:43 <rm_work> but we'll see
14:13:45 <blogan> vjay5: v1 will probably remain in tree, but no official word on it so that could change
14:13:48 <samuelbercovici> dougwig: we were also assured at the begginning that we can start the api all over and it will be fine.....
14:13:51 <sbalukoff> I'm trying to be optimistic, folks!
14:14:14 <sbalukoff> (Though I'm not sure I can achieve blogan levels of optimism.)
14:14:23 <rm_work> blogan / vjay5: I'd actually like to see v1 pulled out of tree, if we're going to be stuck in incubator with v2
14:14:25 <a2hill> I thought I was pesismistic, then I met sbalukoff
14:14:28 <rm_work> but that may be a lost cause argument
14:14:32 <blogan> sbalukoff: its called denial and large quantities of alcholol!
14:14:34 <a2hill> +s
14:14:38 <dougwig> samuelbercovici: yes, we were.  and that's what has most of us a tad bit unsettled (or a lot unsettled.)
14:14:55 <blogan> alcholol is the type of alcohol that makes you laugh
14:15:02 <dougwig> rm_work: i'm very against pulling v1 out of tree, until it has something to replace it.
14:15:03 <sbalukoff> blogan: So that's what I've been doing wrong! I need to take up drinking.
14:15:07 <vjay5> we cant pull out v1, we have some customers who have deployed our solution
14:15:22 <vjay5> it has been there for 2 releases now
14:15:28 <blogan> vjay5: i think that actually is the reason to keep it in tree
14:15:28 <crc32> brb
14:15:39 <rm_work> dougwig: if v1 is out of tree, it makes the argument for splitting off easier :P
14:15:41 <xgerman> blogan +1
14:15:45 <sbalukoff> dougwig is right that pulling v1 out of tree screws over users and vendors with v1 deployments / drivers
14:15:50 <samuelbercovici> so back to the criteria of selecting code into incubation, and I beg pardon for acting the lawyer here. Is there a reason why an API which is in concensus can't be done on trunk but must pass via incubation?
14:15:59 <rm_work> but also there is supposedly "no reason projects from the incubator can't be deployed easily along with neutron"
14:16:01 <blogan> rm_work: can't screw over the customers because of a political maneuver
14:16:12 <jorgem> rm_work: that's what I thought
14:16:15 <sbalukoff> I would totally settle for v1 being officially deprecated in Juno. Not sure how feasible that is.
14:16:23 <rm_work> yeah, but they keep assuring us things are deployable to prod from incubator directly
14:16:23 <rm_work> so
14:16:41 <xgerman> rm_work I just read an e-mail where the packagers revolted and said no to the incubator
14:16:42 <blogan> samuelbercovici: you'll have to take that up with mestery and markmcclain
14:16:53 <samuelbercovici> blogan: ok
14:16:55 <dougwig> samuelbercovici: the decision of where things start/mature is in the hands of the neutron cores.
14:16:58 <rm_work> xgerman: well, ok then >_<
14:17:01 <sbalukoff> xgerman: Really? Was this public somewhere?
14:17:05 <dougwig> blogan: +1
14:17:12 <jorgem> xgerman: So we are back to no incubator then?
14:17:17 <rm_work> if that's the case, I am back to having some problems with the incubator plan again
14:17:18 <jorgem> xgerman: geesh
14:17:24 * mestery is catching up on emails now.
14:17:24 <mestery> The funny thing is, I had spoken to packages (not Ihar) and they said the incubator could be packaged
14:17:24 <mestery> So need to clarify that.
14:17:35 <jorgem> mestery: Please do!
14:17:39 <a2hill> sbalukoff, theres an email thread where this is being dicussed
14:17:52 <rm_work> yeah, having incubator packaged was one of the concessions that made it somewhat bearable as a solution
14:17:52 <dougwig> link?
14:17:54 <blogan> mestery: too many rumors swirling around, we need official details on this ASAP, rumors tend to kill any momentum
14:18:08 <jorgem> +1
14:18:16 <samuelbercovici> dougwig: I am working in this community for the last ~3 years. to me incubation is a place out of focus. why would any core who has his hands full, spend time to llok at code in incubation? this is beyond my understanding
14:18:29 <mestery> blogan: ++
14:18:35 <rm_work> samuelbercovici: i think that is one of the main fears, yes
14:18:39 <sbalukoff> blogan: +1
14:18:46 <rm_work> though they said we'd get some of our own additional reviewers in incubation
14:19:00 <blogan> rm_work: they said they were thinking about it, it wont happen in the beginning
14:19:07 <jorgem> rm_work: That's still not defined very well though
14:19:08 <rm_work> :/
14:19:11 <dougwig> samuelbercovici: i'm really not the right person to be asking.  the theory is that the review requirements will be different, and more iterative.  but i can't speak for the cores.
14:19:20 <rm_work> so that may not happen either? really? :/
14:19:57 <dougwig> rm_work: additional reviewers means less chance of graduation.  if i had to guess, they want to see how it's going to work, and add reviewers if necessary.  but that's just a guess.
14:20:19 <samuelbercovici> is this incubation, already in place?
14:20:29 <blogan> samuelbercovici: no
14:20:30 <sbalukoff> samuelbercovici: Nope
14:20:48 <rm_work> I thought markmcclain said the patches were going in last week?
14:21:02 <rm_work> guess that didn
14:21:04 <rm_work> *didn't happen
14:21:05 <sbalukoff> rm_work: Hasn't landed yet, from what I understand.
14:21:16 <rm_work> hah, what a surprise, a review is delayed :P
14:21:21 <rm_work> guess it even happens to the PTL
14:21:23 <blogan> so until we get more information, rehashing all of this is really just a waste of time
14:21:36 <sbalukoff> blogan: +1
14:21:42 <dougwig> last i heard, the code for the incubator was, "waiting on a few items."  not sure if that was code items, or review feedback.
14:21:44 <xgerman> blogan +1
14:21:55 <xgerman> also we aleways have the mailing list
14:21:55 <dougwig> +1, but i didn't want to cut anyone off.
14:21:59 <dougwig> ok, to move on to next topic?
14:22:23 <dougwig> #topic LBaaS v2 Client Code
14:22:56 <dougwig> #link https://review.openstack.org/#/c/111475/
14:22:58 <jschwarz> The current implementation of the v2 client code lets in some confusion vs the v1 client code
14:23:36 <dougwig> how so?
14:23:37 <blogan> #link https://review.openstack.org/#/c/111475/
14:23:39 <jschwarz> A comment regarding this issue was made by Yair (not here today) and dougwig also -1 until we talked about it... time we talk about it I think
14:24:07 <jschwarz> the whole 'lb-pool-create' vs 'lbaas-pool-create', etc is very confusing to first-timers and people who aren't up to speed
14:24:26 <dougwig> ah, right.  yair was very opposed to have v1 and v2 available at the same time, with slightly different command names.
14:24:34 <jschwarz> while it is okay to provide both v1 and v2 client APIs, I think there should be a stronger separation there
14:24:44 <sbalukoff> So, I would vote to deprecate all the v1-specific commands when v2 is available.
14:24:55 <sbalukoff> But, I think we were told at the mid-cycle hack-a-thon this wasn't an option.
14:25:06 <sbalukoff> That we needed to have both available at the same time.
14:25:07 <dougwig> yair's argument was to now allow both extensions to be present at the same time.
14:25:14 <dougwig> /now/not/
14:25:15 <jschwarz> sbalukoff, wouldn't this be right after v2 reached graduation?
14:25:35 <a2hill> prepending commands to ease confusion between versions?
14:25:45 <sbalukoff> jschwarz: Keep in mind this code was written and this direction set before such a concept as "graduation" existed.
14:26:04 <jschwarz> we must all adapt to changes in the project, it seems ;-)
14:26:34 <dougwig> yair's point was that "neutron lb" and "neutron lbaas" were sufficiently similar so as to likely cause users to make mistakes.
14:26:39 <sbalukoff> So what do we see as the 'right way' of doing this?
14:26:42 <dougwig> whoa, grammar fail.
14:26:45 <sbalukoff> Or rather, what would the core devs see?
14:26:53 <blogan> yeah and that is a good point, and something we should address
14:27:02 <xgerman> (after all we couldn't version)
14:27:06 <blogan> and I'd be fine with saying v1 and v2 cannot be active at teh same time
14:27:14 <dougwig> blogan: +1, and why i dropped a supporting -1.
14:27:34 <jschwarz> I heard a suggestion of a configuration option specifically allowing v1 or v2, but not both
14:27:38 <vjay5> blogan: +1
14:27:44 <jschwarz> sort of like "ENABLE_LBAAS_V2 = True/False"
14:27:57 <dougwig> does anyone feel strongly that they should both be allowed at the same time, outside of dev environments?
14:27:57 <sbalukoff> You heard it here folks: My -1's have actually been "supportive"
14:27:58 <sbalukoff> ;)
14:28:18 <vivek-ebay> it was discussed at hack-a-thon that v1 and v2 cannot be active at same time
14:28:35 <sbalukoff> Again, I can't fault Craig's code here because he implemented this this way based on direction from the core devs.
14:28:43 <samuelbercovici> the reason was to allow olad code that was using v1 to move to v2 by having both apis with a shim
14:28:48 <sbalukoff> But I think he'd also be in favor of disabling v1 when v2 is in use and visa versa.
14:28:48 <blogan> vivek-ebay: i don't remember that all, but my memory from the hackathon has all but faded
14:28:50 <samuelbercovici> not sure if we still want to do so
14:28:50 <jschwarz> No fault for Craig's code intended
14:29:07 <blogan> samuelbercovici: no point in dong a shim now
14:29:15 <sbalukoff> blogan +1
14:29:23 <samuelbercovici> blogan +1
14:29:24 <dougwig> blogan: +1
14:29:55 <samuelbercovici> did yair say, what he would consider acceptable?
14:29:56 <blogan> so would the best way to do it for the client to say that all calls go through lb?
14:30:05 <blogan> as in lb-pool-create works for both v1 and v2?
14:30:14 <jschwarz> samuelbercovici, we did not have a length discussion about this, I'm afraid
14:30:19 <blogan> (this would imply that the client would have some way to discover which version the server is running)
14:30:28 <dougwig> the request from the tempest folks was that the interfaces be the same but different for v1 vs v2.
14:30:38 <dougwig> as in, in favor of 'neutron lb' for both.
14:30:44 <sbalukoff> "the same but different"
14:30:49 <samuelbercovici> blogan: this would be really probalmatic with "old" scripts
14:30:57 <samuelbercovici> I still prefere different naming
14:30:58 <sbalukoff> Excellent specification there. ;)
14:31:15 <blogan> would "neutron lb" vs "neutron lbv2" be a better option?
14:31:15 <dougwig> sbalukoff: i'm not the best one to argue that point, since i don't agree with that facet of the objection
14:31:24 <jschwarz> there could be different naming, but then I would suggest specifically enabling either one but not both
14:31:35 <sbalukoff> dougwig: Aah, sorry-- I thought that was a direct quote
14:31:40 <dougwig> neutron lbv2-create-pool looks horrible.  :)
14:31:42 <jschwarz> so if I created a pool in v1, I wouldn't be able to try to add a member to that pool in v2
14:31:51 <xgerman> no
14:32:06 <xgerman> no mixing of APIs
14:32:33 <xgerman> also the db migration makes it diffiuclt without shim
14:32:47 <blogan> jschwarz: you wouldn't be able to add a v2 member to a v1 member currently, it'd say member id not found
14:32:51 <dougwig> yairs point is that if you run one set of commands, and then the other, you get an non-intuitive error (he's right).  i'm not sure that it necessarily follows that the commands must be the same, just that both not be present.
14:33:08 <jschwarz> blogan, I know, but it wouldn't prevent confusing for the users
14:33:18 <jschwarz> s/confusing/confusion/g
14:33:25 <blogan> jschwarz: i know, and i agree it'll be confusing to users
14:33:39 <samuelbercovici> the best would be to take if with him on IRC and then maybe on ML
14:34:08 <blogan> samuelbercovici: "old" scripts would only have a problem if v2 used the same lb prefix, and if v2 was enabled on the server right?
14:34:27 <samuelbercovici> blogan: to me the current naming is fine
14:34:47 <samuelbercovici> blogan: lb vs. lbaas is fine to me
14:34:54 <sbalukoff> samuelbercovici: +1
14:35:10 <dougwig> does anyone here today feel strongly that the api endpoints and cli commands should match v1 where they overlap?  because if not, we're arguing with a phantom.
14:35:13 <blogan> sameulbercovici: is it fine even when they're both enabled together?
14:35:24 <samuelbercovici> and I think we all are fine with this. so the discussion should be taken with yair to see how to address his concern
14:35:30 <dougwig> +1
14:35:38 <xgerman> +1
14:35:39 <jschwarz> I agree with Yair
14:36:06 <dougwig> i'm going to move on, unless there's part of this we haven't discussed...
14:36:18 <blogan> jschwarz: can you start a ML thread about it?
14:36:31 <jschwarz> blogan, sure, either me or Yair on sunday
14:36:37 <blogan> jschwarz: hopefully Yair will come into as well
14:36:43 <johnsom> +1
14:36:45 <dougwig> #action jschwarz Discuss v1/v2 api naming issue on ML
14:36:53 <dougwig> #topic What is LBaaS v1 in Juno?
14:37:08 <blogan> vjay: you added this didn't you?
14:37:11 <dougwig> whoever added this agenda item, the floor is yours.
14:37:13 <vjay5> yes
14:37:15 <blogan> vjay5
14:37:17 <vjay5> i added this
14:37:38 <vjay5> i wanted to make sure V1 is sure to be in the main tree
14:37:50 <blogan> vjay5: i'd say that is a probability, but not a certainty
14:38:00 <blogan> vjay5: we won't know until we get more details
14:38:11 <dougwig> i have not heard even a single hint from the cores that it won't be.
14:38:15 <sbalukoff> Yep. Similar discussion to earlier.
14:38:29 <rm_work> yeah, again, they have told us that even incubator will be packaged for production -- so, it shouldn't matter -- but either way we need more details to really discuss this
14:38:45 <vjay5> so these discussions are core only? or is it somewhere public for people to particpate
14:38:49 <samuelbercovici> there are pople using v1, you can't take it away without a replacement
14:39:17 <vivek-ebay> yes, i think v1 is un-touched
14:39:19 <blogan> dougwig: i heard at some point it was something that they "were exploring"
14:39:19 <rm_work> vjay5 / samuelbercovici: right, so either it will be in core, or it will be packaged in incubator -- one of the two
14:39:28 <sbalukoff> samuelbercovici: If incubator is pursued as intended with good faith, moving v1 there isn't "taking it away"
14:39:30 <sbalukoff> per se.
14:39:35 <rm_work> sbalukoff +1
14:39:42 <xgerman> +1
14:39:51 <sbalukoff> but again, I think this is a fruitless discussion until we get more details.
14:40:00 <blogan> +1000
14:40:04 <rm_work> [09:38:26]  <rm_work>	 yeah, again, they have told us that even incubator will be packaged for production -- so, it shouldn't matter -- but either way we need more details to really discuss this
14:40:08 <a2hill> That is if the packagers get on board and decide to actually package the incubator?
14:40:27 <samuelbercovici> sbalukoff: I don't agree. status in thigs in incubation and packaging them is not same as core
14:40:29 <xgerman> well, there always is github
14:40:43 <blogan> xgerman: and stackforge!
14:40:56 <dougwig> ok, we're devolving into another incubator rant without info.
14:40:58 <dougwig> :)
14:41:05 <rm_work> yes
14:41:07 <rm_work> either way we need more details to really discuss this
14:41:11 <blogan> vjay5: have we answered your question with enough uncertainty?
14:41:12 <jorgem> indeed
14:41:19 <vjay5> how are these details and info communicated?
14:41:19 <jorgem> lol
14:41:20 <xgerman> dougwig you are syaing it likes a bad thing :-)
14:41:21 <sbalukoff> samuelbercovici: Given my level of skepticism on this, I'm sure you probably know I agree with you. ;)
14:41:55 <blogan> vjay5: I'm assuming it will be announced on the ML, but even that is unclear
14:41:56 <dougwig> ok, moving on...
14:42:08 <vjay5> ok..lets move to next topic then
14:42:08 <dougwig> #topic Is Juno open for fixing v1 bugs?
14:42:10 <sbalukoff> Yes please!
14:42:19 <vjay5> I added this as well
14:42:29 <jorgem> Doesn't this depend on our previous discussion?
14:42:39 <dougwig> i've seen v1 reviews and cores commenting on them, so i'm inferring the answer here is 'yes'.
14:42:43 <sbalukoff> vjay5: Very good question. I have no idea.
14:42:44 <jorgem> Thus, we should wait until more info is available?
14:42:59 <dougwig> jorgem: yep.
14:43:03 <sbalukoff> +1
14:43:06 <blogan> i know eugene has done some bug fixes for v1, but I htink they were mroe stability bug fixes for neutron
14:43:17 <vjay5> we were not submitting V1 small enahancements and bugs on the driver because we were intending to move V1.
14:43:18 <dougwig> but i'd say that with fpf today, if you have a v1 fix, submit it.
14:43:24 <vjay5> s/v1/v2
14:43:34 <vjay5> so there is not last date yet right?
14:43:39 <vjay5> s/not/no
14:43:47 <vjay5> file a bug and upload the fix
14:43:50 <xgerman> there probably is but we don't know
14:43:58 <vjay5> no restriction like august 21 for bugs i suppose?
14:44:14 <blogan> this is actually probably another casualty of the incubator, is that since we were focused on v2, v1 bug fixes were overlooked, and now it doesn't look so good
14:44:15 <dougwig> i'd submit your v1 fixes, not wait.  worst case, it gets ignored.
14:44:19 <sbalukoff> vjay5: It would be a really good idea to get those submitted today.
14:44:28 <vjay5> ok. thanks!
14:44:38 <dougwig> #topic Open discussion
14:44:44 <blogan> i gotta go
14:44:49 <sbalukoff> Seeya!
14:44:52 <blogan> adios
14:44:56 <xgerman> bye
14:45:03 <dougwig> anyone have anything else, or we'll break early ?
14:45:16 <sbalukoff> I got nothin'
14:45:20 <jorgem> same
14:45:26 <xgerman> 0
14:45:27 <rm_work> dougwig: we could rant about incubation for another 15 min?
14:45:30 <samuelbercovici> does anyone knows of a missing critical featur that is still required to get v2 core into juno?
14:45:33 <sbalukoff> HAHA
14:45:45 <vivek-ebay> I have a question
14:45:45 <rm_work> I mean, since we have the time...
14:46:05 <rm_work> samuelbercovici: well, we are running up against the clock on TLS... but I don't know if we required that in Juno V2
14:46:20 <dougwig> samuelbercovici: no tempest tests, no horizon, the ref driver doesn't have an agent, so can only run on one box, general unproven stability.
14:46:30 <samuelbercovici> I am preparing to discuss with Kyle, and as far as I know we have everyting required (API, Tests, CLI, driver and reference implementation)
14:46:31 <jorgem> I feel like incubation is the start of Skynet
14:46:37 <samuelbercovici> am i missing something?
14:46:46 <jorgem> lol
14:46:50 <sbalukoff> Heh!
14:46:52 <rm_work> samuelbercovici: well, TLS is still totally missing components
14:47:01 <samuelbercovici> I am talking core v2
14:47:03 <sbalukoff> vivek-ebay: What is your question?
14:47:12 <vivek-ebay> Suppose user created a LB with few members in a pool.
14:47:16 <samuelbercovici> I prefer to have this in Juno and complete the rest for Kilo if possible
14:47:23 <rm_work> samuelbercovici: ok, so TLS isn't req for core v2
14:47:25 <rm_work> ?
14:47:26 <dougwig> samuelbercovici: tests and the ref driver not being able to scale.
14:47:28 <vivek-ebay> members are supposedly instance member IPs
14:47:48 <samuelbercovici> I think that we can get pass with unscalalble ref driver
14:47:57 <dougwig> samuelbercovici: but by all means, have the conversation.  we'll cross our fingers for you.
14:48:06 <samuelbercovici> what avout tempest, I thought it was worked on?
14:48:07 <a2hill> There some missing container communication for the TLS ref impl
14:48:19 <vivek-ebay> when tenant/user removes instance from nova...will LB continue to have that member within the pool ?
14:48:22 <dougwig> samuelbercovici: minimal api tests.  not in detail, and no scenarios.
14:48:26 <a2hill> Ive submitted the review for it, but without Barbicans work complete it wont do anything
14:48:29 <sbalukoff> vivek-ebay: Yes.
14:48:42 <sbalukoff> since member IPs are not strictly tied to nova instances.
14:48:49 <dougwig> samuelbercovici: momentum/work stopped about 2-3 weeks ago, when the incubator came into play.
14:48:54 <vivek-ebay> later some other tenant can get the same IP, and cause unexpected behavior
14:49:28 <vivek-ebay> we should somehow enforce removal of member if instance is being removed.
14:49:35 <sbalukoff> vivek-ebay: So if the other tenant is on a different internal network, that shouldn't happen.
14:49:38 <dougwig> vivek-ebay: members don't have to be instances.
14:49:57 <rm_work> yeah I have about 1300 lines of barbican code still waiting for review -- and more to write on the neutron-lbaas side to get barbican up and working
14:49:57 <vivek-ebay> in our case, tenants shares networks
14:49:59 <sbalukoff> But it could if the IP being referenced is accessible from the first tenant's network (eg. the IP being referenced is "public" in some way)
14:50:32 <dougwig> safer would be to add something to the member indicating if it was a nova instance, so the cleanup wouldn't need to infer anything.
14:50:48 <samuelbercovici> dougwig: I agree. but we can still make at least with core v2. It is a question of seeing what is missing to get this done and focus on it!
14:51:00 <sbalukoff> vivek-ebay: Then, yes the problem you describe exists, but forcing removing of a member is problematic since they don't correspond 1:1 with instances.
14:51:33 <vivek-ebay> we have written a notification handler to handle such cases
14:51:55 <vivek-ebay> handler listens for instance deletion notification and calls lbaas api to remove member from existing pool.
14:52:11 <sbalukoff> samuelbercovici: I think our window for that has essentially closed while we were waiting on core reviewer feedback on the core changes three weeks ago. :/
14:52:12 <vivek-ebay> but was thinking if this can be generically addressed. will be a common problem.
14:53:06 <sbalukoff> vivek-ebay: You'd need to have some way to know that the lbaas member actually corresponds with the nova instance. Is IP address enough to know that?
14:53:36 <vivek-ebay> no, we modified schema to also contain instance uuid
14:53:42 <sbalukoff> vivek-ebay: In other environments, it's not necessarily a problem because tenants don't share back-end networks.
14:53:49 <sbalukoff> vivek-ebay:  aah!
14:54:14 <sbalukoff> vivek-ebay: Is that attribute required?
14:54:32 <vivek-ebay> for us yes, but should be optional in general
14:54:43 <sbalukoff> I don't think we can force lbaas members to correspond with nova instances. That would break some users' configurations.
14:54:59 <sbalukoff> vivek-ebay: So, that's not a bad idea.
14:55:10 <vivek-ebay> correct..we want it to be independent
14:55:16 <sbalukoff> Make it an optional attribute of the member, and then the code can auto-clean stuff with your notifier.
14:56:37 <dougwig> heh.  i said that at 8:50 sbalukoff
14:56:52 <dougwig> :)
14:57:07 <sbalukoff> dougwig: Why use one statement to get to the point when I can use 10? ;)
14:57:08 <vivek-ebay> :)
14:57:53 <dougwig> heh.
14:57:56 <dougwig> 2 minutes.
14:57:59 <vivek-ebay> ok, time to wrap up i guess
14:58:13 <rm_work> yeah, i guess my team just... took off to our sprint planning meeting >_>
14:58:19 <rm_work> I guess they thought we were done :P
14:58:36 <sbalukoff> Well, we're done now!
14:58:40 <dougwig> i'd suggest moving the member discussion to the ML
14:58:40 <rm_work> later all!
14:58:46 <rm_work> \o
14:58:50 <xgerman> bye
14:58:50 <dougwig> bye
14:58:53 <sbalukoff> Seeya!
14:58:53 <vivek-ebay> bye all
14:58:54 <dougwig> #endmeeting