Tuesday, 2014-08-19

*** xgerman has quit IRC00:10
*** sbfox has quit IRC00:10
*** VijayB has quit IRC00:12
*** VijayB_ has joined #openstack-lbaas00:21
*** jorgem has quit IRC00:36
*** crc32 has quit IRC00:40
*** dlundquist has left #openstack-lbaas00:54
*** magesh has quit IRC01:36
*** VijayB_ has quit IRC01:53
*** Krast_ has quit IRC02:26
*** Krast has joined #openstack-lbaas02:26
*** sbalukoff has quit IRC02:26
*** vjay4 has quit IRC02:44
*** woodster_ has quit IRC02:45
*** fnaval has quit IRC02:46
*** fnaval has joined #openstack-lbaas03:06
*** fnaval has quit IRC03:06
*** markmcclain has quit IRC03:24
*** amotoki has joined #openstack-lbaas03:33
*** orion_ has joined #openstack-lbaas03:47
*** vjay4 has joined #openstack-lbaas04:30
*** sbalukoff has joined #openstack-lbaas05:07
*** orion_ has quit IRC05:07
*** orion_ has joined #openstack-lbaas05:08
*** Krast has quit IRC05:08
*** orion_ has quit IRC05:12
*** ctracey has quit IRC05:16
*** ctracey has joined #openstack-lbaas05:20
*** vjay4 has quit IRC05:54
*** orion_ has joined #openstack-lbaas05:59
*** orion_ has quit IRC06:03
*** Krast has joined #openstack-lbaas06:14
*** Krast has quit IRC06:28
*** vjay4 has joined #openstack-lbaas06:52
*** jschwarz has joined #openstack-lbaas07:01
*** vjay4 has quit IRC07:04
*** sbfox has joined #openstack-lbaas07:11
*** vjay4 has joined #openstack-lbaas07:27
*** Krast has joined #openstack-lbaas08:22
*** sbfox has quit IRC09:01
*** jschwarz_ has joined #openstack-lbaas09:15
*** jschwarz has quit IRC09:15
*** jschwarz_ has quit IRC09:23
*** jschwarz_ has joined #openstack-lbaas10:03
*** vjay5 has joined #openstack-lbaas10:04
*** vjay4 has quit IRC10:07
*** Krast has quit IRC12:02
*** amotoki has quit IRC13:03
*** vjay5 has quit IRC13:14
*** woodster_ has joined #openstack-lbaas13:15
*** vjay5 has joined #openstack-lbaas13:28
*** HenryG_ has joined #openstack-lbaas13:46
*** HenryG has quit IRC13:47
*** HenryG_ is now known as HenryG14:07
*** markmcclain has joined #openstack-lbaas14:07
*** enikanorov__ has joined #openstack-lbaas14:09
*** enikanorov has quit IRC14:10
*** orion__ has joined #openstack-lbaas14:15
*** sbfox has joined #openstack-lbaas14:20
*** sbfox has quit IRC14:31
*** mestery_afk is now known as mestery14:39
*** markmcclain has quit IRC14:52
*** markmcclain has joined #openstack-lbaas14:53
*** mestery is now known as mestery_afk15:01
*** xgerman has joined #openstack-lbaas15:09
*** markmcclain has quit IRC15:12
*** jschwarz_ has quit IRC15:19
*** jorgem has joined #openstack-lbaas15:19
*** sbfox has joined #openstack-lbaas15:36
*** mestery_afk has quit IRC15:39
*** rohara has quit IRC15:55
*** rohara has joined #openstack-lbaas16:03
*** sbfox has quit IRC16:04
*** sbfox has joined #openstack-lbaas16:04
*** vjay5 has quit IRC16:06
dougwigblogan, sbalukoff, xgerman: you around?16:30
rm_workblogan isn't at his computer but I could tell him to look16:31
rm_workdougwig: ^^16:32
dougwignothing urgent.  want to pick their brains on v1/v2 incubator.16:32
*** markmcclain has joined #openstack-lbaas16:34
blogandougwig: im going to food trucks, will bb in like 20 mins16:34
dougwigyeah, i'd skip me for food trucks too.16:35
sbalukoffdougwig: I'm here.16:36
sbalukoffAlso, good morning!16:37
dougwigjust wanted to try and understand the desire to kick v1 into the incubator.  seems like that would cause issues with users, given that it's been in-tree for so long.  and it's not like it's going to change in the incubator.16:38
sbalukoffWell, part of that is because if v1 were released today, it certainly wouldn't pass muster to get through graduation. Part of that is my desire to see it retired / deprecated as soon as possible, since the longer it remains, the harder it's going to be to get v2 in place.16:39
dougwigsure.  but if we assume the incubator exists to promote rapid evolution... v1 will never evolve. it's unlikely to ever have even a single commit against it ever again.  and it's going to deprecate just as fast as v2 is ready.  so... it gains what, beyond confusing end users?16:40
sbalukoffAlso, part of that is my opinion that anything above l2/l3 really ought to be a separate sub-project that isn't rolled into Neutron core at all--  these should all be part of a master "Networking" project...16:41
sbalukoffAnd I'd love to see that happen (at all)16:41
dougwigit gains the devs nothing.  it gains the users less than nothing.16:41
dougwigright, but that's not what the incubator is.16:41
sbalukoffIt sends a clear signal to users that "you should not be using this."16:42
dougwigbut they already are!16:42
dougwigthe incubator isn't for sending political signals.16:42
sbalukoffSuuuure it isn't.16:43
dougwigsigh.  i'm trying approach with good faith, remember?16:43
sbalukoffI know you are. I'm having serous trouble with that.16:43
dougwigwith me acting in good faith?  ;-)16:44
sbalukoffNo, with me trying to be that optimistic.16:44
sbalukoffSeriously, though--  I have a hard time seeing this as anything but politics.16:45
sbalukoffI would be willing to settle for v1 being deprecated in Juno.16:46
sbalukoffI think v1 is going to be a major barrier to LBaaS spinning out.16:47
sbalukoffAnd really... it should spin out and become Openstack LBaaS.16:47
sbalukoff(The sooner that happens, the better.)16:48
dougwigi can see a number of scenarios where v1 doesn't get in the way of a spinout.  but really, aren't we supposed to be not focusing on a spinout right now?16:48
dougwiglet's write some dang code.16:48
dougwigthe politics aren't going anywhere.16:48
sbalukoffdougwig: Sure. But the window for doing something to get v1 out of the way is also in front of us right now.16:49
sbalukoffAnd if we're being screwed with our efforts on v2 (which we absolutely are), then I'd like to see them throw us a bone and make it simpler for us to get v1 out of the way.16:49
dougwigit can be gotten rid of whenever we want.  doing so before there's an alternative is silly.16:49
*** markmcclain has quit IRC16:49
*** markmcclain has joined #openstack-lbaas16:55
xgermanMy argument is that the reference driver is unusable so for me that shouldn't be in neutron16:56
xgermanbut if we pull the reference driver the rest likely needs to go, too - so I am not sure which is the lesser evil...16:57
*** vjay5 has joined #openstack-lbaas17:08
blogandougwig I see your point and it makes sense, that was my initial thinking, and your reasons are probably why it will not go into the incubator17:10
bloganbut I guess my reason is that if v1 wasn't already in tree, then wouldn't it belong in the incubator?17:11
dougwigit would, no question.17:11
bloganor really i suppose it wouldn't belong anywhere since v2 is already in there17:11
bloganso yeah I guess from the viewpoint of doing the right thing for neutron users and current lbaas users, pulling it out of tree would not be right17:12
blogani suppose it would just be a political maneuver17:12
dougwigv2 needs horizon and docs and a full test suite before i'd consider it to be "already in there" (i'd overlook no agent.)17:15
sbalukoffI'd be willing to settle for a deprecated v1 API, so that we can get rid of that piece of shit earlier. ;)17:15
dougwigtell us how you really feel.  don't sugar coat it.17:16
bloganits gonig to need the agent to get graduated anyway17:16
bloganthe right thing to do for the end users is to deprecate it once v2 is graduated17:17
bloganor is spun out17:17
sbalukoffI'm not sure I agree with that.17:17
bloganyou have the floor sir17:17
dougwigblogan: i was referring to what i'd need to see to see it as parity with the current state of v1.17:17
xgermanand an audience - i am back from our huddle17:17
sbalukoffRight, so v1 is all but unusuable for most production uses. And v2 *in its current state* can provide all the functionality of v1.17:18
xgermansbalukoff, the v1 reference driver17:18
dougwigblogan: +1 on the right timing is when v2 is ready to replace, though i'd be good with pre-graduation on that.  right now feels too soon.17:18
blogansbalukoff: it really can't because it doesn't have the driver support, nor an agent to allow for a scalable reference implementation17:18
dougwigsbalukoff: not everyone is a huge operator with their own UI.  no horizon support is a big deal.  no docs is a big deal.  no real test suite is a big deal.17:19
sbalukoffv1 has a scalable reference implementation?17:19
xgermandougiwg, now as our souls are crushed we waon;'t work hard to get it into juno17:19
dougwigxgerman: no question, our mo' got killed.17:19
sbalukoffWell, if we had somewhere to work on that... all those things would be taken care of pretty quickly.17:19
bloganscalable in the sense you can put the agent on as many nodes as you want17:19
sbalukoffBut incubator is also still a pipe-dream right now.17:19
xgermanno docs is wrong. Min wrote all the docs for v217:19
dougwigsbalukoff: yes, in a way.  you can run as many haproxy boxes as you want, each with their own agent.17:20
*** sbfox has quit IRC17:20
xgermanIn my opinion v1 works well with hardware load balancers. We had to pull v1 out of Helion because it absolutely doesn't work even in small installations17:21
sbalukoffdougwig: Really? And users manipulating the v1 API would result in some kind of scale when running multiple agents on multiple hosts?17:21
dougwigyeah, there's a crude scheduler that maps your root object and children to a particular node.17:22
dougwigno HA, no provisions for moving when overloaded.  it's not a good scalable solution, it viewed sideways, it is.17:22
xgermanso as I said I would love to pull the referewnce implementation + leave the API17:23
xgermanis that an option?17:23
sbalukoffdougwig: It sounds to me like people using v1 (what poor few there are) are doing things not exactly documented anyway. :/17:24
sbalukoffAnd making hack-ish alterations to "make it work."17:24
dougwigsbalukoff: you just described all of openstack.  :)17:24
*** dlundquist has joined #openstack-lbaas17:24
*** sbfox has joined #openstack-lbaas17:24
*** markmcclain has quit IRC17:25
*** markmcclain has joined #openstack-lbaas17:25
sbalukoffdougwig: Haha! Good point.17:29
dougwiggoing to grab lunch, bbiab.17:29
sbalukoffSorry for the grumpiness folks. I woke up on the wrong side of the bed last week (and called it "incubator")17:30
bloganxgerman: i don't think thats an option because everything needs a reference implementation to exist17:31
sbalukoffblogan: +117:31
xgermanwell, the reference implementation would be in the incubator... so...17:32
bloganyeah but then the reference implemenation would be installed in a different manner17:32
bloganso i doubt that is an option17:32
sbalukoffWe've also been told that apparently some users somewhere are using the v1 reference implementation in production (the poor schmucks)17:32
bloganwell octavia will solve all their problems then right?17:33
xgermanOctavia will also heal unicorns17:33
sbalukoffdougwig does have a good point: Pulling v1 into incubator would be a dick move to those users who actually use it.17:33
sbalukoffCorrection: Octavia will shoot unicorns.17:33
sbalukoffOut of canons.17:33
blogancan it shoot then heal?17:33
sbalukoffThat's its version of tough love.17:34
bloganits good testing17:34
bloganoh yeah sbalukoff17:34
bloganyou have said listeners will have many pools17:35
sbalukoffblogan: They will... once we have L7 functionality.17:35
bloganis that changing from the neutron lbaas model where the L7 object was going to have a pool17:35
bloganwhat I mean is will the listener directly have a one to many relationship with pools or will it be indirectly through an L7 object?17:36
sbalukoffSo, listeners will have many pools. These get linked to the listener object through L7 policies (or, as a default_pool_id)17:36
sbalukoffWell, a join table is necessary in either case. The L7 policy just has some extra attributes.17:36
bloganokay so in that case it's still fine to have an API look like /loadbalancers/{lb_id}/listeners/{listenr_id}/pools17:37
sbalukoff(Sorry, I often think of these things in terms of their database representations.)17:37
bloganperfectly fine, im thinking about them in both the database and api17:37
sbalukoffblogan: Yes.  But!17:37
sbalukoffIt occurs to me...17:37
sbalukoffWith the listener having a 'default_pool_id' attribute, this implies that the default action for the listener is to forward the request on to a back-end pool.17:37
*** VijayB has joined #openstack-lbaas17:38
sbalukoffThis is valid for >90% of load balancers out there...17:38
sbalukoffBut! Occasionally the default action will be to redirect or block.17:38
blogani think that can just be a validation piece17:38
bloganbc the listener is going to have to have some kind of redirect or block attribute for these features right?17:38
sbalukoffThat can currently be accomplished by making an L7 rule which catches everyting (eg. "Search the header for "Host" and match anything). That would effectively supersede a default "forward request to pool X" action...17:39
sbalukoffBut it's rather circumspect.17:39
sbalukoffDo y'all think that's worth revisiting?17:39
sbalukoffWhat I mean by that is... the default action a listener takes could/should be any kind of action that an L7 policy could take.17:40
bloganso why don't we just call the listener's pool by pool_id17:41
bloganso it's not implying a default action17:41
sbalukoffDoes it make sense to say that instead of a default_pool_id to forward to...  that there should be a default L7 policy, and that what action that policy takes can be variable...17:41
sbalukoffOr is that just too confusing for most users?17:41
blogani think that will get too confusing17:41
sbalukoffSo, callinging the listener's pool by pool ID implies the default action is to forward to that pool.17:41
sbalukoffMy point was that sometimes, you really just want to redirect.17:42
bloganand that redirect would happen in the L7 rules correct?17:42
sbalukoff(Going back to that relatively common scenario discussed on the mailing list where you can have a listener without a pool.)17:42
sbalukoffblogan: Presently, yes.17:42
sbalukoffIt's a bit of a hack, and I don't have a problem telling users how to do it as long as it's well documented.17:43
sbalukoffBut...  part of the implication here is that it needs to be considered a valid configuration if a listener has no pool.17:43
blogansee i think https redirect should actually be less confusing as an attribute of the listener, but it wouldn't be consistent17:43
sbalukoffblogan: That's actually how we do it in our model right now:  If you're going to be doing an https redirect, there's a field on the listener object you can fill out with the URL you want to redirect too... and if that field is not empty, then the software knows it shouldn't look for a back-end pool.17:44
sbalukoffI was just musing "is there a better way to do this?"17:45
*** vjay5 has quit IRC17:45
blogani feel like that way is better17:45
sbalukoffAlso, it's conceivable that a user might want a default action to be redirect, but that some URLs would actually be served directly. We don't have anyone doing this right now...  but in any case, leaving things as they are (with the L7 hackish way of doing a redirect) could accommodate this as well.17:46
bloganbut then the other use cases for L7 would be inconsistent with that17:46
sbalukoffblogan: I'm not against it. :)17:46
sbalukoffThe way I try to approach these things is to make things easiest for the most common usage scenarios.17:47
*** jschwarz has joined #openstack-lbaas17:47
bloganso i guess it coudl be as simple as if these things are very common across users then we can make an attribute of a listener17:47
sbalukoffBut still accommodate advanced and somewhat screwey-looking configurations if the user can justify a reason for wanting them.17:47
blogani am fine with this17:47
*** crc32 has joined #openstack-lbaas17:47
dougwigI want a unicorn.17:48
bloganif we're not allowing sharing of pools, and a user wants two different L7 rules to direct traffic to the same pool, we are fine with having them create two duplicate pools right?17:49
sbalukoffdougwig: I shall get you a unicorn.17:49
* blogan grills a unicorn steak for dougwig17:49
sbalukoffThat's finger-licking good!17:49
sbalukoffblogan: As I understand it, yes we are.17:49
sbalukoffUnless users come to us and complain loudly.17:50
bloganyeah and then it'll be easier to go to sharing of pools rather than the other direction17:50
bloganwill still be a complicated thing though17:50
bloganyou got an idea for a meeting agenda tomorrow?17:51
sbalukoffblogan: I was going to put that together once this conversation is over.  I think I've only got 1 or 2 items on it, so if you want to add more, feel free!17:52
sbalukoffWhat do you think of allowing sharing of pools within one listener configuration?17:52
sbalukoffBut not between listeners?17:52
sbalukoffIn theory, we could still have "simple" status and stats.17:52
sbalukoffAnd we wouldn't be forcing haproxy to do a bunch of duplicate health checks.17:53
sbalukoffAnd, since we don't presently allow for complicated logic around L7 rules... that could increase the number of pools a user would have to use artificially.17:53
sbalukoffWhat would be the possible down-sides of that?17:54
xgermanthe health check argument could be extended to our discussion with listeners and haproxies -- just saying :-)17:55
sbalukoffAll the pools could still be accessed via a /loadbalancers/{lb_id}/listeners/{listenr_id}/pools/{pool_id} URL...  we'd just add a 'default' attribute to one of them. :)17:56
bloganwouldn't that be the listeners default_pool_id17:56
bloganor pool_id17:56
sbalukoffxgerman: That's true. Though I think the incidence of duplicate checks would be far more with non-shared pools given the way L7 is meant to work.17:57
sbalukoffblogan: Aah-- yes, you're right.17:57
sbalukoffThat's a better way of doing it.17:57
sbalukoffSorry, I was thinking if we disallowed sharing of pools between listeners, then pools could have a listener_id attribute.17:57
bloganif listeners had a direct one to many with pools that would be the case17:58
sbalukoff(Rather, they *would* probably need that attribute.17:58
sbalukoffblogan: So that's what I'm saying, have a direct one-to many, but we don't do anything with pools that aren't either the default pool, or referenced by an L7 rule.17:58
bloganim kinda thinking sharing pools within listener configuration might be okay17:59
sbalukoffYeah, I'm trying to think of down-sides to this.17:59
sbalukoffAgain, stats collection and status would actually probably be easier for the user...17:59
*** VijayB has quit IRC17:59
sbalukoffPools would still be referenced through their parent (listener) end-point...18:00
blogani remember drawing something similar like that up during the whole api proposal phase but didn't do it for some reason18:01
sbalukoffMuch simpler for users with complicated load balancer configurations while not increasing complexity for users with simple configurations...18:01
sbalukoffSeriously, what's the achilles heel with this idea?18:02
bloganok just to be clear here, you'r suggesting listener_id attribute on the pool to give the listener to pool a direct one-to-many, while also having a default_pool attribute on the listener?18:02
bloganor the pool would just have a default attribute?18:02
xgermanwell, the achilles heal is that if we ever get to shareable pools as demanded by some vendors we will have to adapt18:02
sbalukoffblogan: either a default_pool_id on the listener, or a 'default' attribute on the pool. The former seems more intuitive and less error-prone.18:02
sbalukoffOne can assume the first pool added will be the default.18:03
xgermannever assume18:03
sbalukoffxgerman: I think we'd have to adapt in either case.18:03
blogani like the default_pool_id on the listener, however that also means we need to have a listener_id on the pool as well so that we know a pool belongs to a listener18:04
*** VijayB_ has joined #openstack-lbaas18:04
sbalukoffblogan: Yes.18:04
jschwarzjumping in: what's the idea of 'default_pool_id', then?18:04
sbalukoffThat's how we enforce the 'no sharing pools between listeners' rule.18:05
bloganwhich without the assumption of first pool created is the default, then the user would have to create the listenr first, then the pool, then update the listener's default_pool_id18:05
sbalukoffjschwarz: A listener can have many pools (accessed via different L7 policies / rules). But only one of them can be the default, if no L7 policies match.18:05
sbalukoffblogan: Yes.18:05
bloganor the API just allows a default attribute on the pool, that will automatically markit as the listener's default_pool_id18:06
bloganbut we don't store taht default attribut eanywhere else18:06
sbalukoffblogan: Even better. :)18:06
bloganso when I originally thought of havng the defualt attribute on the pool, we didn't do it because we were also sharing pools across many listeners18:07
bloganin this case it probably works18:07
bloganoh and we also weren't dong default_pool_id18:08
bloganon listener18:08
sbalukoffblogan: It does, but I still think the default_pool_id attribute is better.18:08
sbalukoff(on the listener)18:08
bloganyeah i think that will be perfectly fine18:08
blogani say that now and then of course soemthing will pop up and we either hack around it or don't do it18:09
sbalukoffDoing the default_pool_id on the listener actually makes the coding changes slightly simpler, if at some future date we decide that we need to allow pools to be shared between listeners.18:09
bloganwell if we start sharing pools across listeners, then it wouldn't make sense for pools to not be a top level object18:09
sbalukoffRight, but we can cross that bridge if we get forced, kicking and screaming, to go there.18:10
bloganim sure we can do some combination of both18:10
bloganinstead of pools, they'll be called GLOBAL_POOLS!!18:10
bloganor UNICORN_POOLS!!!18:10
xgermanBack to the ML where I am urged  to go back to OpenStack school...18:11
sbalukoffHmmm? I guess I need to catch up on that.18:12
bloganwhats up on the ML?18:13
xgermanI said I don't like sudden changes and I have been sent to "upstream training"18:14
bloganlol sounds like reducation camp18:15
xgermanyep, that's the offense I take :-)18:15
*** sbfox has quit IRC18:18
*** sbfox has joined #openstack-lbaas18:18
sbalukoffOh yeah, Stefano.18:22
sbalukoffThe same guy who wrote the blog article about how only developers should be submitting things to launchpad and gerrit.18:23
sbalukoffGreat guy. :P18:23
*** jschwarz has quit IRC18:38
*** sbfox has quit IRC18:47
*** ptoohill has joined #openstack-lbaas18:52
*** orion___ has joined #openstack-lbaas18:58
*** orion___ has quit IRC18:59
*** orion___ has joined #openstack-lbaas19:00
*** ptoohill has quit IRC19:00
*** orion__ has quit IRC19:02
*** orion__ has joined #openstack-lbaas19:03
*** orion___ has quit IRC19:03
*** sbfox has joined #openstack-lbaas19:11
*** markmcclain has quit IRC19:17
*** sbfox has quit IRC19:20
*** markmcclain has joined #openstack-lbaas19:50
*** VijayB_ has quit IRC19:50
*** VijayB has joined #openstack-lbaas20:22
*** orion__ has quit IRC20:25
*** orion__ has joined #openstack-lbaas20:26
*** orion__ has quit IRC20:30
*** orion__ has joined #openstack-lbaas20:30
*** Youcef has quit IRC20:44
*** mestery has joined #openstack-lbaas20:49
*** mestery has quit IRC20:49
*** mestery has joined #openstack-lbaas20:50
*** orion__ has quit IRC20:57
*** orion__ has joined #openstack-lbaas20:58
*** orion__ has quit IRC20:59
*** orion__ has joined #openstack-lbaas20:59
*** VijayB has quit IRC21:21
*** dlundquist has left #openstack-lbaas21:28
*** orion__ has quit IRC21:29
*** orion_ has joined #openstack-lbaas21:30
*** crc32 has quit IRC21:31
*** VijayB_ has joined #openstack-lbaas21:32
sbalukoffOctavia meeting agenda:  https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda21:33
*** orion_ has quit IRC21:34
*** crc32 has joined #openstack-lbaas21:35
*** crc32 has quit IRC21:35
*** mestery_ has joined #openstack-lbaas21:36
blogansbalukoff: I know we need some consensus on a few things, but I think creating the skeleton code/interfaces could be something we can do as action items per the last bullet point21:37
*** mestery has quit IRC21:37
bloganand actually writing implementations where it makes sense21:37
bloganif it makes sense21:38
bloganoh yeah this needs some +2s21:38
sbalukoffAlso, we should probably ask people to review your initial migrations (something I was going to do this afternoon.)21:38
sbalukoffThat. :)21:38
bloganthats not the migrations21:39
sbalukoffOh, not that.21:39
sbalukoffYes, you're right, that one does need some +2's.21:39
bloganbc the migration is a WIP and i'll be updating it based on what is decided in the meeting tomorrow21:39
sbalukoffOk, sounds good.21:39
sbalukoffWould you like me to add those items to the agenda, or do you want to do that?21:39
blogani'll let you do it21:39
sbalukoffSounds good!21:40
bloganwiki markup can rot in hell21:40
*** mestery_ is now known as mestery21:40
bloganbc there's 50,000 versions21:40
sbalukoffHaha! Indeed. I think this is mediawiki, though... so it's probably the most commonly used one.21:40
bloganwell when i've got 2 or 3 internal ones that are different, and one external...they all seem as commonly used21:41
sbalukoffhttps://review.openstack.org/#/c/113458/  --> That's the v0.5 design.21:45
sbalukoffI'd like to see this ratified in the next week or so so we have... less of a moving target that we can start coding. :)21:45
*** crc32 has joined #openstack-lbaas21:45
*** mestery has quit IRC21:45
*** mestery has joined #openstack-lbaas21:46
bloganfine by, as long as the expectation is that it did not cover the finer details and it is subject to change if crazy things crop up that we didn't think about21:47
bloganwhich im sure everyone is under the understanding21:47
sbalukoffYep, that's my understanding, eh.21:47
sbalukoffIt's also not set in stone... ratifying it is more of a good checkpoint to say "we think this is what it's going to look like" If someone has a major concern that comes up afterward, that doesn't mean we can't change it.21:48
sbalukoff(That'll be annoying, since we're trying to give everyone a window to comment... but it's not out of the question, eh.)21:48
sbalukoffdougwig: What are the interrim github repos for Octavia going to be used for?21:51
sbalukoff(Sorry, my git-fu is lacking, I know...  I'm not sure what the utility of this is if we have full control on merging patches.)21:52
sbalukoffLonger-term, more extensive branches?21:52
dougwigjust an idea, but we could pull the neutron lbaas v2 reviews into a few repos we control, and make it easier for people to pull down/setup/tweak.  get 'em out of gerrit.21:52
dougwigoctavia has stackforge, obviously.21:52
dougwigwe can always turn those repos into the new gerrit reviews for the incubator.21:53
sbalukoffAah... that's not a bad idea, eh.21:53
dougwigtalk to the driver vendors, get them all using that as well, merge in tls/l7/etc.21:53
sbalukoffPrior to getting into incubator?21:53
dougwigone sec, let me check something.21:54
sbalukoffOr as a place to (in effect) stage code before we send it to incubator and try to get core reviewer time for a merge?21:54
dougwigsomeplace to get our mo' back while we wait.  i just pinged kyle to check on timeframe, to see if it makes sense.21:55
dougwigwas a random thought for discussion.  not fully-baked.21:55
xgermandougwig: Just as a process remark we only merge things into Octavia hen tow cores +221:56
dougwigerr, did I +A accidentally?21:56
xgermanyou did it right and I am blind21:57
dougwigheh, ok.  you just read my mind, because since it was just typos, i *almost* +A'ed it directly.21:57
dougwigtechnically, you're supposed to wait 2-3 days between +2's as well, to give others time to comment.21:57
dougwigthough i don't think that matters in this case.21:58
sbalukoffI totally just merged it.21:58
dougwigalthough i guess the +2 doesn't have to wait, just the +A.  but it doesn't matter on a typos review.21:58
sbalukoffFWIW, I don't think we need to wait if it really is just typo fixes. :p21:58
*** mestery has quit IRC22:01
xgermanwell, I +2 it so you can merge whenever you are ready :-)22:01
sbalukoffAlso, I totally would not object if someone wants to flesh this out with more detail at some point: https://wiki.openstack.org/wiki/Octavia22:03
sbalukoff(Obviously, no rush.)22:03
sbalukoffSo here's a question for y'all:  When we arrive at conclusions to some of the "get consensus on" questions around implementation details, I would like to make sure these are docuemented somewhere. We will of course keep notes in the meeting minutes on these decisions, but thinking a year or two from now when we've made dozens of these kinds of decisions, I don't want to force newcomers to have to go through a year's worth22:15
sbalukoff of meeting minutes to try to piece together whether "decision A" was arbitrary, or whether we actually discussed it... in deciding whether it needs to change.22:15
sbalukoffI think this could potentially be documented either in the wiki, or right in the code repository itself.22:15
sbalukoffWhat do y'all think is the most appropriate place for this kind of stuff to be kept?22:16
openstackgerritA change was merged to stackforge/octavia: Hacking fixes in CONSTITUTION, ROADMAP, & HACKING  https://review.openstack.org/11473022:16
sbalukoff(I think the wiki is friendlier to edit, but, living as it does apart from the code, it more vulnerable to someone's gratuituous cleanup efforts and/or restructuring of wiki documentation.)22:17
*** HenryG_ has joined #openstack-lbaas22:17
sbalukoffWhat do y'all think?22:18
sbalukoff(I can make this another, hopefully brief, agenda item if y'all like. ;) )22:18
xgermanyeah, let's vote on it during the meeting22:18
sbalukoffWiki might also be friendlier place to put summary data like benchmark results in documenting the reason for a particular decision.22:19
*** HenryG has quit IRC22:19
xgermanwell, you cna also add rst files or similar to the source tree22:19
xgermanI have seen both working -- and don't really have a preference22:20
sbalukoffYep. That's true.22:21
dougwigsbalukoff: wiki.  it has a history button, and notifications.22:22
xgermanjenkins has a similar functionality :-)22:22
dougwigediting is a bit higher touch.22:22
dougwigand by a bit, i mean battleship sized.22:22
sbalukoffI'm indifferent to where we put this stuff. I only insist that we put it somewhere that people can find it. :)22:23
*** markmcclain has quit IRC22:26
*** mestery has joined #openstack-lbaas22:53
*** jorgem has quit IRC23:01
*** mestery_ has joined #openstack-lbaas23:02
*** mestery has quit IRC23:02
*** mestery_ has quit IRC23:07
*** mestery has joined #openstack-lbaas23:07
*** mestery has quit IRC23:12
*** mestery has joined #openstack-lbaas23:13
*** vjay5 has joined #openstack-lbaas23:14
*** vjay5 has quit IRC23:33
*** mestery has quit IRC23:41
*** HenryG_ is now known as HenryG23:42
*** mestery has joined #openstack-lbaas23:44
*** mestery has quit IRC23:45
*** crc32 has quit IRC23:49

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!