| *** mlavalle has quit IRC | 00:10 | |
| *** sbfox has joined #openstack-lbaas | 00:25 | |
| *** sbfox has quit IRC | 00:28 | |
| *** vivek-ebay has joined #openstack-lbaas | 00:37 | |
| *** xgerman has quit IRC | 01:22 | |
| *** Putns has quit IRC | 01:50 | |
| *** vivek-ebay has quit IRC | 01:57 | |
| openstackgerrit | Merged openstack/neutron-lbaas: Merge feature/lbaasv2 https://review.openstack.org/141247 | 02:20 |
|---|---|---|
| *** sbfox has joined #openstack-lbaas | 02:28 | |
| *** woodster_ has quit IRC | 02:40 | |
| *** sbfox has quit IRC | 02:56 | |
| *** sbalukoff has quit IRC | 03:03 | |
| dougwig | woohoo ^^ | 03:19 |
| *** chlong has quit IRC | 03:41 | |
| *** chlong has joined #openstack-lbaas | 03:42 | |
| *** chlong has quit IRC | 03:42 | |
| *** chlong has joined #openstack-lbaas | 03:44 | |
| *** chlong has quit IRC | 03:48 | |
| *** chlong has joined #openstack-lbaas | 03:48 | |
| *** woodster_ has joined #openstack-lbaas | 04:13 | |
| *** rm_work|away is now known as rm_work | 04:18 | |
| *** rm_work is now known as rm_work|away | 04:24 | |
| *** sbfox has joined #openstack-lbaas | 04:35 | |
| *** sbfox has quit IRC | 04:51 | |
| blogan | yay! | 05:21 |
| *** sbfox has joined #openstack-lbaas | 05:24 | |
| *** sbfox has quit IRC | 05:42 | |
| *** amotoki has joined #openstack-lbaas | 05:53 | |
| *** sbfox has joined #openstack-lbaas | 05:57 | |
| openstackgerrit | Merged openstack/neutron-lbaas: Cleaned up requirements.txt https://review.openstack.org/142063 | 06:02 |
| *** woodster_ has quit IRC | 06:20 | |
| *** SumitNaiksatam has quit IRC | 06:41 | |
| *** kobis has joined #openstack-lbaas | 07:17 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 07:28 | |
| *** Miouge has joined #openstack-lbaas | 07:36 | |
| *** kobis has quit IRC | 08:00 | |
| *** kobis has joined #openstack-lbaas | 08:00 | |
| *** kobis has quit IRC | 08:00 | |
| *** kobis has joined #openstack-lbaas | 08:01 | |
| *** kobis has quit IRC | 08:02 | |
| *** kobis has joined #openstack-lbaas | 08:03 | |
| *** pcaruana|afk| is now known as pcaruana | 08:04 | |
| *** kobis has quit IRC | 08:05 | |
| *** kobis has joined #openstack-lbaas | 08:06 | |
| *** chlong has quit IRC | 08:07 | |
| *** jschwarz has joined #openstack-lbaas | 08:17 | |
| *** apuimedo has joined #openstack-lbaas | 08:29 | |
| *** kongfy has joined #openstack-lbaas | 08:33 | |
| *** jschwarz has quit IRC | 08:37 | |
| *** Putns has joined #openstack-lbaas | 08:41 | |
| *** jschwarz has joined #openstack-lbaas | 08:45 | |
| *** pcaruana has quit IRC | 08:59 | |
| *** sbfox has quit IRC | 09:03 | |
| *** pcaruana has joined #openstack-lbaas | 09:13 | |
| *** jschwarz has quit IRC | 09:34 | |
| *** sbalukoff has joined #openstack-lbaas | 09:39 | |
| *** kongfy has quit IRC | 09:50 | |
| *** x1b2j has quit IRC | 10:32 | |
| *** x1b2j has joined #openstack-lbaas | 10:33 | |
| *** chlong has joined #openstack-lbaas | 10:38 | |
| *** x1b2j has quit IRC | 10:53 | |
| *** x1b2j has joined #openstack-lbaas | 11:08 | |
| *** chlong has quit IRC | 11:08 | |
| *** amotoki has quit IRC | 11:12 | |
| *** woodster_ has joined #openstack-lbaas | 12:45 | |
| *** x1b2j has quit IRC | 13:08 | |
| *** markmcclain has joined #openstack-lbaas | 13:46 | |
| *** markmcclain has quit IRC | 13:47 | |
| *** kbyrne has quit IRC | 13:50 | |
| *** woodster_ has quit IRC | 14:50 | |
| *** kbyrne has joined #openstack-lbaas | 14:52 | |
| *** woodster_ has joined #openstack-lbaas | 15:01 | |
| openstackgerrit | Merged openstack/neutron-lbaas: Moved lbaas-haproxy.filters from main neutron repo https://review.openstack.org/142753 | 15:17 |
| *** dkingshott has joined #openstack-lbaas | 15:35 | |
| *** apuimedo has quit IRC | 15:54 | |
| *** markmcclain has joined #openstack-lbaas | 16:02 | |
| *** xgerman has joined #openstack-lbaas | 16:13 | |
| *** kobis has quit IRC | 16:17 | |
| *** kobis has joined #openstack-lbaas | 16:18 | |
| *** kobis has quit IRC | 16:22 | |
| xgerman | blogan, a2hill -- are you guys already in? | 16:29 |
| xgerman | couple of questions regarding our amphora | 16:30 |
| TrevorV | xgerman a2hill is out of the office today, and blogan hasn't really come in yet | 16:30 |
| TrevorV | He's on his way though | 16:30 |
| xgerman | 1) I think we don't want a cosntraint on LB -- an amphora can exist without an LB (e.g. if she is build or in error state) | 16:30 |
| xgerman | TrevorV thanks | 16:30 |
| TrevorV | No prob :) | 16:30 |
| xgerman | 2) Would be what states we support... in particular do we do intermediate states like boot, etc. | 16:31 |
| xgerman | ping me when you guys get in or we can talk about that in the Octavia meeting later | 16:32 |
| TrevorV | meeting is at 2 pm right? | 16:32 |
| TrevorV | 2 pm CST | 16:32 |
| TrevorV | I mean | 16:32 |
| TrevorV | sorry | 16:32 |
| xgerman | yep 12 pm PST | 16:32 |
| xgerman | or PDT I always confuse the two | 16:33 |
| LinuxJedi | PST because you aren't in summer time (Daylight savings) any more | 16:33 |
| LinuxJedi | I typically use PT so that people don't get confused :) | 16:34 |
| xgerman | great idea -- I should do the same :-) | 16:34 |
| *** markmcclain has quit IRC | 16:34 | |
| *** markmcclain has joined #openstack-lbaas | 16:36 | |
| *** markmcclain has quit IRC | 16:36 | |
| *** barclaac has quit IRC | 16:36 | |
| *** markmcclain has joined #openstack-lbaas | 16:37 | |
| TrevorV | LinuxJedi I didn't know that was the difference. Interesting | 16:37 |
| TrevorV | I was looking it up a long time ago | 16:37 |
| TrevorV | Everything I saw online said "interchangeable" | 16:37 |
| *** markmcclain has quit IRC | 16:38 | |
| blogan | xgerman: ping | 16:45 |
| LinuxJedi | TrevorV: technically PST is Pacific Standard Time and PDT is Pacific Daylight Time, but I think it has become standard in the use to interchange them. In the UK there is a distinct difference between the names GMT and BST so we tend to remeber them. Plus I've programmed microcontrollers to read time data from radio clocks before so I get anal about it ;) | 16:45 |
| LinuxJedi | s/use/US | 16:46 |
| TrevorV | I'm totally okay with that LinuxJedi, glad to have the knowledge | 16:46 |
| TrevorV | I was just mentioning I was unable to find a difference, and was happy to see a difference defined :D | 16:47 |
| LinuxJedi | :) | 16:47 |
| xgerman | blogan Heya | 16:51 |
| blogan | xgerman: are you talking about a FK constraint? | 16:51 |
| xgerman | yep | 16:51 |
| xgerman | or more a not null | 16:51 |
| blogan | xgerman: that column is nullable | 16:51 |
| xgerman | mmh, it threw an exception when I nulled it :-( | 16:52 |
| xgerman | maybe I am on an old codebase... | 16:52 |
| blogan | did you run all the migrations? | 16:52 |
| blogan | yeah we have like 3 or 4 migrations | 16:52 |
| *** kobis has joined #openstack-lbaas | 16:52 | |
| xgerman | the code I saw looked like not null | 16:52 |
| blogan | i have a review that combines it all into one until we actually have a milestone version | 16:53 |
| blogan | but some don't like that, others do | 16:53 |
| *** sbfox has joined #openstack-lbaas | 16:54 | |
| xgerman | yeah, I am probably on an old branch -- likely need to rebase. | 16:54 |
| xgerman | Any thoughts on states -- do we want to be granular like boot, etc. | 16:54 |
| blogan | xgerman: well its been in there for a while, im double checking though | 16:54 |
| xgerman | cool - thanks | 16:55 |
| blogan | xgerman: also about the states, the amphora states have not been fully enumerated and I suspect it will evolve over time | 16:55 |
| xgerman | ok, I just don't want to make stuff which is nova informed and doesn't make any sense with containers | 16:56 |
| blogan | xgerman: yep i can do it | 16:56 |
| xgerman | awesome | 16:56 |
| blogan | xgerman: yeah we can define our own | 16:56 |
| xgerman | well, we should probably then do more of a genera; state and then a substate based on container/nova/etc. | 16:57 |
| xgerman | ? | 16:57 |
| blogan | can you give an example? | 16:57 |
| xgerman | state: PENDING_CREATE, substate BOOT, BOOTED, Waiting_for_ping | 16:59 |
| *** rm_work|away is now known as rm_work | 17:00 | |
| blogan | xgerman: since amphora's arent going to be user facing, i don't see why we would have the general state | 17:01 |
| dougwig | xgerman: that's the same as the provisioning and operational status split that we did in the lbaas layer. | 17:01 |
| blogan | dougwig: i don't think we weould have that split with the amphora states | 17:02 |
| dougwig | i think xgerman is suggesting it, because honestly it makes sense in most places. | 17:02 |
| xgerman | yeah, I am more thinking along the lines that we need states which are the same for all amphora tecgs (e.g. ACTIVE) | 17:02 |
| xgerman | but then we might have states only nova has | 17:03 |
| blogan | well what are the chances we dont use nova? | 17:03 |
| blogan | i guess magnum | 17:03 |
| blogan | nvm | 17:03 |
| blogan | lol | 17:03 |
| blogan | or ironic | 17:03 |
| xgerman | yeah, it's more of a future proofing thing then anyhting... | 17:04 |
| blogan | specifically for amphora, what do we gain by having a general state that maps to many sub states? | 17:04 |
| blogan | readability? | 17:04 |
| xgerman | well, with my operator hat I won't to know if there a machines lingering in nova I need to delete | 17:05 |
| xgerman | so ERROR really doesn't cut it | 17:05 |
| xgerman | or PENDING_CREATE | 17:05 |
| blogan | xgerman: i mean dont have PENDING_CREATE, keep the more specific states | 17:06 |
| xgerman | yep, I can live with that | 17:07 |
| blogan | xgerman: okay fine with me, i think having a parent state that maps to many substates is overcomplicating it right now, just use the substates right now | 17:08 |
| blogan | xgerman: i do believe we will need an error_description field at some point too | 17:08 |
| xgerman | yep, absolutely | 17:08 |
| xgerman | I just wanted to make sure we are all on the same page | 17:09 |
| blogan | i believe so on this issue | 17:09 |
| *** rm_work is now known as rm_work|away | 17:09 | |
| blogan | on the taskflow coupling in the interface, you still haven't convinced me lol | 17:10 |
| blogan | nor have I you | 17:10 |
| xgerman | well, we can talk that through maybe at the meeting later... right now I am in another meeting :-) | 17:13 |
| *** jorgem has joined #openstack-lbaas | 17:14 | |
| blogan | xgerman: i was planning on it! | 17:14 |
| dougwig | just in case folks missed this milestone last night: Merged openstack/neutron-lbaas: Merge feature/lbaasv2 | 17:20 |
| xgerman | yeah!! | 17:20 |
| *** kobis has quit IRC | 17:38 | |
| sbalukoff | Morning, folks! | 17:55 |
| *** SumitNaiksatam has quit IRC | 17:56 | |
| dougwig | morning! | 18:15 |
| *** crc32 has joined #openstack-lbaas | 18:22 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 18:23 | |
| *** markmcclain has joined #openstack-lbaas | 18:26 | |
| *** markmcclain has quit IRC | 18:29 | |
| openstackgerrit | Carlos Garza proposed stackforge/octavia: Add nsCertType and ExtendedKey usage extensions to CertGenerator https://review.openstack.org/144670 | 18:42 |
| sbalukoff | Ok folks, I'm still trying to get back on my feet somewhat since the holidays. Please feel free to flesh out this agenda if you've got specific things you'd like to discuss: https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda | 18:51 |
| sbalukoff | Also, don't forget to fill out the weekly standup etherpad: https://etherpad.openstack.org/p/octavia-weekly-standup | 18:51 |
| jorgem | sbalukoff: Hey is there any info on the work items for the API Manager? Or did those not get hashed out yet? | 19:06 |
| sbalukoff | jorgem: I don't think those got hashed out yet. | 19:06 |
| jorgem | k | 19:06 |
| sbalukoff | jorgem: But I'm also playing catch-up here. | 19:06 |
| *** ajmiller has quit IRC | 19:15 | |
| dougwig | regarding the ML thread about octavia, wasn't it the HP folks that suggested not using Libra? | 19:30 |
| xgerman | yeah, we stand by that | 19:32 |
| xgerman | :-) | 19:32 |
| sbalukoff | Haha! | 19:33 |
| sbalukoff | LinuxJedi and xgerman: I take it y'all work in separate areas with essentially no overlap? | 19:33 |
| xgerman | sablukoff you posted the agenda for today anywhere | 19:33 |
| xgerman | yep, different departments | 19:33 |
| sbalukoff | xgerman: It's deceptively short: https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda | 19:34 |
| sbalukoff | Though I expect the "taskflow vs. not taskflow" discussion may take up most of the time anyway. | 19:34 |
| sbalukoff | Please feel free to add what you wish to this. | 19:34 |
| xgerman | cool | 19:35 |
| LinuxJedi | sbalukoff: xgerman works for HP Helion, I work for HP Advanced Technology Group | 19:35 |
| xgerman | also don't forget to update the standup page: https://etherpad.openstack.org/p/octavia-weekly-standup -- johnsom is doing that on our end | 19:35 |
| *** dank has joined #openstack-lbaas | 19:37 | |
| *** crc32 has quit IRC | 19:38 | |
| *** dkingshott has quit IRC | 19:41 | |
| TrevorV | sbalukoff afternoon! | 19:45 |
| *** jorgem has quit IRC | 19:47 | |
| *** crc32 has joined #openstack-lbaas | 19:47 | |
| dougwig | LinuxJedi: you hint that xml/soap is superior to json. egads, man. | 19:52 |
| LinuxJedi | in some ways it is, but it is still turd ;) | 19:52 |
| LinuxJedi | just like in some ways my Ford is superior to a Ferrari. A Ferrari on the roads around here would get stuck on the hump bridges :) | 19:53 |
| dougwig | the turdiness so overwhelms the good ideas that it's unspeakable. | 19:53 |
| dougwig | admittedly it's poor implementation on top of a crap encoding mechanism that killed it. | 19:54 |
| sbalukoff | Yeah.... XML should pretty much DIAF | 19:55 |
| LinuxJedi | I personally prefer YAML over XML, but it doesn't cover all use cases of XML unfortunately | 19:56 |
| *** ajmiller has joined #openstack-lbaas | 19:56 | |
| dougwig | in xml land, the only thing worse than soap is signed xml. | 19:56 |
| dougwig | diaf is too quick and painless for xml. | 19:56 |
| sbalukoff | HAHA | 19:56 |
| *** mwang2 has joined #openstack-lbaas | 19:57 | |
| eren | does xml still exist? | 19:58 |
| eren | :( | 19:58 |
| sbalukoff | eren: The web has ensured its immortality. | 20:00 |
| dougwig | when solving the serialization problems with automated tools exceeds doing it by hand, the technology has failed. which was soap's issue. i'm not sure protocol buffers will avoid that fate, unless the quality and ubiquity of the client generators becomes insanely high. | 20:00 |
| sballe | o/ | 20:00 |
| sbalukoff | Oh yes! Meeting time! | 20:00 |
| sbalukoff | #startmeeting Octavia | 20:00 |
| openstack | Meeting started Wed Jan 7 20:00:48 2015 UTC and is due to finish in 60 minutes. The chair is sbalukoff. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:00 |
| openstack | The meeting name has been set to 'octavia' | 20:00 |
| blogan | you're dong it in here? | 20:00 |
| sbalukoff | #topic Roll Call | 20:00 |
| blogan | shouldn't it be in the meeting channel? | 20:00 |
| xgerman | +1 | 20:01 |
| sballe | +1 | 20:01 |
| sbalukoff | #endmeeting | 20:01 |
| openstack | Meeting ended Wed Jan 7 20:01:09 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 20:01 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-01-07-20.00.html | 20:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-01-07-20.00.txt | 20:01 |
| blogan | yes short meeting | 20:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-01-07-20.00.log.html | 20:01 |
| sbalukoff | Sorry, got a little over-excited there. | 20:01 |
| *** rm_work|away is now known as rm_work | 20:01 | |
| blogan | quick on the trigger | 20:01 |
| sballe | lol | 20:01 |
| rm_work | T_T | 20:01 |
| eren | drew it too fast | 20:01 |
| *** jorgem has joined #openstack-lbaas | 20:01 | |
| blogan | its -alt right? | 20:02 |
| sbalukoff | Yeah. | 20:02 |
| eren | ok, what's the meeting channel? | 20:04 |
| blogan | openstack-meeting-alt | 20:04 |
| sbalukoff | #openstack-meeting-alt | 20:04 |
| blogan | #^ | 20:04 |
| eren | thanks | 20:04 |
| bedis | morning | 20:07 |
| sbalukoff | Howdy, bedis! We're meeting in #openstack-meeting-alt | 20:12 |
| openstackgerrit | Al Miller proposed stackforge/octavia: Interface specification for housekeeping manager https://review.openstack.org/142633 | 20:31 |
| *** rm_work is now known as rm_work|away | 20:34 | |
| *** rm_work|away is now known as rm_work | 20:42 | |
| *** vivek-ebay has joined #openstack-lbaas | 20:55 | |
| a2hill | So, why will we be refactoring it to be tightly coupled in a year or so? | 21:01 |
| dougwig | i think that last vote was missing key stakeholders. | 21:01 |
| sballe | We continue here? | 21:01 |
| blogan | xgerman lets discuss this more | 21:01 |
| bedis | o/ | 21:01 |
| sbalukoff | dougwig: It definitely was | 21:01 |
| a2hill | What about when UltimegaTaskFlow comes out in a year and a half and we use that instead? | 21:01 |
| rm_work | Also my concern -- why would drivers even be aware of an "undo"? | 21:01 |
| rm_work | But that might not be related to this SPECIFIC discussion | 21:02 |
| rm_work | Just want my question/objection to be noted | 21:02 |
| sbalukoff | rm_work: Some drivers might need to do some very complicated stuff. | 21:02 |
| a2hill | because | 21:02 |
| a2hill | :P | 21:02 |
| bedis | an undo is just a do with parameters before last update :) | 21:02 |
| sbalukoff | This might mean that we're essentially embedding some state information in the driver. | 21:02 |
| blogan | indeed | 21:02 |
| sballe | I think xgerman and co had to leave for a team meeting. | 21:02 |
| a2hill | ^ +1 | 21:02 |
| sbalukoff | Which is bad. | 21:02 |
| xgerman | will be back in a few | 21:03 |
| sbalukoff | But might be unavoidable for some drivers. | 21:03 |
| rm_work | erk, k | 21:03 |
| rm_work | that was my objection | 21:03 |
| rm_work | drivers shouldn't have state info | 21:03 |
| rm_work | and in that case, "undo_update" is "update" and "undo_delete" is "create" | 21:03 |
| rm_work | etc | 21:03 |
| a2hill | Then we would either need to have much driver specific logic in the controller defined by the driver writer, OR have taskflow coupled to the driver | 21:03 |
| a2hill | That was only a suggestion to get around both of those issues | 21:04 |
| blogan | well the need for undos is an argument outside of this, bc tightly coupling taskflow in the drivers or not would also have undo methods | 21:04 |
| xgerman | ok, back - meeting was quick | 21:04 |
| sbalukoff | The most interesting thing about this discussion to me is that it seems to hinge around making things easier for driver writers to do complicated things. Yet dougwig (vendor) is against this. Maybe that should be telling? Let's not worry about solving for stupid implementations we can't predict and do what we would want for the reference? | 21:04 |
| rm_work | anyway, I think that might not be relevant to THIS discussion, I just didn't want "I agree with that gist" to imply that I agreed with driver-undo implicitly | 21:04 |
| *** openstackgerrit has quit IRC | 21:05 | |
| a2hill | I guess im at the point that i would prefer to have it decoupled, but if there is more limitations then not and its going to take much more time coming to a consensus I am fine with having taskflow coupled | 21:05 |
| *** openstackgerrit has joined #openstack-lbaas | 21:06 | |
| xgerman | I am all for decoupled | 21:06 |
| sbalukoff | xgerman: You are confusing me, man! | 21:06 |
| xgerman | but I also like to have the taskflow stuff available if needed for some of the things in the nova driver | 21:06 |
| blogan | xgerman: what do you mean? | 21:06 |
| xgerman | sbalukoff, decoupling for me means returning an OctaviaFlow | 21:07 |
| sbalukoff | xgerman: Any reason that driver writers can't do task flow stuff within their methods if they want? | 21:07 |
| a2hill | we couldnt the driver still do taskflows and the controller 'task' just call the method that has its own taskflow flows defined? | 21:07 |
| rm_work | xgerman: that still sounds pretty coupled to me | 21:07 |
| a2hill | what sbalukoff said :P | 21:07 |
| a2hill | yea, but its a choice in that case | 21:07 |
| a2hill | oh, didnt see xgermans line there. In that case yea its still coupled | 21:08 |
| rm_work | Answer the question: "would this driver still work if the whole of Taskflow disappeared tomorrow?" If the answer is "no", it's coupled | 21:08 |
| a2hill | in the gist, the answer is yes | 21:09 |
| xgerman | for each task in OctaviaFlow call execute... | 21:09 |
| sbalukoff | rm_work: That then excludes drivers from calling their own taskflow methods if they want to. | 21:09 |
| rm_work | a2hill: right, but for what xgerman is saying, the answer is no | 21:09 |
| a2hill | yep | 21:09 |
| rm_work | sbalukoff: is there a good reason they need to? | 21:09 |
| xgerman | well, in nthe nova case tou might boot and then have anither task poll, and then another one verifu your ntework is plugged ok | 21:10 |
| rm_work | sbalukoff: also I don't think that's true | 21:10 |
| blogan | sbalukoff: it doesn't, the drivers can still use taskflow if they want | 21:10 |
| sbalukoff | rm_work: My note was probably more pedantic than a real objection. What I'm saying is, the question is "Would this driver still work if in "octavia core" we stopped using taskflow tomorrow?" | 21:10 |
| a2hill | blogan +1 | 21:10 |
| rm_work | sbalukoff: lol ok | 21:10 |
| rm_work | fine | 21:10 |
| rm_work | that is the correct question | 21:11 |
| sbalukoff | xgerman: How to you see OctaviaFlow and Taskflow differing? | 21:11 |
| bedis | you can't ask the driver writter to rewrite their driver all the time ;) | 21:11 |
| sbalukoff | bedis: You are correct. | 21:11 |
| xgerman | sbalukoff for now it would be a thin layer but if we go to something else I would just adapt it accodringly | 21:12 |
| a2hill | https://gist.github.com/the2hill/34040ec123fccb6def0b | 21:12 |
| sbalukoff | xgerman: So it's essentially just another layer of abstraction. | 21:13 |
| xgerman | taskflow basiclaly is a c;ass with an undo and execute method | 21:13 |
| crc32 | xgerman is probably refering to OctaviaFlow being an abstract class | 21:13 |
| xgerman | yep | 21:13 |
| blogan | so lets take the network driver methods for example | 21:14 |
| xgerman | ok | 21:14 |
| sbalukoff | dougwig: Isn't that essentially what you had suggested? | 21:14 |
| sbalukoff | (Still trying to figure out if we're violently agreeing here.) | 21:14 |
| blogan | how would the driver code look with the OctaviaFLow class? | 21:14 |
| dougwig | xgerman: for your nova example, maybe one call that does all those things is too large a bite? | 21:15 |
| blogan | sbalukoff: me too, but I think we have disagreemnts on the method of decoupling | 21:15 |
| sballe | sbalukoff: lol | 21:15 |
| dougwig | sbalukoff: i think if that's really all the class is doing, then we're largely down to a syntactic argument, which likely has less value to argue about. whether you call VipCreate.execute or "create_vip" in the controller's flow is largely irrelevant. | 21:16 |
| sbalukoff | blogan: Right. So let's wheedle out these differences. | 21:16 |
| xgerman | dougwig +1 | 21:16 |
| sbalukoff | dougwig: Agreed. | 21:16 |
| sbalukoff | dougwig: So... what color are we painting this bike shed again? | 21:16 |
| sbalukoff | ;) | 21:17 |
| xgerman | blue | 21:17 |
| a2hill | https://gist.github.com/the2hill/34040ec123fccb6def0b This is updated to what could be done if taskflow is still wanted/needed inside the driver. Which could just be subclassed from Octaviaflow | 21:17 |
| a2hill | I may have completely lost myself on where this debate is going | 21:17 |
| blogan | a2hill: you have | 21:17 |
| a2hill | >< | 21:17 |
| sbalukoff | a2hill: Welcome to the club. Try the sandwiches. | 21:17 |
| dougwig | why we would use the much more verbose class/execute() syntax is a question style (blech), but i'm not going to go crazy. | 21:17 |
| dougwig | question of style | 21:18 |
| blogan | dougwig: i agree, but at least it decouples us from taskflow | 21:18 |
| a2hill | Tasty mmmm | 21:18 |
| sbalukoff | dougwig: Sorry, I didn't mean the bikeshedding comment to be aimed specifically at you | 21:18 |
| xgerman | well, classes save us from noops if undo is not needed | 21:19 |
| sbalukoff | I also agree we want consistency in the various parts of the controller on this: I don't want to just leave this one up to the implementer, eh. | 21:19 |
| xgerman | yeah, I am aiming for consistency, too | 21:20 |
| dougwig | xgerman: not making the undo's abstract also solves that. :) | 21:20 |
| dougwig | sbalukoff: is ok, i have lots of excess paint. | 21:24 |
| sbalukoff | :) | 21:26 |
| blogan | so is the argument now whether we use classes for each "task" or use methods for each task? | 21:27 |
| blogan | and those classes are not inheriting from taskflow at all, though probably from a base class | 21:28 |
| xgerman | well, it would make my life easier if they inherit from taskflow :-) | 21:28 |
| xgerman | then I just add them to the flow | 21:29 |
| *** jorgem has quit IRC | 21:30 | |
| blogan | but wrapping them in a Taskflow.Task is pretty trivial in the layer above, same if they are just methods | 21:30 |
| dougwig | eh, versus wrapping them and adding. that's gotta be like 4 lines of code we're down to debating. :) | 21:31 |
| sballe | dougwig: +1 | 21:31 |
| xgerman | so let's summarize then: | 21:38 |
| xgerman | 1) We want drivers to be simple and synchronous | 21:38 |
| xgerman | 2) We don't want drivers to know about taskflow and if they need to implement flows they should get their own flow engine | 21:38 |
| sbalukoff | --> Which might be taskflow, but we're not dictating that or anything else. | 21:39 |
| sbalukoff | Also, I think 2 is better stated: We don't want drivers to have to return flows. If they they need to implement flows in their methods, they can use whatever flow engine they like. We're not picky. | 21:41 |
| sbalukoff | What I'm getting out of this is that the driver interface should always be synchronous, even if some methods take a long time to execute. | 21:42 |
| sbalukoff | Anyone disagree with that? | 21:43 |
| xgerman | no that's fine | 21:43 |
| sbalukoff | Also, in the controller we will definitely be using taskflow at this time-- but again, we're not forcing driver writers to know anything about it. | 21:44 |
| sbalukoff | Are we agreed on that as well? | 21:44 |
| xgerman | I am not so sure on that one -- ML2 is now forcing driver writers to use taskflow because letting them do their own thing caused problems | 21:45 |
| sbalukoff | It seems to me that if we're strict on requiring all driver methods to be synchronous it's not a problem. | 21:45 |
| dougwig | i'm not sure a neutron wip is really an authoritative source here. | 21:46 |
| dougwig | or is it out of wip with +2 approvals? | 21:46 |
| blogan | xgerman: im not saying the drivers have to be synchronous either | 21:47 |
| sbalukoff | blogan: Dammit, man! | 21:47 |
| blogan | i dont know why that woudl be a requirement! | 21:47 |
| blogan | lol sorry | 21:48 |
| xgerman | so we basically only don't want ot us etaskflow in the driver | 21:48 |
| blogan | we dont want to expect taskflow to be used in teh driver, people writing their own drivers are free to do whatever they want | 21:48 |
| xgerman | and otherwise it's free 4 all | 21:48 |
| sbalukoff | blogan: If the same method for one driver is synchronous, and for another is asynch, won't that lead to problems in a flow being run by the controller? | 21:48 |
| *** jorgem has joined #openstack-lbaas | 21:49 | |
| blogan | not if we run the driver method asynchronously, as in we just kick it off and keep going, if the method is synchronous or async doesn't matter | 21:49 |
| xgerman | usually async methods need to update our database | 21:50 |
| sbalukoff | blogan: What if a subsequent task in the flow must be done serially (ie. after some previous method is finished executing)? | 21:50 |
| xgerman | which I despise | 21:50 |
| sbalukoff | xgerman: Agreed. | 21:50 |
| blogan | well i'd like to avoid drivers having access to the db, if possible, not sure if it is | 21:50 |
| sbalukoff | blogan: I think we all agree on that. | 21:51 |
| dougwig | blogan: there is a big different between saying that the interface is synchronous and saying you can't end-run that and do async anyway. don't muddle those. | 21:51 |
| dougwig | difference | 21:51 |
| blogan | sbalukoff: can you give an example? what kind of task? | 21:51 |
| dougwig | an asynchronous interface implies it can return "not ready yet, call again later" somehow. | 21:51 |
| sbalukoff | blogan: I want to push out a new haproxy config. It has a new member on a new subnet. I need to plumb the subnet. If I try to push / run the new haproxy config before I plumb that subnet it's going to fail. | 21:52 |
| xgerman | well, nova is asynchronous but it doesn't help us if the vm isn't booted -- so we are blocked on that and keep polling | 21:52 |
| *** crc32 has quit IRC | 21:52 | |
| dougwig | i'm 100% fine with stating that it's a synchronous interface, and there is fuckall nothing you can do if someone decides to write an agent and be async in their own way anyway. that is different that saying you support both sync and async. | 21:52 |
| sbalukoff | dougwig: +1 | 21:53 |
| xgerman | +1 | 21:53 |
| blogan | ok so this is a similar problem in neutron lbaas right? | 21:53 |
| sbalukoff | blogan: Er... I don't know? I think so? | 21:53 |
| blogan | drivers that accomplish their methods synchronously versus those that accomplish async | 21:53 |
| bedis | (( Guys, I'm going to submit proposition of a presentation for next openstack summit in Vancouver. "Cool haproxy tips you want to know" :) )) | 21:54 |
| blogan | well basically drivers that are agentified and those that arent | 21:54 |
| bedis | (( I count on your votes ;) )) | 21:54 |
| dougwig | yes, but taskflow is what eases the burdens there (don't make the rest call wait on a synchronous return, how to handle fallback) | 21:54 |
| sbalukoff | bedis: +1 And good luck! | 21:54 |
| blogan | actually taskflow doesnt do that for us, we still have to spawn the taskflow execution in a separate thread/process | 21:55 |
| dougwig | that's an implementation nit. :) | 21:55 |
| xgerman | well, taskflow aslo saves states so if we crash we can just start where we left off | 21:56 |
| xgerman | and things like that | 21:56 |
| *** TrevorV_ has joined #openstack-lbaas | 21:56 | |
| bedis | (( good night all )) | 21:56 |
| *** chlong has joined #openstack-lbaas | 21:56 | |
| sbalukoff | good night, bedis! | 21:56 |
| xgerman | bedis: good night | 21:56 |
| sbalukoff | xgerman: Are you saying that this is a tool written to solve these kinds of complicated flow problems? ;) | 21:57 |
| sbalukoff | Look, I don't think anyone is against using taskflow. | 21:57 |
| sbalukoff | Octavia is going to use it in the controller in any case. | 21:58 |
| sbalukoff | Right? | 21:58 |
| sbalukoff | We also know that we can't necessarily trust driver writers to understand the complexity of what we're trying to do in the Octavia controller-- and that complexity is going to increase a lot when we go to octavia v1.0 and v2.0 | 21:59 |
| xgerman | yep - I was just trying to summarize what we wanted | 21:59 |
| *** jorgem has quit IRC | 21:59 | |
| blogan | ok lets start of just saying every driver is synchronous | 21:59 |
| blogan | but yes taskflow in the controller is definitely what we should do | 21:59 |
| xgerman | has a synchromous imnterface as dougwig pointed out :-) | 21:59 |
| sbalukoff | blogan: Ok! | 21:59 |
| blogan | yes | 21:59 |
| dougwig | sbalukoff: i guarantee that most driver writers will want to learn/do the minimum and the GTFO. | 21:59 |
| sbalukoff | dougwig: Amazing, that's what I want to do, too! XD | 22:00 |
| sbalukoff | ;) | 22:00 |
| sbalukoff | So! | 22:00 |
| xgerman | I gotta run to anothe rmeeting | 22:00 |
| blogan | okay | 22:00 |
| sbalukoff | Ok. | 22:00 |
| sbalukoff | Here's what I'm thinking (when you get back): | 22:00 |
| blogan | so im going to assume I should change the network driver around for this | 22:01 |
| xgerman | and I undertand we can't force driver writers to their own luck | 22:01 |
| sbalukoff | 1. All driver interfaces are synchronous, even the methods that might take a long time to execute fully. | 22:01 |
| sbalukoff | 2. Drivers should not need to be aware of flows, although they are free to use them themselves. | 22:01 |
| sbalukoff | 3. ... profit? | 22:01 |
| blogan | 3. Beat sbalukoff | 22:02 |
| TrevorV_ | 3. a) with a stick first | 22:02 |
| blogan | profit | 22:02 |
| TrevorV_ | 3. b) then with a bat | 22:02 |
| sbalukoff | So, I'm not hearing a compelling reason to use an abstract base class here, or have drivers return anything that looks like a flow. | 22:02 |
| sbalukoff | (er... a class which abstracts out flows.) | 22:03 |
| *** chlong has quit IRC | 22:03 | |
| blogan | well the reason to use an abstract base class is now whether we want to define all the tasks as methods in a single class or define the tasks as classes with execute and revert methods | 22:03 |
| sbalukoff | blogan: Ok, that's not as interesting to me. If you feel really strongly about that, please decide and let me know what color the shed is afterward. | 22:04 |
| sbalukoff | Anyway, the above gets us the following: | 22:04 |
| blogan | lol well you said you're not hearing a compelling reasonf or an abstract base class | 22:04 |
| sbalukoff | blogan: I used the wrong term. | 22:04 |
| blogan | ohhh lol | 22:04 |
| sbalukoff | Anyway, the above gets us the following: | 22:04 |
| sbalukoff | A. Driver writers need not have deep knowledge of controller internals. | 22:05 |
| sbalukoff | B. Driver writers are also not restricted in what they can do other than we expect all methods to be synchronous. (ie. if you need to wait for something to complete, please don't return until it's actually complete.) | 22:05 |
| *** jorgem has joined #openstack-lbaas | 22:06 | |
| sbalukoff | C. Octavia developers and driver writers alike have simplified interfaces that shouldn't need to change very often. | 22:06 |
| TrevorV_ | wait why the enforcement on synchronous? | 22:06 |
| TrevorV_ | For the flows to work properly? | 22:06 |
| sbalukoff | TrevorV_: Yes. | 22:07 |
| blogan | well i said above that i dont think that should be a requirement, but i can live with that now | 22:07 |
| TrevorV_ | Okay no problem just didn't read that earlier | 22:07 |
| blogan | we can improve in the future we need to | 22:07 |
| dougwig | once you pass runtime control to me, all your pesky rules are just guidelines. but that guidance will keep things simpler. | 22:07 |
| sbalukoff | blogan: Yes. Let's just get unblocked here and continue to work toward having an alpha people can deploy. We can't let fear of refactoring paralyze us. | 22:08 |
| blogan | totally agree | 22:08 |
| TrevorV_ | You're a refactor | 22:09 |
| *** markmcclain has joined #openstack-lbaas | 22:10 | |
| blogan | i do have a feeling though, that when i update the network driver interface there will be disagreements | 22:10 |
| TrevorV_ | (in this case it is fear of unnecessary refactor) | 22:10 |
| TrevorV_ | blogan, we can just link the chat log that includes the votes and make them shush :P | 22:10 |
| TrevorV_ | jp jp | 22:10 |
| sbalukoff | Heh! | 22:11 |
| blogan | no i still feel like we won't be on the same page, but I'm hopeful, I would like to get on the same page | 22:11 |
| blogan | and im sure i am not explaining myself well | 22:12 |
| sbalukoff | That's OK. I like to use the wrong terms to describe things, despite me being pedantic about this when I see it in other people's writing. | 22:13 |
| sbalukoff | This is partially because I'm an asshole. It 's also partially because sometimes there's a serious disconnect between brain and keyboard. | 22:13 |
| sbalukoff | Like now. | 22:13 |
| blogan | there's a serious disconnect between many parts of my brain | 22:13 |
| dougwig | just bring some code. | 22:16 |
| sbalukoff | :) | 22:18 |
| sbalukoff | Ok, I'mma be partially AFK for a bit. | 22:19 |
| *** sbfox has quit IRC | 22:19 | |
| *** mwang2 has quit IRC | 22:28 | |
| *** sbfox has joined #openstack-lbaas | 22:31 | |
| *** sbfox has quit IRC | 22:43 | |
| xgerman | dougwig: https://review.openstack.org/#/c/142569/ | 22:51 |
| xgerman | here is the code | 22:52 |
| xgerman | also our assumptions are: | 22:57 |
| xgerman | have another meeting catch you guys later | 22:58 |
| *** crc32 has joined #openstack-lbaas | 23:02 | |
| *** vivek-eb_ has joined #openstack-lbaas | 23:10 | |
| *** vivek-ebay has quit IRC | 23:10 | |
| openstackgerrit | Stephen Balukoff proposed stackforge/octavia: haproxy reference amphora API code https://review.openstack.org/145623 | 23:11 |
| sbalukoff | Woot! Got the first -1 on that review. | 23:13 |
| TrevorV_ | Heh | 23:14 |
| *** vivek-eb_ has quit IRC | 23:21 | |
| *** vivek-ebay has joined #openstack-lbaas | 23:21 | |
| *** chlong has joined #openstack-lbaas | 23:22 | |
| jorgem | johnsom: Heyo, I commented on https://review.openstack.org/#/c/136540/9/specs/version0.5/controller.rst if you want to take a look. Just trying to understand the API Manager component :) | 23:24 |
| johnsom | Ok, I will take a look | 23:25 |
| rm_work | johnsom: yeah, I was confused when I read that part too, might need a quick update -- I think the "deploy worker" thread is supposed to be called (and handle) every type of operation (CUD) not just Updates | 23:26 |
| rm_work | err | 23:26 |
| rm_work | *not just Creates | 23:26 |
| sbalukoff | Yeah, we called it 'deploy' worker on the whiteboard. | 23:34 |
| sbalukoff | But, I think this was before we figured out that each manager will need to spawn tasksflows occasionally. | 23:34 |
| sbalukoff | So, perhaps 'deploy worker' is a poor name. | 23:34 |
| crc32 | blogan: see my pm | 23:34 |
| crc32 | rm_you is blogan still in office? | 23:36 |
| rm_work | yes | 23:36 |
| rm_work | he is talking with Jorge | 23:36 |
| crc32 | could you slap him real quick. | 23:36 |
| xgerman | sbalukoff +1 it woill fire off a flow | 23:37 |
| rm_work | crc32: uhh he's at a whiteboard, i guess, what did you need? | 23:42 |
| rm_work | crc32: anything I could just get an answer from him quickly or does he really need to go read his IRC? | 23:42 |
| rm_work | sbalukoff: well, we called it a worker to distinguish it from a 'manager', which is a daemon, because the worker is just a thread | 23:43 |
| sbalukoff | rm_work: That works! | 23:43 |
| rm_work | xgerman: i don't know if it has to be flows? I am not sure why we'd bother doing that with flows | 23:43 |
| sbalukoff | (pun intended) | 23:43 |
| rm_work | sbalukoff: T_T | 23:43 |
| sbalukoff | rm_work: It doesn't strictly have to be a flow each time. But a lot of them will end up being flows. | 23:44 |
| rm_work | xgerman: I figure the API Manager reads from a queue, and spawns a deploy worker thread, for whatever action the queue specified -- then internally it might kick off flows | 23:44 |
| crc32 | I'm doing a change to "https://review.openstack.org/#/c/142915/" but when I type "git review" I get a merge conflict. | 23:44 |
| crc32 | crc@bitchslap:~/workspace/curr/neutron-lbaas$ git review | 23:44 |
| crc32 | Errors running git rebase -i remotes/gerrit/master | 23:44 |
| crc32 | error: could not apply b61ac93... Merge feature/lbaasv2 | 23:44 |
| crc32 | When you have resolved this problem, run "git rebase --continue". | 23:44 |
| crc32 | If you prefer to skip this patch, run "git rebase --skip" instead. | 23:44 |
| crc32 | To check out the original branch and stop rebasing, run "git rebase --abort". | 23:44 |
| crc32 | Could not apply b61ac93728fade2a6fbc003ba984edecb1cb106f... Merge feature/lbaasv2 | 23:45 |
| rm_work | but actually spinning up a deploy worker wouldn't need to come from a flow, seems like extra overhead/complexity than we need | 23:45 |
| crc32 | the conflict is on the file both modified: neutron_lbaas/db/loadbalancer/loadbalancer_db.py which isn't part of my change request. | 23:45 |
| rm_work | hmm | 23:45 |
| crc32 | its like its trying to rebase a dependency commit. | 23:45 |
| xgerman | rm_work I agree with sbalukoff some might be flows some aren't | 23:45 |
| rm_work | xgerman: hmm... k... i mean, what all spawns a deploy-worker thread? I was pretty sure it was ONLY the API Manager and maybe Health Manager? | 23:46 |
| xgerman | flows gives you a thread pool and some way to orchestrate among multiple workers/threads - so I would rather run a flow before spinning a worker | 23:46 |
| rm_work | I don't think either of those would gain anything from using flows | 23:46 |
| rm_work | xgerman: i was told TaskFlow *did not* handle threading | 23:47 |
| rm_work | and that if you wanted something to be run in a thread you still had to run taskflow in a thread manually | 23:47 |
| sbalukoff | rm_work: Some event will cause this. Could be an API command, or something spawned at regular intervals. Heck, a worker might even spawn another worker. | 23:47 |
| rm_work | because taskflow.execute() itself would block | 23:47 |
| xgerman | yep, but it will run on a threadpool | 23:47 |
| rm_work | sbalukoff: yeah but since what the deploy-worker will be doing will itself run taskflows, i don't see the advantage of using taskflow to run it | 23:48 |
| rm_work | seems kind of redundant | 23:48 |
| rm_work | and more complicated than necessary | 23:48 |
| sbalukoff | rm_work: Agreed. | 23:48 |
| rm_work | but i guess it technically would be up to whoever calls it <_< | 23:48 |
| rm_work | it's not like the deploy-worker code itself needs to be flow-aware for it to work | 23:48 |
| xgerman | well, ot really depends on the command | 23:48 |
| sbalukoff | Some things will need a task flow (probably most things, actually), others won't. | 23:49 |
| rm_work | crc32: i am checking currently | 23:49 |
| xgerman | sbalukoff +1 | 23:49 |
| crc32 | it looks like a commit was merged where sball just rearranged import statements. | 23:49 |
| rm_work | crc32: you're trying to rebase on top of 144832 right? | 23:50 |
| crc32 | not sure all I said was git review. The rebase is implied apparently | 23:50 |
| rm_work | looks like that is your dependency | 23:50 |
| rm_work | which itself relies on 144831 | 23:50 |
| rm_work | which is the thing which ACTUALLY has a merge conflict, I think | 23:50 |
| crc32 | so. | 23:51 |
| crc32 | "" | 23:51 |
| crc32 | ?? | 23:51 |
| rm_work | crc32: try `git review -R` | 23:51 |
| rm_work | err, and you might have to revert whatever rebasing it tried to do | 23:51 |
| rm_work | because it looks like it left you mid-rebase | 23:52 |
| openstackgerrit | Trevor Vardeman proposed stackforge/octavia: Author: Trevor Vardeman <trevor.vardeman@rackspace.com> https://review.openstack.org/145637 | 23:53 |
| crc32 | Whats the -R do? | 23:53 |
| openstackgerrit | Carlos Garza proposed openstack/neutron-lbaas: Common TLS utilities https://review.openstack.org/142915 | 23:53 |
| rm_work | no rebase | 23:53 |
| rm_work | TrevorV_: lol your commit message | 23:53 |
| openstackgerrit | Trevor Vardeman proposed stackforge/octavia: haproxy reference amphora API client https://review.openstack.org/145637 | 23:53 |
| crc32 | so did I just kick the problem down the road or is it ficed? | 23:53 |
| openstackgerrit | Trevor Vardeman proposed stackforge/octavia: haproxy reference amphora API client https://review.openstack.org/145637 | 23:54 |
| rm_work | crc32: the rebasing isn't "your problem", it's the problem of the person above you in the review chain | 23:54 |
| rm_work | crc32: so, kinda both | 23:54 |
| rm_work | crc32: you *can't* really fix it now yourself | 23:54 |
| rm_work | but you will probably have to do a rebase patchset later once brandon fixes his review | 23:54 |
| rm_work | that's one of the only real problems with large review chains | 23:55 |
| rm_work | *dependency chains | 23:55 |
| crc32 | Its the waterfall model. | 23:55 |
| *** TrevorV_ has quit IRC | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!