Friday, 2014-10-03

*** sbfox has quit IRC00:02
*** xgerman has quit IRC00:03
*** vivek-ebay has quit IRC00:03
*** HenryG has quit IRC00:05
*** markmcclain has quit IRC00:09
*** markmcclain has joined #openstack-lbaas00:14
*** mlavalle has quit IRC00:16
*** markmcclain has quit IRC00:55
*** markmcclain1 has joined #openstack-lbaas00:55
*** markmcclain1 has quit IRC01:00
*** woodster_ has quit IRC01:01
*** VijayB has quit IRC01:14
*** sbfox has joined #openstack-lbaas01:38
*** HenryG has joined #openstack-lbaas01:56
*** HenryG has quit IRC01:56
*** HenryG has joined #openstack-lbaas01:58
*** sbfox has quit IRC02:03
*** xgerman has joined #openstack-lbaas02:49
*** fnaval has quit IRC02:51
*** xgerman has quit IRC02:56
*** sbfox has joined #openstack-lbaas03:03
*** sbfox has quit IRC03:08
*** fnaval has joined #openstack-lbaas03:09
*** vivek-ebay has joined #openstack-lbaas03:16
*** sbfox has joined #openstack-lbaas03:38
*** vivek-eb_ has joined #openstack-lbaas03:40
*** vivek-ebay has quit IRC03:42
*** amotoki_ has joined #openstack-lbaas03:56
*** sbfox has quit IRC04:40
*** sbfox has joined #openstack-lbaas04:41
*** fnaval has quit IRC04:55
*** vivek-eb_ has quit IRC06:03
*** vjay9 has joined #openstack-lbaas06:42
*** vjay9 has quit IRC07:06
*** vjay9 has joined #openstack-lbaas07:20
*** enikanorov has quit IRC09:22
*** enikanorov has joined #openstack-lbaas09:30
*** vjay9 has quit IRC10:25
*** vjay9 has joined #openstack-lbaas10:47
*** amotoki_ has quit IRC11:56
*** woodster_ has joined #openstack-lbaas12:25
*** mestery has joined #openstack-lbaas12:51
*** fnaval has joined #openstack-lbaas13:02
*** mestery has quit IRC13:10
*** enikanorov_ has joined #openstack-lbaas13:23
*** mestery has joined #openstack-lbaas13:26
*** busterswt has quit IRC13:43
*** busterswt has joined #openstack-lbaas13:55
*** vjay9 has quit IRC14:25
*** fnaval has quit IRC14:27
*** sbfox has quit IRC15:19
*** fnaval has joined #openstack-lbaas15:19
*** sbfox has joined #openstack-lbaas15:24
*** sbfox has quit IRC15:26
*** mlavalle has joined #openstack-lbaas15:46
*** vivek-ebay has joined #openstack-lbaas16:25
*** vivek-ebay has quit IRC16:38
*** sbfox has joined #openstack-lbaas16:54
*** VijayB_ has joined #openstack-lbaas17:16
dougwigblogan: let's talk active/deferred and drivers.17:18
*** vivek-ebay has joined #openstack-lbaas17:23
blogandougwig okay17:23
dougwigrefresh my memory, where did we end up with the error-prone-ness of having everyone have to do all that deferred/active chain logic in each driver?17:24
*** VijayB_ has quit IRC17:32
*** mlavalle has quit IRC17:36
bloganbecause every entity can be created independently17:38
bloganso if you create a pool, and its not related to a load balancer, then it is in a deferred state because at that point its just a db entry17:38
bloganand since the plugin has to support async and sync drivers, it can't assume that once that pool is connected to a load balancer that it can automatically go to ACTIVE state17:39
bloganso the plugin can't make that decision, so the driver has to17:40
dougwigso the part that makes it messy is the DEFERRED thing.17:40
blogani think its just the overall status management being left to the driver17:41
blogangot a meeting ill bb in like 30 mins17:41
*** VijayB_ has joined #openstack-lbaas17:52
dougwigblogan: no worries no this going high latency.  well, it's a one line yes/no on the per object status.  it's not until we insist on not marking them active until it's "working" that it gets messier than that.  which is a change from v1, where you could have an ACTIVE pool that did nothing useful.17:55
bloganwell antoher reason is if we ever need to change a status, add a status, remove a status, we'd have to do that in all drivers18:14
bloganand an ACTIVE pool that did nothing doesn't make sense to me (which is why in octavia we dont have a provisioning status)18:15
*** VijayB_ has quit IRC18:21
*** VijayB_ has joined #openstack-lbaas18:35
*** VijayB_ has quit IRC18:47
*** VijayB_ has joined #openstack-lbaas18:50
*** Youcef has quit IRC18:54
*** jorgem has joined #openstack-lbaas18:56
*** markmcclain has joined #openstack-lbaas19:01
*** mestery has quit IRC19:05
*** mestery has joined #openstack-lbaas19:11
*** sbfox has quit IRC19:20
*** VijayB_ has quit IRC19:21
*** vivek-ebay has quit IRC19:21
sbalukoffI don't think that means it's official yet, but I do think it means "There are no conflicts, and nothing wrong with the application-- this will almost certainly become official once we have finished our paperwork."19:24
dougwigblogan: eh, i don't think i've ever agreed on that, mostly because we're likely thinking of two different definitions of that field.19:30
dougwigmostly i'm trying to remember where we left it and what our consensus was.19:30
*** VijayB_ has joined #openstack-lbaas19:32
*** VijayB_ has quit IRC19:46
*** sbfox has joined #openstack-lbaas19:56
*** VijayB_ has joined #openstack-lbaas20:07
blogandougwig: you mean provisioning status?20:10
bloganin octavia?20:11
dougwigno, this is all neutron/lbaas i'm talking about20:20
*** VijayB_ has quit IRC20:23
bloganah so a pool with ACTIVE status that is only a db entity does make sense to you?20:26
dougwigit does to me, simply because the model is one of building the pieces before tying them together.  this goes back to the mixing of provisioning and operational status, for sure.20:28
blogani suppose if pool only had an operating status, and it was set to OFFLINE until it was connected to a real load balancer, that woudl be better20:31
dougwigyou don't like provisioning status at all?   in an async world, there is a delay between the job being queued and the completed result.  how would we reflect that?20:32
blogani get that, but from a user perspective, what is the point of a pool without load balancer?20:33
bloganwhat functionality does it serve20:33
blogani.e., the provisioning status would be reflected in the provisioning status of the listener and/or load balancer that pool is connected with20:34
dougwighmm, so maybe if we had two statuses, we could let the plugin handle the operational side and the driver handle the provisioning side (and the changes to the provision state could trigger the plugin to handle the initial active on the operation side.)20:35
dougwigthe purpose is the admin/support (provision) vs the end user (operational).20:35
bloganwell how would the plugin handle the operational side if the driver is responsible for checking its own health monitoring system?  would the plugin expose a callback the driver calls?20:38
dougwiglet me reword that for clarity:  if we used two statuses in v2, we could keep drivers with the simple active/failed logic, and your more complicated (and useful) deferred stuff could be entirely contained within the plugin, keying off of whichever object changes made sense (i.e. the final LB creation.)20:38
bloganso if a user delete a load balancer that had a listener attached to it, the plugin woudl be responsible for changing that to deferred?20:40
bloganthe status of the listener?20:40
dougwigyes, it could plumb in that check as part of the delete call.  you know, i'm wondering if the logic that's currently all over the noop/haproxy driver couldn't be entirely contained with the simpler active()/failed()/db_delete() methods.  those things could be made object aware, and do all of this logic.  and it'd work async.  all while the drivers remained20:42
dougwigdumb about deferred.20:42
dougwigas in, keep your current scheme, but hide the code from the drivers.20:43
*** jorgem has quit IRC20:43
bloganyeah i believe i implemented a helper method in the plugin that automatically did it, but it became a logical nightmare, so I broke it up a bit for simplicity20:44
bloganbut is something we can revisit and implement again20:44
bloganhowever, i need to look at that code again to see if it would be something that every driver can use20:45
bloganthough it still is status management at the driver level, but I don't know how the operational status could be implemented without the driver managing that20:46
dougwigi'm not worried about status management at the driver level; just if it's too complex and thus will never be right.20:46
blogani know, i still am obviously20:47
dougwigdo we push to get this in and iterate?  or is the risk of someone starting a vendor driver too high in the interim?20:47
bloganyeah ive struggled with an answer to that, because its a lot to consider20:49
bloganthough since it is a feature branch, and if we iterate within the feature branch it should be acceptable that it is subject to some extreme changes20:50
bloganonce it is merged in though, it should be set20:50
bloganat least the workflow for drivers shouldn't change drastically20:51
bloganat least thats my opinion20:52
bloganwe then run the risk of takign too much time for it to be merged into kilo20:52
bloganthough i don't think it will take too long once we have a concrete plan20:52
*** VijayB_ has joined #openstack-lbaas20:53
*** VijayB_ has quit IRC20:57
*** VijayB_ has joined #openstack-lbaas21:01
*** vivek-ebay has joined #openstack-lbaas21:04
*** VijayB_ has quit IRC21:05
dougwigwell, if it we merge the current, someone else can more easily take a stab at iterating, too, instead of you being on the hook for everything.21:08
dougwigthe current chain is not at all fair to you21:08
*** sbfox has quit IRC21:11
*** jorgem has joined #openstack-lbaas21:13
*** mlavalle has joined #openstack-lbaas21:16
*** sbfox has joined #openstack-lbaas21:21
*** sbfox has quit IRC21:23
*** jorgem has quit IRC21:27
*** VijayB_ has joined #openstack-lbaas21:28
*** VijayB_ has quit IRC21:32
blogani dont mind it, but it woudl be nice to have more people understand the code base to understand all the little issues that pop up21:36
bloganand more people involved in the decision making because I always wonder if I am making the right decision21:37
dougwigi'm just sick of gerrit chains. it slows everything down21:41
bloganme too21:41
bloganbut its happening in octavia too21:41
bloganbut at least there's visible progress on that21:41
*** vivek-ebay has quit IRC21:47
*** vivek-ebay has joined #openstack-lbaas21:54
rm_workdougwig / sballe / sbalukoff / mestery / markmcclain / blogan: email thread started: "[Neutron] Barbican Integration for Advanced Services" with mostly the same content as before, but with slightly updated diagrams and slightly less text. :)22:11
dougwigrm_work: cool, ty22:16
*** VijayB_ has joined #openstack-lbaas22:24
*** VijayB_ has quit IRC22:40
sbalukoffThanks, rm_work22:44
*** VijayB_ has joined #openstack-lbaas22:47
johnsom_Good stuff22:52
*** vivek-ebay has quit IRC23:08
*** vivek-ebay has joined #openstack-lbaas23:08
*** mlavalle has quit IRC23:22
*** VijayB_ has quit IRC23:47

Generated by 2.14.0 by Marius Gedminas - find it at!