*** sbfox has quit IRC | 00:02 | |
*** xgerman has quit IRC | 00:03 | |
*** vivek-ebay has quit IRC | 00:03 | |
*** HenryG has quit IRC | 00:05 | |
*** markmcclain has quit IRC | 00:09 | |
*** markmcclain has joined #openstack-lbaas | 00:14 | |
*** mlavalle has quit IRC | 00:16 | |
*** markmcclain has quit IRC | 00:55 | |
*** markmcclain1 has joined #openstack-lbaas | 00:55 | |
*** markmcclain1 has quit IRC | 01:00 | |
*** woodster_ has quit IRC | 01:01 | |
*** VijayB has quit IRC | 01:14 | |
*** sbfox has joined #openstack-lbaas | 01:38 | |
*** HenryG has joined #openstack-lbaas | 01:56 | |
*** HenryG has quit IRC | 01:56 | |
*** HenryG has joined #openstack-lbaas | 01:58 | |
*** sbfox has quit IRC | 02:03 | |
*** xgerman has joined #openstack-lbaas | 02:49 | |
*** fnaval has quit IRC | 02:51 | |
*** xgerman has quit IRC | 02:56 | |
*** sbfox has joined #openstack-lbaas | 03:03 | |
*** sbfox has quit IRC | 03:08 | |
*** fnaval has joined #openstack-lbaas | 03:09 | |
*** vivek-ebay has joined #openstack-lbaas | 03:16 | |
*** sbfox has joined #openstack-lbaas | 03:38 | |
*** vivek-eb_ has joined #openstack-lbaas | 03:40 | |
*** vivek-ebay has quit IRC | 03:42 | |
*** amotoki_ has joined #openstack-lbaas | 03:56 | |
*** sbfox has quit IRC | 04:40 | |
*** sbfox has joined #openstack-lbaas | 04:41 | |
*** fnaval has quit IRC | 04:55 | |
*** vivek-eb_ has quit IRC | 06:03 | |
*** vjay9 has joined #openstack-lbaas | 06:42 | |
*** vjay9 has quit IRC | 07:06 | |
*** vjay9 has joined #openstack-lbaas | 07:20 | |
*** enikanorov has quit IRC | 09:22 | |
*** enikanorov has joined #openstack-lbaas | 09:30 | |
*** vjay9 has quit IRC | 10:25 | |
*** vjay9 has joined #openstack-lbaas | 10:47 | |
*** amotoki_ has quit IRC | 11:56 | |
*** woodster_ has joined #openstack-lbaas | 12:25 | |
*** mestery has joined #openstack-lbaas | 12:51 | |
*** fnaval has joined #openstack-lbaas | 13:02 | |
*** mestery has quit IRC | 13:10 | |
*** enikanorov_ has joined #openstack-lbaas | 13:23 | |
*** mestery has joined #openstack-lbaas | 13:26 | |
*** busterswt has quit IRC | 13:43 | |
*** busterswt has joined #openstack-lbaas | 13:55 | |
*** vjay9 has quit IRC | 14:25 | |
*** fnaval has quit IRC | 14:27 | |
*** sbfox has quit IRC | 15:19 | |
*** fnaval has joined #openstack-lbaas | 15:19 | |
*** sbfox has joined #openstack-lbaas | 15:24 | |
*** sbfox has quit IRC | 15:26 | |
*** mlavalle has joined #openstack-lbaas | 15:46 | |
*** vivek-ebay has joined #openstack-lbaas | 16:25 | |
*** vivek-ebay has quit IRC | 16:38 | |
*** sbfox has joined #openstack-lbaas | 16:54 | |
*** VijayB_ has joined #openstack-lbaas | 17:16 | |
dougwig | blogan: let's talk active/deferred and drivers. | 17:18 |
---|---|---|
*** vivek-ebay has joined #openstack-lbaas | 17:23 | |
blogan | dougwig okay | 17:23 |
dougwig | refresh 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 IRC | 17:32 | |
*** mlavalle has quit IRC | 17:36 | |
blogan | because every entity can be created independently | 17:38 |
blogan | so 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 entry | 17:38 |
blogan | and 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 state | 17:39 |
blogan | so the plugin can't make that decision, so the driver has to | 17:40 |
dougwig | so the part that makes it messy is the DEFERRED thing. | 17:40 |
blogan | i think its just the overall status management being left to the driver | 17:41 |
blogan | got a meeting ill bb in like 30 mins | 17:41 |
*** VijayB_ has joined #openstack-lbaas | 17:52 | |
dougwig | blogan: 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 |
blogan | well 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 drivers | 18:14 |
blogan | and 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 IRC | 18:21 | |
*** VijayB_ has joined #openstack-lbaas | 18:35 | |
*** VijayB_ has quit IRC | 18:47 | |
*** VijayB_ has joined #openstack-lbaas | 18:50 | |
*** Youcef has quit IRC | 18:54 | |
*** jorgem has joined #openstack-lbaas | 18:56 | |
*** markmcclain has joined #openstack-lbaas | 19:01 | |
*** mestery has quit IRC | 19:05 | |
*** mestery has joined #openstack-lbaas | 19:11 | |
*** sbfox has quit IRC | 19:20 | |
*** VijayB_ has quit IRC | 19:21 | |
*** vivek-ebay has quit IRC | 19:21 | |
sbalukoff | http://tsdr.uspto.gov/documentviewer?caseId=sn86319369&docId=EXA20141003#docIndex=0&page=1&tdrlink= | 19:23 |
sbalukoff | I 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 |
dougwig | blogan: 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 |
dougwig | mostly i'm trying to remember where we left it and what our consensus was. | 19:30 |
*** VijayB_ has joined #openstack-lbaas | 19:32 | |
*** VijayB_ has quit IRC | 19:46 | |
*** sbfox has joined #openstack-lbaas | 19:56 | |
*** VijayB_ has joined #openstack-lbaas | 20:07 | |
blogan | dougwig: you mean provisioning status? | 20:10 |
blogan | in octavia? | 20:11 |
dougwig | no, this is all neutron/lbaas i'm talking about | 20:20 |
*** VijayB_ has quit IRC | 20:23 | |
blogan | ah so a pool with ACTIVE status that is only a db entity does make sense to you? | 20:26 |
dougwig | it 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 |
blogan | i 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 better | 20:31 |
dougwig | you 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 |
blogan | i get that, but from a user perspective, what is the point of a pool without load balancer? | 20:33 |
blogan | what functionality does it serve | 20:33 |
blogan | i.e., the provisioning status would be reflected in the provisioning status of the listener and/or load balancer that pool is connected with | 20:34 |
dougwig | hmm, 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 |
dougwig | the purpose is the admin/support (provision) vs the end user (operational). | 20:35 |
blogan | well 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 |
dougwig | let 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 |
blogan | so 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 |
blogan | the status of the listener? | 20:40 |
dougwig | yes, 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 remained | 20:42 |
dougwig | dumb about deferred. | 20:42 |
dougwig | as in, keep your current scheme, but hide the code from the drivers. | 20:43 |
*** jorgem has quit IRC | 20:43 | |
blogan | yeah 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 simplicity | 20:44 |
blogan | but is something we can revisit and implement again | 20:44 |
blogan | however, i need to look at that code again to see if it would be something that every driver can use | 20:45 |
blogan | though 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 that | 20:46 |
dougwig | i'm not worried about status management at the driver level; just if it's too complex and thus will never be right. | 20:46 |
blogan | i know, i still am obviously | 20:47 |
dougwig | do 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 |
blogan | yeah ive struggled with an answer to that, because its a lot to consider | 20:49 |
blogan | though 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 changes | 20:50 |
blogan | once it is merged in though, it should be set | 20:50 |
blogan | at least the workflow for drivers shouldn't change drastically | 20:51 |
blogan | at least thats my opinion | 20:52 |
blogan | we then run the risk of takign too much time for it to be merged into kilo | 20:52 |
blogan | though i don't think it will take too long once we have a concrete plan | 20:52 |
*** VijayB_ has joined #openstack-lbaas | 20:53 | |
*** VijayB_ has quit IRC | 20:57 | |
*** VijayB_ has joined #openstack-lbaas | 21:01 | |
*** vivek-ebay has joined #openstack-lbaas | 21:04 | |
*** VijayB_ has quit IRC | 21:05 | |
dougwig | well, 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 |
dougwig | the current chain is not at all fair to you | 21:08 |
*** sbfox has quit IRC | 21:11 | |
*** jorgem has joined #openstack-lbaas | 21:13 | |
*** mlavalle has joined #openstack-lbaas | 21:16 | |
*** sbfox has joined #openstack-lbaas | 21:21 | |
*** sbfox has quit IRC | 21:23 | |
*** jorgem has quit IRC | 21:27 | |
*** VijayB_ has joined #openstack-lbaas | 21:28 | |
*** VijayB_ has quit IRC | 21:32 | |
blogan | i dont mind it, but it woudl be nice to have more people understand the code base to understand all the little issues that pop up | 21:36 |
blogan | and more people involved in the decision making because I always wonder if I am making the right decision | 21:37 |
dougwig | i'm just sick of gerrit chains. it slows everything down | 21:41 |
blogan | me too | 21:41 |
blogan | but its happening in octavia too | 21:41 |
blogan | but at least there's visible progress on that | 21:41 |
*** vivek-ebay has quit IRC | 21:47 | |
*** vivek-ebay has joined #openstack-lbaas | 21:54 | |
rm_work | dougwig / 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 |
dougwig | rm_work: cool, ty | 22:16 |
*** VijayB_ has joined #openstack-lbaas | 22:24 | |
*** VijayB_ has quit IRC | 22:40 | |
sbalukoff | Thanks, rm_work | 22:44 |
*** VijayB_ has joined #openstack-lbaas | 22:47 | |
johnsom_ | Good stuff | 22:52 |
*** vivek-ebay has quit IRC | 23:08 | |
*** vivek-ebay has joined #openstack-lbaas | 23:08 | |
*** mlavalle has quit IRC | 23:22 | |
*** VijayB_ has quit IRC | 23:47 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!