Wednesday, 2015-01-07

*** mlavalle has quit IRC00:10
*** sbfox has joined #openstack-lbaas00:25
*** sbfox has quit IRC00:28
*** vivek-ebay has joined #openstack-lbaas00:37
*** xgerman has quit IRC01:22
*** Putns has quit IRC01:50
*** vivek-ebay has quit IRC01:57
openstackgerritMerged openstack/neutron-lbaas: Merge feature/lbaasv2
*** sbfox has joined #openstack-lbaas02:28
*** woodster_ has quit IRC02:40
*** sbfox has quit IRC02:56
*** sbalukoff has quit IRC03:03
dougwigwoohoo ^^03:19
*** chlong has quit IRC03:41
*** chlong has joined #openstack-lbaas03:42
*** chlong has quit IRC03:42
*** chlong has joined #openstack-lbaas03:44
*** chlong has quit IRC03:48
*** chlong has joined #openstack-lbaas03:48
*** woodster_ has joined #openstack-lbaas04:13
*** rm_work|away is now known as rm_work04:18
*** rm_work is now known as rm_work|away04:24
*** sbfox has joined #openstack-lbaas04:35
*** sbfox has quit IRC04:51
*** sbfox has joined #openstack-lbaas05:24
*** sbfox has quit IRC05:42
*** amotoki has joined #openstack-lbaas05:53
*** sbfox has joined #openstack-lbaas05:57
openstackgerritMerged openstack/neutron-lbaas: Cleaned up requirements.txt
*** woodster_ has quit IRC06:20
*** SumitNaiksatam has quit IRC06:41
*** kobis has joined #openstack-lbaas07:17
*** SumitNaiksatam has joined #openstack-lbaas07:28
*** Miouge has joined #openstack-lbaas07:36
*** kobis has quit IRC08:00
*** kobis has joined #openstack-lbaas08:00
*** kobis has quit IRC08:00
*** kobis has joined #openstack-lbaas08:01
*** kobis has quit IRC08:02
*** kobis has joined #openstack-lbaas08:03
*** pcaruana|afk| is now known as pcaruana08:04
*** kobis has quit IRC08:05
*** kobis has joined #openstack-lbaas08:06
*** chlong has quit IRC08:07
*** jschwarz has joined #openstack-lbaas08:17
*** apuimedo has joined #openstack-lbaas08:29
*** kongfy has joined #openstack-lbaas08:33
*** jschwarz has quit IRC08:37
*** Putns has joined #openstack-lbaas08:41
*** jschwarz has joined #openstack-lbaas08:45
*** pcaruana has quit IRC08:59
*** sbfox has quit IRC09:03
*** pcaruana has joined #openstack-lbaas09:13
*** jschwarz has quit IRC09:34
*** sbalukoff has joined #openstack-lbaas09:39
*** kongfy has quit IRC09:50
*** x1b2j has quit IRC10:32
*** x1b2j has joined #openstack-lbaas10:33
*** chlong has joined #openstack-lbaas10:38
*** x1b2j has quit IRC10:53
*** x1b2j has joined #openstack-lbaas11:08
*** chlong has quit IRC11:08
*** amotoki has quit IRC11:12
*** woodster_ has joined #openstack-lbaas12:45
*** x1b2j has quit IRC13:08
*** markmcclain has joined #openstack-lbaas13:46
*** markmcclain has quit IRC13:47
*** kbyrne has quit IRC13:50
*** woodster_ has quit IRC14:50
*** kbyrne has joined #openstack-lbaas14:52
*** woodster_ has joined #openstack-lbaas15:01
openstackgerritMerged openstack/neutron-lbaas: Moved lbaas-haproxy.filters from main neutron repo
*** dkingshott has joined #openstack-lbaas15:35
*** apuimedo has quit IRC15:54
*** markmcclain has joined #openstack-lbaas16:02
*** xgerman has joined #openstack-lbaas16:13
*** kobis has quit IRC16:17
*** kobis has joined #openstack-lbaas16:18
*** kobis has quit IRC16:22
xgermanblogan, a2hill -- are you guys already in?16:29
xgermancouple of questions regarding our amphora16:30
TrevorVxgerman a2hill is out of the office today, and blogan hasn't really come in yet16:30
TrevorVHe's on his way though16:30
xgerman1) 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
xgermanTrevorV thanks16:30
TrevorVNo prob :)16:30
xgerman2) Would be what states we support... in particular do we do intermediate states like boot, etc.16:31
xgermanping me when you guys get in or we can talk about that in the Octavia meeting later16:32
TrevorVmeeting is at 2 pm right?16:32
TrevorV2 pm CST16:32
TrevorVI mean16:32
xgermanyep 12 pm PST16:32
xgermanor PDT I always confuse the two16:33
LinuxJediPST because you aren't in summer time (Daylight savings) any more16:33
LinuxJediI typically use PT so that people don't get confused :)16:34
xgermangreat idea -- I should do the same :-)16:34
*** markmcclain has quit IRC16:34
*** markmcclain has joined #openstack-lbaas16:36
*** markmcclain has quit IRC16:36
*** barclaac has quit IRC16:36
*** markmcclain has joined #openstack-lbaas16:37
TrevorVLinuxJedi I didn't know that was the difference.  Interesting16:37
TrevorVI was looking it up a long time ago16:37
TrevorVEverything I saw online said "interchangeable"16:37
*** markmcclain has quit IRC16:38
bloganxgerman: ping16:45
LinuxJediTrevorV: 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
TrevorVI'm totally okay with that LinuxJedi, glad to have the knowledge16:46
TrevorVI was just mentioning I was unable to find a difference, and was happy to see a difference defined :D16:47
xgermanblogan Heya16:51
bloganxgerman: are you talking about a FK constraint?16:51
xgermanor more a not null16:51
bloganxgerman: that column is nullable16:51
xgermanmmh, it threw an exception when I nulled it :-(16:52
xgermanmaybe I am on an old codebase...16:52
blogandid you run all the migrations?16:52
bloganyeah we have like 3 or 4 migrations16:52
*** kobis has joined #openstack-lbaas16:52
xgermanthe code I saw looked like not null16:52
blogani have a review that combines it all into one until we actually have a milestone version16:53
bloganbut some don't like that, others do16:53
*** sbfox has joined #openstack-lbaas16:54
xgermanyeah, I am probably on an old branch -- likely need to rebase.16:54
xgermanAny thoughts on states -- do we want to be granular like boot, etc.16:54
bloganxgerman: well its been in there for a while, im double checking though16:54
xgermancool - thanks16:55
bloganxgerman: also about the states, the amphora states have not been fully enumerated and I suspect it will evolve over time16:55
xgermanok, I just don't want to make stuff which is nova informed and doesn't make any sense with containers16:56
bloganxgerman: yep i can do it16:56
bloganxgerman: yeah we can define our own16:56
xgermanwell, we should probably then do more of a genera; state and then a substate based on container/nova/etc.16:57
blogancan you give an example?16:57
xgermanstate: PENDING_CREATE, substate BOOT, BOOTED, Waiting_for_ping16:59
*** rm_work|away is now known as rm_work17:00
bloganxgerman: since amphora's arent going to be user facing, i don't see why we would have the general state17:01
dougwigxgerman: that's the same as the provisioning and operational status split that we did in the lbaas layer.17:01
blogandougwig: i don't think we weould have that split with the amphora states17:02
dougwigi think xgerman is suggesting it, because honestly it makes sense in most places.17:02
xgermanyeah, I am more thinking along the lines that we need states which are the same for all amphora tecgs (e.g. ACTIVE)17:02
xgermanbut then we might have states only nova has17:03
bloganwell what are the chances we dont use nova?17:03
blogani guess magnum17:03
bloganor ironic17:03
xgermanyeah, it's more of a future proofing thing then anyhting...17:04
bloganspecifically for amphora, what do we gain by having a general state that maps to many sub states?17:04
xgermanwell, with my operator hat I won't to know if there a machines lingering in nova I need to delete17:05
xgermanso ERROR really doesn't cut it17:05
xgermanor PENDING_CREATE17:05
bloganxgerman: i mean dont have PENDING_CREATE, keep the more specific states17:06
xgermanyep, I can live with that17:07
bloganxgerman: 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 now17:08
bloganxgerman: i do believe we will need an error_description field at some point too17:08
xgermanyep, absolutely17:08
xgermanI just wanted to make sure we are all on the same page17:09
blogani believe so on this issue17:09
*** rm_work is now known as rm_work|away17:09
bloganon the taskflow coupling in the interface, you still haven't convinced me lol17:10
blogannor have I you17:10
xgermanwell, we can talk that through maybe at the meeting later... right now I am in another meeting :-)17:13
*** jorgem has joined #openstack-lbaas17:14
bloganxgerman: i was planning on it!17:14
dougwigjust in case folks missed this milestone last night: Merged openstack/neutron-lbaas: Merge feature/lbaasv217:20
*** kobis has quit IRC17:38
sbalukoffMorning, folks!17:55
*** SumitNaiksatam has quit IRC17:56
*** crc32 has joined #openstack-lbaas18:22
*** SumitNaiksatam has joined #openstack-lbaas18:23
*** markmcclain has joined #openstack-lbaas18:26
*** markmcclain has quit IRC18:29
openstackgerritCarlos Garza proposed stackforge/octavia: Add nsCertType and ExtendedKey usage extensions to CertGenerator
sbalukoffOk 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:
sbalukoffAlso, don't forget to fill out the weekly standup etherpad:
jorgemsbalukoff: Hey is there any info on the work items for the API Manager? Or did those not get hashed out yet?19:06
sbalukoffjorgem: I don't think those got hashed out yet.19:06
sbalukoffjorgem: But I'm also playing catch-up here.19:06
*** ajmiller has quit IRC19:15
dougwigregarding the ML thread about octavia, wasn't it the HP folks that suggested not using Libra?19:30
xgermanyeah, we stand by that19:32
sbalukoffLinuxJedi and xgerman: I take it y'all work in separate areas with essentially no overlap?19:33
xgermansablukoff you posted the agenda for today anywhere19:33
xgermanyep, different departments19:33
sbalukoffxgerman: It's deceptively short:
sbalukoffThough I expect the "taskflow vs. not taskflow" discussion may take up most of the time anyway.19:34
sbalukoffPlease feel free to add what you wish to this.19:34
LinuxJedisbalukoff: xgerman works for HP Helion, I work for HP Advanced Technology Group19:35
xgermanalso don't forget to update the standup page: -- johnsom is doing that on our end19:35
*** dank has joined #openstack-lbaas19:37
*** crc32 has quit IRC19:38
*** dkingshott has quit IRC19:41
TrevorVsbalukoff afternoon!19:45
*** jorgem has quit IRC19:47
*** crc32 has joined #openstack-lbaas19:47
dougwigLinuxJedi: you hint that xml/soap is superior to json.  egads, man.19:52
LinuxJediin some ways it is, but it is still turd ;)19:52
LinuxJedijust 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
dougwigthe turdiness so overwhelms the good ideas that it's unspeakable.19:53
dougwigadmittedly it's poor implementation on top of a crap encoding mechanism that killed it.19:54
sbalukoffYeah.... XML should pretty much DIAF19:55
LinuxJediI personally prefer YAML over XML, but it doesn't cover all use cases of XML unfortunately19:56
*** ajmiller has joined #openstack-lbaas19:56
dougwigin xml land, the only thing worse than soap is signed xml.19:56
dougwigdiaf is too quick and painless for xml.19:56
*** mwang2 has joined #openstack-lbaas19:57
erendoes xml still exist?19:58
sbalukofferen: The web has ensured its immortality.20:00
dougwigwhen 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
sbalukoffOh yes! Meeting time!20:00
sbalukoff#startmeeting Octavia20:00
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:00
openstackThe meeting name has been set to 'octavia'20:00
bloganyou're dong it in here?20:00
sbalukoff#topic Roll Call20:00
bloganshouldn't it be in the meeting channel?20:00
openstackMeeting ended Wed Jan  7 20:01:09 2015 UTC.  Information about MeetBot at . (v 0.1.4)20:01
openstackMinutes (text):
bloganyes short meeting20:01
sbalukoffSorry, got a little over-excited there.20:01
*** rm_work|away is now known as rm_work20:01
bloganquick on the trigger20:01
erendrew it too fast20:01
*** jorgem has joined #openstack-lbaas20:01
bloganits -alt right?20:02
erenok, what's the meeting channel?20:04
sbalukoffHowdy, bedis! We're meeting in #openstack-meeting-alt20:12
openstackgerritAl Miller proposed stackforge/octavia: Interface specification for housekeeping manager
*** rm_work is now known as rm_work|away20:34
*** rm_work|away is now known as rm_work20:42
*** vivek-ebay has joined #openstack-lbaas20:55
a2hillSo, why will we be refactoring it to be tightly coupled in a year or so?21:01
dougwigi think that last vote was missing key stakeholders.21:01
sballeWe continue here?21:01
bloganxgerman lets discuss this more21:01
sbalukoffdougwig: It definitely was21:01
a2hillWhat about when UltimegaTaskFlow comes out in a year and a half and we use that instead?21:01
rm_workAlso my concern -- why would drivers even be aware of an "undo"?21:01
rm_workBut that might not be related to this SPECIFIC discussion21:02
rm_workJust want my question/objection to be noted21:02
sbalukoffrm_work: Some drivers might need to do some very complicated stuff.21:02
bedisan undo is just a do with parameters before last update :)21:02
sbalukoffThis might mean that we're essentially embedding some state information in the driver.21:02
sballeI think xgerman and co had to leave for a team meeting.21:02
a2hill^ +121:02
sbalukoffWhich is bad.21:02
xgermanwill be back in a few21:03
sbalukoffBut might be unavoidable for some drivers.21:03
rm_workerk, k21:03
rm_workthat was my objection21:03
rm_workdrivers shouldn't have state info21:03
rm_workand in that case, "undo_update" is "update" and "undo_delete" is "create"21:03
a2hillThen we would either need to have much driver specific logic in the controller defined by the driver writer, OR have taskflow coupled to the driver21:03
a2hillThat was only a suggestion to get around both of those issues21:04
bloganwell the need for undos is an argument outside of this, bc tightly coupling taskflow in the drivers or not would also have undo methods21:04
xgermanok, back - meeting was quick21:04
sbalukoffThe 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_workanyway, 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 implicitly21:04
*** openstackgerrit has quit IRC21:05
a2hillI 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 coupled21:05
*** openstackgerrit has joined #openstack-lbaas21:06
xgermanI am all for decoupled21:06
sbalukoffxgerman: You are confusing me, man!21:06
xgermanbut I also like to have the taskflow stuff available if needed for some of the things in the nova driver21:06
bloganxgerman: what do you mean?21:06
xgermansbalukoff, decoupling for me means returning an OctaviaFlow21:07
sbalukoffxgerman: Any reason that driver writers can't do task flow stuff within their methods if they want?21:07
a2hillwe couldnt the driver still do taskflows and the controller 'task' just call the method that has its own taskflow flows defined?21:07
rm_workxgerman: that still sounds pretty coupled to me21:07
a2hillwhat sbalukoff said :P21:07
a2hillyea, but its a choice in that case21:07
a2hilloh, didnt see xgermans line there. In that case yea its still coupled21:08
rm_workAnswer the question: "would this driver still work if the whole of Taskflow disappeared tomorrow?" If the answer is "no", it's coupled21:08
a2hillin the gist, the answer is yes21:09
xgermanfor each task in OctaviaFlow call execute...21:09
sbalukoffrm_work: That then excludes drivers from calling their own taskflow methods if they want to.21:09
rm_worka2hill: right, but for what xgerman is saying, the answer is no21:09
rm_worksbalukoff: is there a good reason they need to?21:09
xgermanwell, in nthe nova case tou might boot and then have anither task poll, and then another one verifu your ntework is plugged ok21:10
rm_worksbalukoff: also I don't think that's true21:10
blogansbalukoff: it doesn't, the drivers can still use taskflow if they want21:10
sbalukoffrm_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
a2hillblogan +121:10
rm_worksbalukoff: lol ok21:10
rm_workthat is the correct question21:11
sbalukoffxgerman: How to you see OctaviaFlow and Taskflow differing?21:11
bedisyou can't ask the driver writter to rewrite their driver all the time ;)21:11
sbalukoffbedis: You are correct.21:11
xgermansbalukoff for now it would be a thin layer but if we go to something else I would just adapt it accodringly21:12
sbalukoffxgerman: So it's essentially just another layer of abstraction.21:13
xgermantaskflow basiclaly is a c;ass with an undo and execute method21:13
crc32xgerman is probably refering to OctaviaFlow being an abstract class21:13
bloganso lets take the network driver methods for example21:14
sbalukoffdougwig: Isn't that essentially what you had suggested?21:14
sbalukoff(Still trying to figure out if we're violently agreeing here.)21:14
bloganhow would the driver code look with the OctaviaFLow class?21:14
dougwigxgerman: for your nova example, maybe one call that does all those things is too large a bite?21:15
blogansbalukoff: me too, but I think we have disagreemnts on the method of decoupling21:15
sballesbalukoff: lol21:15
dougwigsbalukoff: 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
sbalukoffblogan: Right. So let's wheedle out these differences.21:16
xgermandougwig +121:16
sbalukoffdougwig: Agreed.21:16
sbalukoffdougwig: So... what color are we painting this bike shed again?21:16
a2hill This is updated to what could be done if taskflow is still wanted/needed inside the driver. Which could just be subclassed from Octaviaflow21:17
a2hillI may have completely lost myself on where this debate is going21:17
blogana2hill: you have21:17
sbalukoffa2hill: Welcome to the club. Try the sandwiches.21:17
dougwigwhy 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
dougwigquestion of style21:18
blogandougwig: i agree, but at least it decouples us from taskflow21:18
a2hillTasty mmmm21:18
sbalukoffdougwig: Sorry, I didn't mean the bikeshedding comment to be aimed specifically at you21:18
xgermanwell, classes save us from noops if undo is not needed21:19
sbalukoffI 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
xgermanyeah, I am aiming for consistency, too21:20
dougwigxgerman: not making the undo's abstract also solves that.  :)21:20
dougwigsbalukoff: is ok, i have lots of excess paint.21:24
bloganso is the argument now whether we use classes for each "task" or use methods for each task?21:27
bloganand those classes are not inheriting from taskflow at all, though probably from a base class21:28
xgermanwell, it would make my life easier if they inherit from taskflow :-)21:28
xgermanthen I just add them to the flow21:29
*** jorgem has quit IRC21:30
bloganbut wrapping them in a Taskflow.Task is pretty trivial in the layer above, same if they are just methods21:30
dougwigeh, versus wrapping them and adding. that's gotta be like 4 lines of code we're down to debating.  :)21:31
sballedougwig: +121:31
xgermanso let's summarize then:21:38
xgerman1) We want drivers to be simple and synchronous21:38
xgerman2) We don't want drivers to know about taskflow and if they need to implement flows they should get their own flow engine21:38
sbalukoff--> Which might be taskflow, but we're not dictating that or anything else.21:39
sbalukoffAlso, 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
sbalukoffWhat 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
sbalukoffAnyone disagree with that?21:43
xgermanno that's fine21:43
sbalukoffAlso, 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
sbalukoffAre we agreed on that as well?21:44
xgermanI am not so sure on that one -- ML2 is now forcing driver writers to use taskflow because letting them do their own thing caused problems21:45
sbalukoffIt seems to me that if we're strict on requiring all driver methods to be synchronous it's not a problem.21:45
dougwigi'm not sure a neutron wip is really an authoritative source here.21:46
dougwigor is it out of wip with +2 approvals?21:46
bloganxgerman: im not saying the drivers have to be synchronous either21:47
sbalukoffblogan: Dammit, man!21:47
blogani dont know why that woudl be a requirement!21:47
bloganlol sorry21:48
xgermanso we basically only don't want ot us etaskflow in the driver21:48
bloganwe dont want to expect taskflow to be used in teh driver, people writing their own drivers are free to do whatever they want21:48
xgermanand otherwise it's free 4 all21:48
sbalukoffblogan: 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-lbaas21:49
blogannot 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 matter21:49
xgermanusually async methods need to update our database21:50
sbalukoffblogan: What if a subsequent task in the flow must be done serially (ie. after some previous method is finished executing)?21:50
xgermanwhich I despise21:50
sbalukoffxgerman: Agreed.21:50
bloganwell i'd like to avoid drivers having access to the db, if possible, not sure if it is21:50
sbalukoffblogan: I think we all agree on that.21:51
dougwigblogan: 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
blogansbalukoff: can you give an example? what kind of task?21:51
dougwigan asynchronous interface implies it can return "not ready yet, call again later" somehow.21:51
sbalukoffblogan: 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
xgermanwell, nova is asynchronous but it doesn't help us if the vm isn't booted -- so we are blocked on that and keep polling21:52
*** crc32 has quit IRC21:52
dougwigi'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
sbalukoffdougwig: +121:53
bloganok so this is a similar problem in neutron lbaas right?21:53
sbalukoffblogan: Er... I don't know? I think so?21:53
blogandrivers that accomplish their methods synchronously versus those that accomplish async21: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
bloganwell basically drivers that are agentified and those that arent21:54
bedis(( I count on your votes ;) ))21:54
dougwigyes, 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
sbalukoffbedis: +1 And good luck!21:54
bloganactually taskflow doesnt do that for us, we still have to spawn the taskflow execution in a separate thread/process21:55
dougwigthat's an implementation nit.  :)21:55
xgermanwell, taskflow aslo saves states so if we crash we can just start where we left off21:56
xgermanand things like that21:56
*** TrevorV_ has joined #openstack-lbaas21:56
bedis(( good night all ))21:56
*** chlong has joined #openstack-lbaas21:56
sbalukoffgood night, bedis!21:56
xgermanbedis: good night21:56
sbalukoffxgerman: Are you saying that this is a tool written to solve these kinds of complicated flow problems? ;)21:57
sbalukoffLook, I don't think anyone is against using taskflow.21:57
sbalukoffOctavia is going to use it in the controller in any case.21:58
sbalukoffWe 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.021:59
xgermanyep - I was just trying to summarize what we wanted21:59
*** jorgem has quit IRC21:59
bloganok lets start of just saying every driver is synchronous21:59
bloganbut yes taskflow in the controller is definitely what we should do21:59
xgermanhas a synchromous imnterface as dougwig pointed out :-)21:59
sbalukoffblogan: Ok!21:59
dougwigsbalukoff: i guarantee that most driver writers will want to learn/do the minimum and the GTFO.21:59
sbalukoffdougwig: Amazing, that's what I want to do, too! XD22:00
xgermanI gotta run to anothe rmeeting22:00
sbalukoffHere's what I'm thinking (when you get back):22:00
bloganso im going to assume I should change the network driver around for this22:01
xgermanand I undertand we can't force driver writers to their own luck22:01
sbalukoff1. All driver interfaces are synchronous, even the methods that might take a long time to execute fully.22:01
sbalukoff2. Drivers should not need to be aware of flows, although they are free to use them themselves.22:01
sbalukoff3. ... profit?22:01
blogan3. Beat sbalukoff22:02
TrevorV_3. a) with a stick first22:02
TrevorV_3. b) then with a bat22:02
sbalukoffSo, 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 IRC22:03
bloganwell 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 methods22:03
sbalukoffblogan: 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
sbalukoffAnyway, the above gets us the following:22:04
bloganlol well you said you're not hearing a compelling reasonf or an abstract base class22:04
sbalukoffblogan: I used the wrong term.22:04
bloganohhh lol22:04
sbalukoffAnyway, the above gets us the following:22:04
sbalukoffA. Driver writers need not have deep knowledge of controller internals.22:05
sbalukoffB. 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-lbaas22:06
sbalukoffC. 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
sbalukoffTrevorV_: Yes.22:07
bloganwell i said above that i dont think that should be a requirement, but i can live with that now22:07
TrevorV_Okay no problem just didn't read that earlier22:07
bloganwe can improve in the future we need to22:07
dougwigonce you pass runtime control to me, all your pesky rules are just guidelines. but that guidance will keep things simpler.22:07
sbalukoffblogan: 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
blogantotally agree22:08
TrevorV_You're a refactor22:09
*** markmcclain has joined #openstack-lbaas22:10
blogani do have a feeling though, that when i update the network driver interface there will be disagreements22: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 :P22:10
TrevorV_jp jp22:10
bloganno i still feel like we won't be on the same page, but I'm hopeful, I would like to get on the same page22:11
bloganand im sure i am not explaining myself well22:12
sbalukoffThat'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
sbalukoffThis is partially because I'm an asshole. It 's also partially because sometimes there's a serious disconnect between brain and keyboard.22:13
sbalukoffLike now.22:13
bloganthere's a serious disconnect between many parts of my brain22:13
dougwigjust bring some code.22:16
sbalukoffOk, I'mma be partially AFK for a bit.22:19
*** sbfox has quit IRC22:19
*** mwang2 has quit IRC22:28
*** sbfox has joined #openstack-lbaas22:31
*** sbfox has quit IRC22:43
xgermanhere is the code22:52
xgermanalso our assumptions are:22:57
xgermanhave another meeting catch you guys later22:58
*** crc32 has joined #openstack-lbaas23:02
*** vivek-eb_ has joined #openstack-lbaas23:10
*** vivek-ebay has quit IRC23:10
openstackgerritStephen Balukoff proposed stackforge/octavia: haproxy reference amphora API code
sbalukoffWoot! Got the first -1 on that review.23:13
*** vivek-eb_ has quit IRC23:21
*** vivek-ebay has joined #openstack-lbaas23:21
*** chlong has joined #openstack-lbaas23:22
jorgemjohnsom: Heyo, I commented on if you want to take a look. Just trying to understand the API Manager component :)23:24
johnsomOk, I will take a look23:25
rm_workjohnsom: 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 Updates23:26
rm_work*not just Creates23:26
sbalukoffYeah, we called it 'deploy' worker on the whiteboard.23:34
sbalukoffBut, I think this was before we figured out that each manager will need to spawn tasksflows occasionally.23:34
sbalukoffSo, perhaps 'deploy worker' is a poor name.23:34
crc32blogan: see my pm23:34
crc32rm_you is blogan still in office?23:36
rm_workhe is talking with Jorge23:36
crc32could you slap him real quick.23:36
xgermansbalukoff +1 it woill fire off a flow23:37
rm_workcrc32: uhh he's at a whiteboard, i guess, what did you need?23:42
rm_workcrc32: anything I could just get an answer from him quickly or does he really need to go read his IRC?23:42
rm_worksbalukoff: well, we called it a worker to distinguish it from a 'manager', which is a daemon, because the worker is just a thread23:43
sbalukoffrm_work: That works!23:43
rm_workxgerman: i don't know if it has to be flows? I am not sure why we'd bother doing that with flows23:43
sbalukoff(pun intended)23:43
rm_worksbalukoff: T_T23:43
sbalukoffrm_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_workxgerman: 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 flows23:44
crc32I'm doing a change to "" but when I type "git review" I get a merge conflict.23:44
crc32crc@bitchslap:~/workspace/curr/neutron-lbaas$ git review23:44
crc32Errors running git rebase -i remotes/gerrit/master23:44
crc32error: could not apply b61ac93... Merge feature/lbaasv223:44
crc32When you have resolved this problem, run "git rebase --continue".23:44
crc32If you prefer to skip this patch, run "git rebase --skip" instead.23:44
crc32To check out the original branch and stop rebasing, run "git rebase --abort".23:44
crc32Could not apply b61ac93728fade2a6fbc003ba984edecb1cb106f... Merge feature/lbaasv223:45
rm_workbut actually spinning up a deploy worker wouldn't need to come from a flow, seems like extra overhead/complexity than we need23:45
crc32the conflict is on the file both modified:      neutron_lbaas/db/loadbalancer/ which isn't part of my change request.23:45
crc32its like its trying to rebase a dependency commit.23:45
xgermanrm_work I agree with sbalukoff some might be flows some aren't23:45
rm_workxgerman: 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
xgermanflows gives you a thread pool and some way to orchestrate among multiple workers/threads - so I would rather run a flow before spinning a worker23:46
rm_workI don't think either of those would gain anything from using flows23:46
rm_workxgerman: i was told TaskFlow *did not* handle threading23:47
rm_workand that if you wanted something to be run in a thread you still had to run taskflow in a thread manually23:47
sbalukoffrm_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_workbecause taskflow.execute() itself would block23:47
xgermanyep, but it will run on a threadpool23:47
rm_worksbalukoff: 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 it23:48
rm_workseems kind of redundant23:48
rm_workand more complicated than necessary23:48
sbalukoffrm_work: Agreed.23:48
rm_workbut i guess it technically would be up to whoever calls it <_<23:48
rm_workit's not like the deploy-worker code itself needs to be flow-aware for it to work23:48
xgermanwell, ot really depends on the command23:48
sbalukoffSome things will need a task flow (probably most things, actually), others won't.23:49
rm_workcrc32: i am checking currently23:49
xgermansbalukoff +123:49
crc32it looks like a commit was merged where sball just rearranged import statements.23:49
rm_workcrc32: you're trying to rebase on top of 144832 right?23:50
crc32not sure all I said was git review. The rebase is implied apparently23:50
rm_worklooks like that is your dependency23:50
rm_workwhich itself relies on 14483123:50
rm_workwhich is the thing which ACTUALLY has a merge conflict, I think23:50
rm_workcrc32: try `git review -R`23:51
rm_workerr, and you might have to revert whatever rebasing it tried to do23:51
rm_workbecause it looks like it left you mid-rebase23:52
openstackgerritTrevor Vardeman proposed stackforge/octavia: Author: Trevor Vardeman <>
crc32Whats the -R do?23:53
openstackgerritCarlos Garza proposed openstack/neutron-lbaas: Common TLS utilities
rm_workno rebase23:53
rm_workTrevorV_: lol your commit message23:53
openstackgerritTrevor Vardeman proposed stackforge/octavia: haproxy reference amphora API client
crc32so did I just kick the problem down the road or is it ficed?23:53
openstackgerritTrevor Vardeman proposed stackforge/octavia: haproxy reference amphora API client
rm_workcrc32: the rebasing isn't "your problem", it's the problem of the person above you in the review chain23:54
rm_workcrc32: so, kinda both23:54
rm_workcrc32: you *can't* really fix it now yourself23:54
rm_workbut you will probably have to do a rebase patchset later once brandon fixes his review23:54
rm_workthat's one of the only real problems with large review chains23:55
rm_work*dependency chains23:55
crc32Its the waterfall model.23:55
*** TrevorV_ has quit IRC23:56

Generated by 2.14.0 by Marius Gedminas - find it at!