20:03:16 <sbalukoff> #startmeeting Octavia
20:03:17 <openstack> Meeting started Wed Jan  7 20:03:16 2015 UTC and is due to finish in 60 minutes.  The chair is sbalukoff. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:18 <sballe> lol
20:03:18 <rm_work> WOOO
20:03:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:20 <openstack> The meeting name has been set to 'octavia'
20:03:23 <sbalukoff> #topic Roll CAll
20:03:23 <johnsom> o/
20:03:24 <jorgem> #help
20:03:24 <rm_work> o/
20:03:25 <sballe> \o/
20:03:27 <dougwig> o/
20:03:30 <jamiem> o/
20:03:32 <rm_work> success
20:03:33 <ajmiller> o/
20:03:33 <blogan> hi
20:03:44 <jorgem> hello
20:03:56 <sbalukoff> Ok, this is today's agenda, such as it is:
20:03:59 <sbalukoff> #link https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda
20:04:33 <a2hill> o/
20:04:41 <eren> o/
20:04:55 <xgerman> o/
20:04:55 <sbalukoff> #topic Brief progress reports
20:05:06 <sbalukoff> I'll go first on this:
20:05:34 <sbalukoff> Trevor and I collaborated over the holiday to get a skeleton of some code started for the amphora API.
20:05:55 <sbalukoff> It's totally incomplete, with no testing, and certainly doesn't work yet... and probably puts the code in the wrong place.
20:06:04 * TrevorV did something without blogan around (mostly)... feels accomplished mildly
20:06:07 <sbalukoff> But my plan is to get a WIP review going on this after this meeting.
20:06:24 * dougwig sharpens his -1 finger.
20:06:47 <sbalukoff> Should be enough to get people started on what we're thinking, and yes, I imagine we're going to go through a lot of patch sets before I see any +1's or +2's.
20:06:54 <a2hill> sbalukoff, can you ensure to respond to some of my comments in the spec? It makes difference for some of the driver decisions
20:07:23 <sbalukoff> a2hill: Yes, I had been holding off on updating the spec because I wanted to get some actual python coded.
20:07:29 <sbalukoff> Prepare to be horrified y'all.
20:07:36 <a2hill> Gotcha ;)
20:07:37 <johnsom> Hahaha
20:07:38 <sbalukoff> Anyway, who would like to go next?
20:07:43 <rm_work> a2hill: wait didn't you take ETO? :P
20:07:50 <a2hill> yes o.O
20:08:02 <sbalukoff> rm_work: I took some.
20:08:17 <dougwig> sbalukoff: rule #1) python files should end with ".rb"
20:08:22 <johnsom> I am mostly getting caught up from vacation time.  We have been working on the amphora driver API
20:08:24 * blogan chokes dougwig
20:08:28 <rm_work> sbalukoff: yes but a2hill is on ETO *now* T_T
20:08:34 <sbalukoff> dougwig: Thanks for the help, yo. XD
20:08:39 <xgerman> ruby 4ever!
20:08:44 <a2hill> wanted to attend meeting
20:08:52 * dougwig metaprograms his way out of blogan's chokehold.
20:08:54 * rm_work puts xgerman and dougwig in the corner
20:08:57 * sbalukoff stares at a2hill incredulously.
20:09:02 <a2hill> ><
20:09:07 <sbalukoff> Ok!
20:09:28 <sbalukoff> I'm not sure what all people were able to get done over the break, so I'm reluctant to call people out individually.
20:09:44 <a2hill> For my update I was catching myself up on things and starting on the haproxy driver
20:09:44 <xgerman> I did some more work on the taskflow/api server which starts a nova vm... it now writes to the DB
20:09:58 <blogan> i started the api to queue code, carlos is taking that over though
20:09:58 <sbalukoff> excellent!
20:10:09 <rm_work> I literally just got back today from vacation <_<
20:10:16 <sbalukoff> Any particular reviews y'all would like to point out that need eyes at this time?
20:10:48 <blogan> well i have some that are pendign the taskflow discussion
20:10:59 * dougwig sharpens his pitchfork.
20:11:02 <sbalukoff> HAHA
20:11:02 <a2hill> ^^
20:11:27 <sbalukoff> Anyone have reviews that are not pending the taskflow discussion you'd like to get eyes on this week?
20:11:32 <TrevorV> johnsom sorry to interject, i have no idea what you mean by "amphora driver API"
20:11:34 <sballe> maybe we could move to the taskflow discussion and then come back based on the conclusion on
20:11:51 <a2hill> the API you are building client for TrevorV
20:11:52 <johnsom> TrevorV: amphora-driver-interface blueprint code
20:12:01 <a2hill> or that
20:12:17 <TrevorV> Oooh oh oh okay, I was concerned there was duplication
20:12:18 <TrevorV> Sorry sorry
20:12:19 <rm_work> "amphora driver interface"
20:12:25 <blogan> this review needs some reviews https://review.openstack.org/#/c/136499/
20:12:33 <sbalukoff> Yay!
20:12:37 <blogan> TrevorV: needs to fix my one comment
20:12:42 <a2hill> in min going to be updating that interface to the new spec xgerman?
20:12:46 <a2hill> is*
20:12:52 <xgerman> yes
20:12:55 <a2hill> kk
20:13:08 <sbalukoff> Ok.
20:13:18 <TrevorV> blogan I'll get on that later this evening
20:13:55 <sbalukoff> Ok, let's go onto the taskflow discussion, as I see this taking a while.
20:14:00 <sbalukoff> #topic To tightly couple interfaces with taskflow or to not (german & blogan)
20:14:08 <a2hill> duhdundun
20:14:10 <sbalukoff> I yield the floor to y'all.
20:14:22 <blogan> i rephrased your original topic
20:14:32 <jorgem> "tightly copule" infers to not
20:14:35 <jorgem> lol
20:14:42 <a2hill> Ill start off by saying it would be nice to not have to build tasks in the driver and instead wrap them so its less coupled
20:14:45 <jorgem> oh haha that makes sense then
20:14:55 <TrevorV> +1 a2hill
20:14:55 <dougwig> firstly, we're all agreed to use taskflow, so this is NOT a taskflow vs not discussion, right?
20:15:01 <blogan> bc I am not advocating not using taskflow, im just saying that the interfaces should not be tightly coupled with it, they should be dumb about hwo they are executed
20:15:06 <xgerman> dougwig +1
20:15:10 <blogan> dougwig: +1
20:15:10 <jorgem> dougwig: I believe so
20:15:21 <TrevorV> Correct dougwig
20:15:30 <TrevorV> We're discussing where the task-flow related code will exist.
20:15:44 <dougwig> this is, are our driver interfaces flow aware, or are they "create_foo, update_foo, delete_foo"
20:15:59 <blogan> and i dont think teh drivers should return flows, I know ML2 is currently doing that but that is a WIP, and I personally don't think it is the best design
20:15:59 <sbalukoff> xgerman: Could you share your thoughts on this with us?
20:15:59 <dougwig> and it's the controller's job to wrap a flow around those.
20:16:15 <blogan> correct dougwig
20:16:20 <a2hill> ^^ +100 dougwig
20:16:42 <dougwig> fwiw, i'm in the yes taskflow, drivers are not aware, camp.
20:17:23 <xgerman> ok, I don't think drivers returning flows is a big burden -- it's just soem boilerplate code
20:17:39 <xgerman> and ensures that we can have an revert method we can call for each method
20:17:52 <a2hill> not that its a burden, its that its tightly coupled
20:17:56 <blogan> but we can have the interface force a definition of a revert method
20:17:57 <dougwig> but if we go away from flows, then the drivers all have to be rewritten.
20:18:01 <sbalukoff> xgerman: Is this harder to achieve with "dumb" methods?
20:18:08 <dougwig> and it'd seem trivial to have the higher layer wrap the flow
20:18:35 <TrevorV> It IS trivial to have them at a higher level
20:18:42 <sbalukoff> dougwig: Do you think we will ever move away from flows?
20:18:44 <a2hill> thing with that is the driver implementor has to worry about controller code also, not that its a big issue
20:18:53 <xgerman> well, it's only trivial if the driver doesn't need any advanced flows
20:19:25 <xgerman> when we looked atour discussion I didn't want to preclude the drivers from having the abilkity to define flows if they want to
20:19:28 <dougwig> a driver can do its own flows without needing to be part of the main flow, right? aren't those orthogonal issues?
20:19:34 <blogan> the driver can still choose to use taskflow underneath if it wants
20:19:40 <a2hill> If we wrap things in the controller, the controller needs to know the order of the method and which methods to actually call
20:19:42 <sbalukoff> a2hill: I don't think there's any way to avoid the drivers being aware of what the controller is doing...
20:19:43 <a2hill> thats a downside
20:20:14 <xgerman> yeah, we want the controller to be in control
20:20:27 <a2hill> then in that case, wraping it makes sense
20:20:31 <xgerman> and not have the driver call out to other drivers
20:20:32 <blogan> it will be, it'll call interface methods
20:20:39 <sbalukoff> For what it's worth, I'm currently on neither side of this discussion. :)
20:20:49 <bedis> the driver should be a "performer"
20:20:53 <dougwig> drivers should be, "here's some info, do what you need to do, tell me the result".  flows are an interface for abstracting async, concurrency, failure rollback, etc.  those aren't "driver" functions.
20:21:21 <xgerman> well, historically drivers did stuff async, etc.
20:21:29 <blogan> and drviers can still do that
20:21:52 <xgerman> well, then they should be flow aware to do that in a sane way
20:22:11 <dougwig> to me, it's like embedding the thread scheduler in a filesystem driver. let the filesystem driver read/write blocks, let the higher level worry about how to organize it.
20:22:41 <bedis> +1 with dougwig :)
20:22:57 <sbalukoff> dougwig: You mentioned in previous discussions (and above) that you'd like to see another layer of abstraction for this. I thought you were joking when you first mentioned it. How would you envision that working exactly in this case?
20:23:38 <blogan> wrapping of the driver methods in a flow in the controller code, not in the driver code
20:23:52 <dougwig> drivers have tight uncoupled entry points "do_x", and the controller has a layer that encodes how to put those primitives into a sane flow.  if the primitive is so large the controller can't do that, it's an indication that the driver is being asked for too large a piece.
20:24:02 <dougwig> what blogan said, yeah.
20:24:27 <blogan> and if its too large a piece, the interface needs to be decomposed into further methods
20:24:47 <johnsom> I really want a solution that has clear and complete error handling.
20:24:53 <a2hill> You do lose the specific abiljity to revert as part of the task when you just wrap a 'dumb' method though and not sure its doable otherwise
20:24:57 <sbalukoff> blogan: That seems to imply that all end-devices need to use roughly the same flows. Or are you thinking that for some drivers, some of the methods called would just be noops if they don't need them (and then the controller potentially is calling a ridiculous number of methods to accommodate every strange device?)
20:25:20 <dougwig> johnsom: if the driver is doing little bits, then the encoding for error handling and rollback is actually only done once (in the controller), instead of left to every driver author.
20:25:23 <xgerman> sbalukoof +1 - what's easy for one driver might be difficult for the next
20:25:53 <sbalukoff> (Again, just playing devil's advocate here. Because I'm kind of a jerk.)
20:25:54 <dougwig> sbalukoff: i'm not assuming a 1:1 mapping on the controller flows and the driver interfaces.
20:26:21 <sbalukoff> dougwig: I'm not quite sure I follow you.
20:26:39 <xgerman> yeah, I am confused, too
20:26:46 <sballe> same here
20:26:58 <xgerman> if I call say update_lb -- that can be done async, sycn, and wahtever
20:27:14 <dougwig> e.g. the driver interfaces might be create_vip, create_fip, add_member x3, create and assoc hm.  the flow might be to create the lb, and have a tree for all of that, plus it's rollback scenarios.
20:27:14 <xgerman> and consist of figuring out the state on the lb, not doing that...
20:27:23 <sbalukoff> What if the next step in the flow needs to be done serially?
20:28:09 <a2hill> thing is, from what i can tell thus far, is unless you are subclassing taskflow you cant add the specific rollback scenarios, which makes it difficult to de-couple this
20:28:19 <sbalukoff> That is to say-- assume one driver does it sync, another async...  do we need another method there for the controller to check on the status of the last command in case it was done async and pause before the next serial command?
20:28:43 <xgerman> a2hill we can always write an abstraction for that
20:28:45 <dougwig> i'm assuming you can simplify drivers and just have them all be sync, and let taskflow async them.
20:28:53 <blogan> if taskflow is used in the controller to call these dumb methods, and one method is async hte other is sync, it shouldn't matter, its all going to look async to the controller
20:28:54 <dougwig> then the serialization is up to the flow.
20:29:03 <a2hill> not if youre wrapping with functortask
20:29:35 <xgerman> so we are making assunptions:
20:29:48 <xgerman> 1) driver tasks a simple and synchronous
20:29:49 <a2hill> you can provide it params but i dont see a way to tell the flow to rollback if 'this particular task' fails
20:30:13 <sbalukoff> xgerman: We could explicity state that in the contract...
20:30:34 <blogan> im not assuming they're synchronous
20:30:34 <sbalukoff> Anything running a taskflow is going to be doing it in its own thread anyway-- that thread can wait indefinitely.
20:31:01 <xgerman> well, waiting is another "task"
20:31:02 <bedis> the rollback could be a revert to a "snapshot"
20:31:05 <sbalukoff> (Which... well, might be a problem in some cases.  Obviously we'll want to be able to interrupt hung tasks.)
20:31:15 <a2hill> I suppose we could have tasks in the controller that has defined revert policies that calls the dumb methods, which wouldnt be using functortask in that case
20:31:22 <sbalukoff> bedis: It's not always that simple.
20:31:23 <johnsom> indefinite waiting threads is a bad thing
20:31:30 <xgerman> yep
20:31:53 <xgerman> so all we are saying is we don't want to wrap driver functions into classes
20:31:55 <dougwig> johnsom: that's what timeouts are for.
20:32:44 <bedis> sbalukoff: is the configuration stored in the DB ?
20:33:09 <blogan> xgerman: i think we're saying we dont want to have driver implementations return flows
20:33:16 <TrevorV> +1 blogan
20:33:24 <bedis> that said, if an error occured, a rollaback may also generate an error :/
20:33:37 <bedis> s/occured/occurs/
20:33:38 <blogan> and let the code that is calling the driver wrap those methods in tasks/flows
20:33:42 <sbalukoff> bedis: In theory yes-- but there's the problem of resolving what's in the DB with what is actually deployed. That's the whole problem, really. :)
20:33:52 <jorgem> just to point out, it will be easier to test if the interface is decoupled from flows.
20:33:58 <sbalukoff> bedis: Yep, that's my point!
20:34:30 <sbalukoff> Ok...
20:34:57 <a2hill> For example: I need to build haproxy configs, call api client, so my update() method would do just that. Then the controller would have a Task that calls the drivers update() method and have revert policies defined. This adds a lot of logic to the controller, but sounds like thats what we want and it de couples taskflow from the driver
20:35:10 <sbalukoff> I see this more a question of "where should the intelligence be"?  If it's all in the controller, drivers are probably simpler to write, so long as they can do things in a way that's very similar to the reference implementation.
20:35:29 <sbalukoff> If it's in the driver, that leaves a lot more work for the driver writer, but also a lot more flexibility
20:35:45 <dougwig> a2hill: would that revert be to call update, and then call update again with the old config, and if that also fails, start a new amphora with the old config? that's driver neutral rollback.
20:35:55 <a2hill> could be
20:35:56 <sbalukoff> It also means that users and operators may not have a unified experience of how Octavia works, depending on which drivers / amphorae they're using.
20:36:08 <a2hill> depends on what/how we want to revert i suppose
20:36:19 <TrevorV> Then I'd say the logic shouldn't be in the driver layer sbalukoff
20:36:30 <TrevorV> Which i've said from the beginning
20:36:33 <sbalukoff> TrevorV: Why?
20:36:51 <xgerman> revert might look different dpending on the driver
20:36:55 <TrevorV> Why would we want a different experience per user?
20:36:55 <dougwig> speaking as a driver writer, the guys writing new drivers do *NOT* have the deep knowledge of the overall system and failure cases that the guys writing the controller have.  that "increased flexibility" becomes "worse quality", IME.
20:37:15 <blogan> +1
20:37:20 <xgerman> they don;t need that
20:37:27 <a2hill> xgerman, exactly, and thats why using functorTask isnt really a solution either because you cant define revert policies for it
20:37:40 <sbalukoff> dougwig: Very good point. Also echoes my experience as an operator.
20:37:40 <xgerman> yes, don't use FunctorTasks
20:37:44 <TrevorV> xgerman who doesn't need what?
20:37:46 <a2hill> so, we cant decouple if the revert is driver specific
20:38:06 <blogan> a2hill i dont know what you mean
20:38:24 <xgerman> so whatever the driver is doing might be more complicated than just a call
20:38:27 <a2hill> you have to define the tasks in the driver that has the revert etc.. policies
20:38:42 <xgerman> which can easily be reverted
20:39:01 <bedis> the controller should update configuration through a "transaction", driving the driver through small "atomic" operations
20:39:22 <TrevorV> xgerman a2hill I think we've missed a step here.  You're saying the roll-back operation should happen in the driver?  I'm arguing against that.
20:39:29 <blogan> why can't teh driver interface define do_this() and undo_that() methods?
20:39:52 <dougwig> xgerman: nothing prevents more complicated drivers from hijacking their runtime entry point and doing *whatever* they want. being more complicated is supported in both scenarios, i think.
20:39:58 <a2hill> like undo_update?
20:40:13 <blogan> a2hill: yes if that is what the real issue is here
20:40:25 <a2hill> that would solve the revert policies i suppose
20:40:27 <xgerman> dougwig I just wanted to give the driver writer a framework to do this in an organized way
20:40:35 <a2hill> actually yea, thats kinda nice
20:40:51 <sbalukoff> dougwig: And this continues to work with taskflow especially if the driver interfaces are all sync by contract.
20:40:53 <a2hill> so in my above example, the revert policy would just call the 'undo' methods
20:41:04 <dougwig> sbalukoff: right
20:41:06 <a2hill> so its still defined by the driver, but the task built in controller
20:41:08 <blogan> a2hill: yes
20:41:15 <a2hill> I like that
20:41:33 <dougwig> blogan: +1
20:42:27 <xgerman> not sure how that is different from wrapping those two functions ina  class
20:43:04 <a2hill> IT would be the same thing, just not coupled to the interface. If im understanding your confusion correctly :P
20:43:09 <a2hill> er to taskflow
20:43:54 <blogan> xgerman: the difference is driver writers dont have to worry about taskflow and flows, and they just ahve to worry about writing the methods to do exactly what they say they are supposed to do
20:44:02 <blogan> its clearer
20:44:10 <sbalukoff> For the driver writers...
20:44:11 <blogan> and easier to test
20:44:22 <sbalukoff> Who are likely not to have intimate knowledge about everything the controller has to do.
20:44:34 <blogan> no and they shouldn't
20:44:39 <xgerman> they don't need that knowledge -
20:44:40 <a2hill> but they wouldnt need to if we do it this way
20:44:42 <TrevorV> Not to mention, in my opinion, we shouldn't couple an interface (which is meant to be generic) to a technology.
20:44:42 <sbalukoff> Also, the controller taskflows are likely to get a lot more complicated with Octavia v2.0....
20:45:02 <sbalukoff> Leaving that kind of logic in the driver at that point seems like a really bad idea.
20:45:10 <blogan> sbalukoff: what logic?
20:45:10 <xgerman> which logic?
20:45:13 <blogan> lol
20:45:41 <xgerman> yeah, all I wanted to give driver writers a framework so if assign_vip is ten steps they could make that more orgznized
20:46:05 <blogan> if its ten steps then they can organize that themselves
20:46:23 <sbalukoff> Well, maybe I'm thinking about this wrong, but I'm talking about roll-back logic when, say, you're trying to bind to a specific IP on 100 amphorae and it doesn't work on one of them...
20:46:24 <xgerman> yeah, hence tey would return a flow containing those ten steps
20:46:31 <sbalukoff> But... again, I'm probably not thinking about this correctly.
20:46:41 <blogan> xgerman: or they use taskflow in their own driver
20:46:55 <blogan> xgerman: or they solve it in another way that they prefer
20:47:51 <blogan> i wish this had come up at the hackathon :(
20:47:58 <blogan> bc whiteboarding would be great!
20:48:02 <dougwig> (or provide a parent method to request a flow handle and populate it, then return success.)
20:48:05 <xgerman> yep
20:48:13 <dougwig> ((optionally))
20:48:59 <xgerman> I felt the flow stuff was lightweight enough o warrant just saying get_flow
20:49:02 <TrevorV> Not to be a stick in the mud, but from what I can collect popular opinion on the topic at hand is decoupling driver from task-flow.
20:49:10 <sbalukoff> blogan: It did come up at the end of the week at the hackathon, I believe.... but parties had already left at that point.
20:49:20 <blogan> sbalukoff: ouch
20:49:22 <a2hill> I think this is what im thinking about, is this wrong? https://gist.github.com/the2hill/0a40cbe6963d8a1097a4
20:49:28 <bedis> maybe  the driver can implement a method such as "snapshot_point" and should be able to revert to that point
20:49:48 <blogan> bedis: maybe, but to keep it simple right now i'd leave that to do in future versions
20:49:49 <TrevorV> a2hill that seems accurate to me
20:49:56 <dougwig> a2hill: +1
20:49:59 <xgerman> a2hill and that is exactly a taslflow.task
20:50:05 <dougwig> i'm not sure we've got any new information to offer here, nor consensus.  so... vote, ML, let this brew, other?
20:50:08 <a2hill> yea, just not coupled in the driver
20:50:10 <sbalukoff> bedis: I'm not sure we want to hand that requirement to each driver writer. Some states are hard to revert to.
20:50:11 <TrevorV> bedis that's definitely a possibility here.
20:50:18 <blogan> xgerman: it is, but to the driver writer its not
20:50:41 <sbalukoff> dougwig: I think consensus on this is blocking some work here.
20:50:41 <blogan> driver doesn't need to know taskflow, or how to pass parameters around, how to load parameters, get return values
20:50:45 <xgerman> oh, ok, I just did an class OctaviaRask(task.Task):
20:50:46 <sbalukoff> Or lack thereof, I mean.
20:50:59 <xgerman> blogan, they don.t
20:51:02 <bedis> sbalukoff: well, not for HAProxy, it's a "cp haproxy.cfg.snaptshot haproxy.cfg" :)
20:51:24 <sbalukoff> bedis: Yes, but launching amphora, plumbing them, etc. are much more complicated tasks. ;)
20:51:33 <bedis> heh :)
20:51:41 <sbalukoff> Ok, so!
20:51:52 <sbalukoff> I really want to not be blocked on this.
20:51:57 <bedis> I'm not deep enough :/
20:51:59 <crc32> Ivote?
20:52:04 <TrevorV> sbalukoff vote sounds good to me
20:52:15 <xgerman> I think blogan and a2hill and I are pretty much aligned
20:52:16 <blogan> xgerman: would you be okay with the interfaces defining do and undo methods and the layer above just wraps them in tasks/flows?
20:52:29 <a2hill> i dislike blogan, im against anything he says
20:52:30 <dougwig> #vote To couple or not to couple, that is the question.  Couple, Not Couple
20:52:31 <sbalukoff> xgerman: Ok! That's great to hear.
20:52:32 <dougwig> :)
20:52:32 <sballe> could somebody summarize the outcome? it looks like we are in agreement.
20:52:32 <a2hill> :)
20:52:44 <blogan> violent agreement
20:52:59 <rm_work> all agreement in this group is violent
20:53:01 <dougwig> by transitive association, that means xgerman and i agree as well.
20:53:03 <sbalukoff> #vote Shoud we couple drivers with task flow? Yes No
20:53:07 <TrevorV> I think the outcome is NOT coupling taskflow in drivers/interfaces, but definitely to use taskflow in the controller
20:53:12 <a2hill> rm_work +1, but i hate you
20:53:16 <sbalukoff> Dammit... been a while since I ran a vote.
20:53:17 <blogan> startvote
20:53:34 <sbalukoff> #startvote Should we couple drivers with taskflow? Yes No Sandwiches
20:53:35 <openstack> Begin voting on: Should we couple drivers with taskflow? Valid vote options are Yes, No, Sandwiches.
20:53:36 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:53:38 <bedis> (I'm lost...)
20:53:44 <sbalukoff> #vote No
20:53:46 <TrevorV> #vote Yes
20:53:46 <jorgem> #vote No
20:53:49 <rm_work> a2hill: i violently agree, I hate me too :P
20:53:53 <TrevorV> #No
20:53:54 <dougwig> #vote No
20:53:55 <blogan> #vote No
20:53:56 <bedis> #vote No
20:53:56 <xgerman> #vote Yes
20:53:56 <TrevorV> #vote No
20:53:56 <a2hill> #vote No
20:53:57 <crc32> #vote no
20:54:02 <johnsom> #vote Yes
20:54:03 <a2hill> :P
20:54:04 <blogan> that was an oddly worded vote
20:54:05 <rm_work> #vote Sandwiches
20:54:05 <sballe> yes
20:54:14 <sballe> #vote yes
20:54:15 <ajmiller> #vote yes
20:54:28 <mwang2> #vote yes
20:54:39 <sbalukoff> 30 seconds to get your votes in...
20:54:53 <dougwig> that does not look like violent agreement nor consensus.
20:54:54 <rm_work> #vote No
20:55:11 <blogan> im so confused, i thought we were aligned
20:55:16 <sballe> yeah weird I thought we were agreeing
20:55:16 <sbalukoff> Me too.
20:55:22 <jorgem> lol
20:55:26 <a2hill> ><
20:55:28 <sbalukoff> #endvote
20:55:29 <openstack> Voted on "Should we couple drivers with taskflow?" Results are
20:55:30 <openstack> Yes (5): xgerman, mwang2, johnsom, sballe, ajmiller
20:55:31 <openstack> No (9): rm_work, a2hill, sbalukoff, dougwig, jorgem, TrevorV, crc32, bedis, blogan
20:55:45 <sbalukoff> The lines seem to be:  HP, and everyone else. :P
20:55:46 <xgerman> the question was confusinf
20:55:49 <rm_work> i should have left myself on Sandwiches
20:55:57 <sballe> rm_work: +1
20:56:08 <sbalukoff> xgerman: How would you have rather seen the question worded?
20:56:23 <sballe> Maybe we should have quickly summarize the solution we were voting for
20:56:28 <blogan> should driver methods return flows?
20:56:34 <xgerman> it seems that blogan and a2hill siuggested an Octavia verison of the task class to use
20:56:40 <sbalukoff> xgerman: If you were basically in agreement with dougwig and blogan, could I ask the three of you to work together on what that 'agreement' is/was and send it to the ML?
20:57:09 <jorgem> the example that phil gave us
20:57:18 <blogan> xgerman: https://gist.github.com/the2hill/0a40cbe6963d8a1097a4'
20:57:21 <blogan> https://gist.github.com/the2hill/0a40cbe6963d8a1097a4
20:57:26 <xgerman> yeah
20:57:29 <a2hill> yea, thats what i was thinking we were going for, that decouples it from the driver
20:57:31 <jorgem> yeah that ^^
20:57:31 <blogan> you're fine with that?
20:58:16 <sbalukoff> Ok, shall we try to vote on that instead in the last minute here?
20:58:17 <jorgem> testing the controller class in that case is also easy to test out with mocking. All the flow logic gets tested easily.
20:58:39 <dougwig> if we run out of time, let's continue this in channel, as people are blocked.
20:58:42 <xgerman> you can test somehting which has undo and execute ina  class easy, too
20:58:46 <sballe> sbalukoff: make sense now that we know what we are voting on
20:59:00 <sbalukoff> #startvote Should we follow this general model for defining driver interfaces https://gist.github.com/the2hill/0a40cbe6963d8a1097a4 ? Yes No Sandwiches
20:59:01 <openstack> Begin voting on: Should we follow this general model for defining driver interfaces https://gist.github.com/the2hill/0a40cbe6963d8a1097a4 ? Valid vote options are Yes, No, Sandwiches.
20:59:02 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:59:11 <a2hill> #vote Yes
20:59:15 <dougwig> #vote Yes
20:59:16 <sbalukoff> #vote Yes
20:59:17 <jorgem> #vote Yes
20:59:20 <blogan> lol
20:59:31 <blogan> #vote Yes
20:59:46 <dougwig> folks have about 20 seconds to vote, given the clock.
20:59:47 <bedis> #vote Yes
21:00:01 <sbalukoff> HP folks? Please vote?
21:00:05 <jorgem> or #vote abstain?
21:00:13 <bedis> they're on strike :)
21:00:14 <blogan> i think we can discuss this in the main channel
21:00:14 <sbalukoff> Sandwiches
21:00:17 <xgerman> well, we will refactor to taskflow like Ml2 in a year anyway
21:00:20 <crc32> #vote abstain
21:00:21 <openstack> crc32: abstain is not a valid option. Valid options are Yes, No, Sandwiches.
21:00:28 <TrevorV> #vote Yes
21:00:36 <sballe> #vote Sandwiches
21:00:46 <rm_work> #vote Sandwiches (I am concerned about the fact that this implies drivers will have undo methods in them, but this may be irrelevant for this discussion)
21:00:47 <sbalukoff> Dang.
21:00:47 <openstack> rm_work: Sandwiches (I am concerned about the fact that this implies drivers will have undo methods in them, but this may be irrelevant for this discussion) is not a valid option. Valid options are Yes, No, Sandwiches.
21:00:56 <rm_work> #vote Sandwiches
21:01:01 <sbalukoff> #endvote
21:01:02 <openstack> Voted on "Should we follow this general model for defining driver interfaces https://gist.github.com/the2hill/0a40cbe6963d8a1097a4 ?" Results are
21:01:03 <openstack> Yes (7): a2hill, sbalukoff, dougwig, jorgem, TrevorV, bedis, blogan
21:01:04 <openstack> Sandwiches (2): rm_work, sballe
21:01:08 <sbalukoff> #endmeeting