Thursday, 2014-07-31

*** sbfox has joined #openstack-lbaas00:01
*** fnaval has quit IRC00:06
*** sbfox has quit IRC00:07
*** xgerman_ has quit IRC00:09
dougwigoh, i'm in california.  that means bad things for the irc meeting time.00:37
dougwigbad things for me.00:37
dougwigblogan: is that push the last of them, or was that just a rebase fix?00:46
*** banix has joined #openstack-lbaas00:50
*** sbfox has joined #openstack-lbaas01:14
*** sbfox has quit IRC01:28
*** sbfox has joined #openstack-lbaas01:34
*** crc32 has quit IRC01:59
*** fnaval has joined #openstack-lbaas02:00
*** sbfox has quit IRC02:10
*** sbalukoff has quit IRC02:15
*** sbfox has joined #openstack-lbaas02:32
*** sbfox has quit IRC02:39
*** crc32 has joined #openstack-lbaas02:45
*** blogan_ has joined #openstack-lbaas02:54
*** woodster has joined #openstack-lbaas02:57
blogan_[M ?W03:08
*** crc32 has quit IRC03:22
*** fnaval has quit IRC04:06
*** HenryG is now known as HenryG_afk04:06
*** fnaval has joined #openstack-lbaas04:06
*** banix has quit IRC04:29
*** sbfox has joined #openstack-lbaas04:34
*** sbalukoff has joined #openstack-lbaas04:50
*** fnaval has quit IRC06:26
*** fnaval has joined #openstack-lbaas06:26
*** fnaval has quit IRC06:31
*** sbfox has quit IRC07:02
*** blogan_ has quit IRC07:15
*** woodster has quit IRC07:15
*** evgenyf has joined #openstack-lbaas07:58
*** banix has joined #openstack-lbaas10:44
*** banix has quit IRC11:42
*** woodster has joined #openstack-lbaas12:49
*** HenryG_afk is now known as HenryG12:49
*** HenryG has quit IRC13:02
*** fnaval has joined #openstack-lbaas13:24
*** banix has joined #openstack-lbaas13:30
*** banix has quit IRC13:31
*** banix has joined #openstack-lbaas13:32
*** banix has quit IRC13:34
*** crc32 has joined #openstack-lbaas13:36
*** banix has joined #openstack-lbaas13:38
*** fnaval has quit IRC13:51
*** xgerman_ has joined #openstack-lbaas13:51
*** fnaval has joined #openstack-lbaas13:51
sballe_mestery, morning13:52
mesterysballe_: howdy!13:53
sballe_mestery, What is the deadline for design session submissions?13:53
mesteryThose haven't opened up yet :)13:53
sballe_when do they open?13:53
sballe_and close :)13:53
*** fnaval has quit IRC13:56
mesteryNot until late September.13:57
*** jorgem has joined #openstack-lbaas13:58
*** xgerman_ has quit IRC13:58
*** xgerman has joined #openstack-lbaas13:58
*** rolledback has joined #openstack-lbaas14:01
*** HenryG has joined #openstack-lbaas14:43
*** Youcef has joined #openstack-lbaas14:50
sbalukoffI guess we do have eavesdropping bots recording everything that happens here, so the discussion won't be lost to the ether. :)15:01
bloganill be back in 1515:01
sbalukoffvjay isn't here.15:01
*** vjay has joined #openstack-lbaas15:01
sbalukoffThere he is!15:01
sbalukoffvjay: blogan says he'll be back in 15.15:01
*** jorgem1 has joined #openstack-lbaas15:03
*** fnaval has joined #openstack-lbaas15:04
*** jorgem has quit IRC15:05
*** fnaval has quit IRC15:07
*** fnaval has joined #openstack-lbaas15:08
*** jorgem1 has quit IRC15:12
*** banix has quit IRC15:12
*** fnaval has quit IRC15:13
bloganim back15:14
vjayhi blogan15:15
vjayI was checking THe latest update has changed the behaviour; The LBaaS extension updates the DB assuming the Driver operation is synchronous and the operation is complete when the driver call returns. This might not be the case for drivers like NetScaler, Radware etc. This is very useful for simple No-Op drivers.15:15
*** jorgem has joined #openstack-lbaas15:17
vjayblogan: are u t?15:19
*** mlavalle has joined #openstack-lbaas15:23
bloganvjay: sorry got pulled a way, give me a few mins15:30
*** rolledba_ has joined #openstack-lbaas15:31
*** rolledback has quit IRC15:31
bloganok vjay back15:39
vjayI was checking THe latest update has changed the behaviour; The LBaaS extension updates the DB assuming the Driver operation is synchronous and the operation is complete when the driver call returns. This might not be the case for drivers like NetScaler, Radware etc.15:40
bloganvjay changing it back to where the drivers update the status would solve this right?15:40
bloganokay, but sometime I'd like to solve it so the drivers don't have to have that responsibility, whether they're async or sync15:41
blogandoesn't have to be now15:41
bloganor juno15:41
vjaycorrect, agreed!15:41
bloganand its my fault for making an assumption that all the drivers that weren't using the agent were sync15:41
bloganbut its easy to revert15:41
*** banix has joined #openstack-lbaas15:42
vjaythe scenario tests in the V1 API understood this. It used to wait for the STATUS to be marked ACTIVE and then ran the tests15:42
blogannow this means right now the drivers have a lot of responsibility in changing entities to ACTIVE (which is the easy part) and changing them back to DEFERRED when they are unlinked for a loadbalancer entity (whcih is the hardest part)15:43
vjayhmm... the No-Op driver will act as a model driver for these cases?15:45
ptoohillvjay, the nonagent_namespace_driver wil be the reference that displays this behaviour15:47
vjayptoohill: thanks!15:48
bloganvjay: the noop driver should do this as well15:52
bloganand I'm thinking there should just be a plugin method that all drivers can call to automatically set everything to ACTIVE or set the entities that need to be changed to DEFERRED15:53
*** crc32 has quit IRC15:54
bloganbut drivers dont have to use it15:54
vjayblogan, makes sense15:54
bloganokay ill get on that, thanks vjay15:55
*** jorgem has quit IRC15:59
*** jorgem has joined #openstack-lbaas16:00
*** sbfox has joined #openstack-lbaas16:03
*** evgenyf has quit IRC16:16
*** crc32 has joined #openstack-lbaas16:18
*** sbalukoff has quit IRC16:34
*** rolledba_ has quit IRC16:38
dougwigmorning, sorry i missed the meeting.16:45
dougwigblogan answered this fine, but the noop driver should be a reference, and the minimum that any vendor needs (sort of a "just add your backend calls to this skeleton".)  it must result in ACTIVE objects and working CLI/API, or I'll consider it a bug.  the haproxy driver is a reference of something that actually makes those backend calls and can pass traffic.16:48
dougwigblogan: where are we at in terms of auto-ACTIVE/FAILED/DEFERRED, and sync vs async?16:48
*** fnaval has joined #openstack-lbaas16:53
dougwigi see going back to async, concur given objections.  and let's talk about whether automatically changing deferred makes sense.  i can see a few cases where it does not.16:53
*** fnaval has quit IRC16:56
*** banix has quit IRC16:56
*** fnaval has joined #openstack-lbaas16:57
*** banix has joined #openstack-lbaas17:00
*** fnaval has quit IRC17:01
*** vjay has left #openstack-lbaas17:07
blogandougwig: im just gonig to go back and let the drivers do the status management, since support both async and sync drivers will require work and time investments we don't enough of in juno17:29
blogandougwig: and then make that something we can address later, if we can do it in kilo great17:30
*** mestery has quit IRC17:31
*** mestery has joined #openstack-lbaas17:31
*** HenryG_ has joined #openstack-lbaas17:31
*** HenryG has quit IRC17:34
*** banix has quit IRC17:37
*** HenryG_ is now known as HenryG17:39
bloganany objections to that?17:40
*** banix has joined #openstack-lbaas17:40
*** banix has quit IRC17:43
*** banix has joined #openstack-lbaas17:43
dougwigok is dougwig code for 'no objections'.17:45
dougwigi'll put the noop fix back on my list.17:46
dougwiggiven that it was functionality removal, and some depend on it, it was clearly a bit premature.17:46
dougwigdoes this mean you retract yesterday's bowing down to my awesomeness?17:47
bloganno i bow down to my own failures17:51
*** sbfox has quit IRC17:56
dougwigwell, i was pushing for it as well.17:56
dougwigi'll share.17:56
blogani may add the code in the noop to set to active and deferred in this PS because I've already got tests that will test it17:59
*** sbalukoff has joined #openstack-lbaas18:00
*** sbalukoff has quit IRC18:00
*** sbfox has joined #openstack-lbaas18:02
*** Youcef has quit IRC18:05
*** rolledback has joined #openstack-lbaas18:19
*** jorgem1 has joined #openstack-lbaas18:28
*** sbalukoff has joined #openstack-lbaas18:29
*** jorgem has quit IRC18:30
sbalukoffProof that anyone can submit a talk idea to the OpenStack paris summit:
sbalukoffI think that one might even beat the UDP load balancing session19:03
*** banix has quit IRC19:05
*** fnaval has joined #openstack-lbaas19:11
*** sballe_ has quit IRC19:13
*** banix has joined #openstack-lbaas19:27
*** sbfox has quit IRC19:36
*** fnaval has quit IRC19:47
*** fnaval has joined #openstack-lbaas19:48
*** sbfox has joined #openstack-lbaas19:50
*** rolledback has quit IRC20:01
*** sbfox1 has joined #openstack-lbaas20:02
*** sbfox has quit IRC20:03
jorgem1sbalukoff: wow! really20:04
*** jorgem1 is now known as jorgem20:04
dougwigblogan: ok, sweet.20:16
crc32sbalukoff: This may be a late question but the SNI stuff is only for determining which certificate to return to the users browser right. Was there any intention of using it to select which back end pool was going to be used?20:26
crc32sbalukoff: for example SNI host should go to the toysrus pool while SNI host should go to some other pool.Is there anything that was supposed to be inplace to dictate which host goes to which pool cause other wise it sounds just like a Cert selector going to the same Application.20:28
*** sbfox has joined #openstack-lbaas20:28
*** sbfox1 has quit IRC20:29
ptoohillIn addition to what carlos has said, in the proposed tls spec and code review theres only a sni_container_ids object that is a list of barbican container ids. Unless im misunderstand how to configure haproxy with the additional certs I dont see this being useful at this point20:29
crc32Oh course my question is thinking beyond the scope of Juno and more interms of rencrypting.20:32
ptoohillmy question is more for the imediate work for the tls ref impl and its configurations20:35
*** fnaval has quit IRC20:36
*** fnaval has joined #openstack-lbaas20:36
*** fnaval has quit IRC20:41
*** fnaval has joined #openstack-lbaas20:53
johnsomIt seems like that could be covered by a layer 7 inspection of the HTTP request after the SSL is removed20:54
*** fnaval has quit IRC20:56
*** fnaval has joined #openstack-lbaas20:57
*** openstackgerrit has quit IRC21:01
*** fnaval has quit IRC21:01
*** openstackgerrit has joined #openstack-lbaas21:02
ptoohilljohnson, what im trying to get at is, with current spec/review all we have is sni_container_ids. we dont have any rules at this point. Im trying to understand what we are supposed to do with those certs without rules.21:07
ptoohillI think carlos has somewhat cleared up my confusion21:07
*** openstack has joined #openstack-lbaas21:08
*** fnaval has joined #openstack-lbaas21:13
*** banix has quit IRC21:32
*** mestery has quit IRC21:53
*** mestery has joined #openstack-lbaas21:54
sbalukoffcrc32 and ptoohill: Yes, and this will generally be accomplished using Layer 7 rules (this is how our proprietary load balancer product works today). So yes, without L7, SNI is less useful (though not totally useless-- a single pool could service multiple secure domains, so using SNI means you can do this while consuming fewer IPs).22:03
sbalukoffI haven't looked at any code that's written for this yet, but the spec should have also associated those sni_container_ids with a mandatory order, which will be used for hostname conflict resolution.22:04
sbalukoffptoohill: The existence (or non-existence) of L7 rules should not affect SNI functionality at all...22:05
sbalukoffSo I don't understand why you're saying "Im trying to understand what we are supposed to do with those certs without rules."22:05
sbalukoffWhat you do with them is put them in an SNI configuration so haproxy can choose the proper cert to use based on what the client asks for, according to the SNI protocol.22:06
sbalukoff(That exchange acutally happens right after the TCP session gets started, early in the handshaking process. This is waaaay before we've started speaking HTTP or any other protocol over the connection between client and server.)22:07
crc32sbalukoff: Yes but no mention of mappings to pools or anything. I think the question was more on the line of should an SNI entry be determining which backend pool was being used.22:08
sbalukoffcrc32: Aah! So the answer, from my perspective is: No, the L7 rules will do that.22:09
crc32IE SNI host should go to the toysrus members pool/backend.22:09
ptoohillgotcha, thanks for clarifying!22:09
sbalukoffRight, and the L7 rule would make that determination by examining the Host: http header.22:09
crc32ok so then SNI is just for selecting the correct certificate. The L7 rules later on down the road (Not slated for juno if I understood correctly).22:09
crc32Ok I was just verifying this was your expectation as well.22:10
sbalukoffI haven't looked closely at what parameters or variables are available to us in haproxy 1.5 yet, but I imagine selecting the backend pool would still fall solidly under the whole L7 functionality even there.22:10
crc32yea I just barely got interduced to the docs my self today.22:11
sbalukoffcrc32: I would love to see L7 get into Juno. But I'm having trouble wrangling engineering time to get it done in time.22:11
sbalukoff(Mostly, it's become apparent that we need to get Octavia bootstrapped, which is where my time has been lately.)22:11
ptoohillThat makes sense, think my questions were more unclear then my confusion ><, So thanks for the resonse!22:12
sbalukoffI'm pretty familiar with haproxy 1.4 functionality, as I was heavily involved in defining the templates for using it in our internal load balancer product. But this was before SSL functionality was cooked into haproxy. (We're doing SNI using stunnel there.)22:12
sbalukoffNo worries, eh!22:12
sbalukoffAlso, I'm a pretty terrible python coder, which is something I'm also working on correcting, though that won't happen overnight. :P22:13
ptoohillYea, it seems you do acls based off provided certs, then can determine which backend or node to server based on a match. I just wanted to verify that the spec wasnt assuming that we were doing what is essentailly L7 at this point.22:13
sbalukoff(our existing product is written in a combination of perl, shell, and ruby.)22:14
sbalukoffptoohill: Right. Yeah, leave that for L7.22:14
*** mestery has quit IRC22:22
*** mestery has joined #openstack-lbaas22:23
*** sbalukoff has quit IRC22:40
*** HenryG has quit IRC22:45
*** Pattabi has joined #openstack-lbaas22:52
*** jorgem has quit IRC22:53
Pattabihi <blogan>22:53
bloganPattabi: hey whats up, was hoping to see you22:54
Pattabiquick observation on the update_listener API for the case when default_pool_id is set to None22:54
Pattabiin the driver code, i observed that the old listener db object is not fully loaded22:55
bloganPattabi: we're not going the route of the plugin doing all the status management now, because it would cause major problems with other drivers22:55
Pattabiyes .. i read that in the IRC meeting minutes .. sorry i missed today's IRC call22:56
bloganPattabi: let me check that out about the update in the driver22:56
bloganI have not run into that issue22:57
Pattabifor example, old_listener_object.default_pool.listener seems to be None22:57
bloganah that could be because of some lazy loading issues22:58
bloganis there a reason you need to go back to listenr?22:58
Pattabiyes .. seems like lazy loading issue22:58
Pattabiwhen the default_pool_id is set to None as part of update_listener, I need to clean up/delete pool, healthmonitor and members on the device22:59
blogani get that, but default_pool is there right?23:00
bloganis healthmonitor and members not there?23:01
bloganmeaning old_listener.default_pool.healthmonitor23:01
Pattabifrom update_listener implementation, i invoke the methods delete_pool and delete_pool would in turn call delete_healthmonitor and delete_member ... these are the same apis that would get invoked when user delete pool or delete healthmonitor23:02
Pattabiyes .. thats my observation23:02
Pattabiactually i take it back ....23:03
Pattabiold_listener.default_pool.healthmonitor is avaialble23:03
bloganwhat about members?23:03
Pattabibut then old_listener.default_pool.healthmonitor.pool seems null23:03
Pattabiold_listner.default_pool.healthmonitor.pool.listener seems null23:04
Pattabimemebrs seem okay23:04
blogani think thats right because these are getting eager loaded, so when you try to go back up normally sqlalchemy would just do a select statement on the fly (lazy loading), but since its eager loaded it can't do that23:06
Pattabiyes .. thats the exception i see on the neutron log also ...23:07
Pattabibecause of this i cannot have a delete_pool taking a pool db object and do pool_db.listener.loadbalancer23:08
bloganbut i think its fine because you shouldn't need to go back up, because you've already got those references23:08
bloganahh i see23:09
bloganill try to do some tests on this tonight, or tomorrow and see if i can reproduce what you're seeing and if anywway around it23:10
Pattabii have for now implemented a private internale method _delete_pool for example taking loadbalancer as as additional parameter that i derive from the new_obj23:10
Pattabiand use this method to hnadle setting of defualt_pool_id to Null in the update_listener API23:10
Pattabii will also upload my code to my git and share the linkf or your referece23:11
bloganokay but i think it might just require you to have to make a db call to grab the loadbalancer23:11
Pattabiyes .. that's another option23:12
Pattabionly issue is that i cannot grab a loadbalancer from the healthmonitor object23:13
Pattabireason being, healthmonitor.pool will be None for the old object due to lazy loading23:14
bloganjust did a quick test, didn't run into that issue i coudl traverse down the tree and back up23:14
bloganill have to do some in depth testing tonight23:14
Pattabiok.. thanks blogan23:15
blogannp sorry for all the churn on this23:15
*** sbfox has quit IRC23:24
mlavalleblogan: you around?23:59

Generated by 2.14.0 by Marius Gedminas - find it at!