20:00:11 #startmeeting openstack-state-management 20:00:11 Meeting started Thu Aug 22 20:00:11 2013 UTC and is due to finish in 60 minutes. The chair is harlowja. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:14 The meeting name has been set to 'openstack_state_management' 20:00:17 hola 20:00:35 (: 20:00:36 \o/ 20:00:42 | 20:00:47 /\ 20:01:01 hi there 20:01:10 hi there 20:01:32 hiii 20:01:42 o/ 20:01:55 #link https://wiki.openstack.org/wiki/Meetings/StateManagement#Agenda_for_next_meeting 20:02:09 so lets get started! 20:02:11 #topic status 20:02:23 anything anyone wants to say about status items that they might be doing 20:02:52 i've been in alot of meetings @ y! and am trying to rework a little of the cinder code i did, splitting it up into more files for easier maintaince for them 20:03:09 and readjusted the persistence layer and am updating the resumption logbook code to use it 20:03:23 thats currently it from me, watching code reviews and helping there to :) 20:03:30 and talking to other people about integration 20:04:22 Yeah, I'm actually currently trying talk trove integration in their IRC 20:04:23 heh 20:04:28 They're having a task scheduler meeting 20:04:40 :) 20:04:49 That got postponed until about another 15 min, so that will wait a bit 20:04:51 haha 20:05:04 But mostly I've been working on trove integration 20:05:05 ya, same with me and glance, trying to do doulble-meetings, not so easy, ha 20:05:12 hi, I'm present. 20:05:13 Ah, yeah 20:05:29 hi kebray 20:06:06 melnikov and anastia i think are busy helping out make taskflow core be really good 20:06:14 i've been working on pattern/engines stuff with akarpinska; then taskflow decorators came in the way, and i refactored them a bit 20:06:27 sweet 20:06:29 Yeah - I really liked your git-review for that melnikov 20:06:37 Forgot to comment on it and what not though. :x 20:06:54 I read through the code in examples, and plans to read the persistence code when it is done by harlowja. Also people in my group are working a cloud QoS project and are very interested in taskflow .We probably will use the library. 20:07:03 awesome! 20:07:26 thx changbl ! 20:07:47 :D 20:07:49 np ~ thanks for making this great library, folks 20:08:15 it will be super great soon to! 20:08:45 changbl anything u think dislike/like maybe u have some thoughts on to, maybe can discuss later 20:08:57 the more feedback (good, bad, sucky) is useful always 20:09:07 anytime someone pulls TaskFlow into a project, and if it's a positive experience, I'd love to see a shout out for it on the dev mailing list, or a link to a video demo showing the integration or a link to a blog article about how it's helped. just saying :-) 20:09:20 videos! 20:09:21 haha 20:09:36 I just wow'd the trove room with my video. They're thinking about making a sock puppet version 20:09:42 lol 20:09:46 +2 20:09:54 haha 20:10:21 But yeah, +1 kebray. Happiness everytime someone pulls in taskflow. :P 20:10:32 +1 20:10:32 +1 kebray 20:11:08 coolness this flows into a good next topic, unless other status anyone has? 20:11:27 topic: vote for presentation? 20:11:39 #action harlowja make sock puppet video of taskflow too 20:11:42 right now in the examples, i feel a bit awkward to specify tasks: provides, requires, __call__, not sure how we can make it simpler, though. I will take a deep look at harlowja 's create_volume code in cinder 20:12:08 changbl yes, its a known contention point, the way to establish dependencies between tasks 20:12:22 i'm not sure if melnikov wants to change that, or wait for that change, unsure 20:12:37 lets hold on this discussion though 20:12:48 kebray lets jump into one more topic before yours 20:12:53 #topic coordination 20:13:08 I use billingstack :) 20:13:13 ekarlso- +1 20:13:18 with TF 20:13:39 so with the ongoing work integrating and awareness of taskflow, and dev<->dev communication, its picking up steam, which is great 20:14:08 i'm just wondering if we want to designate a person to do this nearly full-time, like talk to glance folks, talk to others about not recreating taskflow, but integrating with it instead 20:14:23 and getting concepts that they have that taskflow doesn't have (and which make sense) in taskflow 20:14:30 sorta like a integration person if u will 20:14:56 looking for volunteers, i don't mind trying to do it also, but that means less time coding 20:15:30 i just think the importance of reach-out is getting more important, trove, glance and others i think are recreating there own mini-task thingies 20:15:50 and if we educate/interact with them we can likely redirect there energy instead of creating there own 20:15:53 thoughts? 20:16:14 i know we have docs, but not everyone reads them (so thats where the interaction comes into play) 20:16:33 kebray adrian_otto maybe u have some thoughts releated to this, since u guys have more experience here 20:16:47 *more experience than me 20:17:40 harlowja I think we spread the work for now.. and, use this meeting to coordinate reach-out-efforts. I spend most of my week on Heat. adrian_otto has a bunch of other things he regularly works on.. but, we can all help. 20:18:23 ok, maybe thats ok for now to 20:18:26 ok 20:18:29 If you can make it your FT job, awesome! FWIW, jlucci is 100% TaskFlow... so, I can help her connect with others too. 20:18:40 (reading scrollback) 20:19:05 lets see, i'm not sure about FT integration person yet, but maybe :) 20:19:13 if i need to do that, i will :-P 20:19:23 * kebray thinks harlowja and jlucci will connect best with the other devs... and, myself can connect best with other engineering managers and product managers. 20:19:35 Documentation should be out top priority 20:19:41 s/out/our/ 20:19:51 agreed, still though, people just don't read it, ha 20:19:57 i.e. make it simple. 20:20:04 k 20:20:11 I'm happy to carry the evangelism role, which I intend to continue at the HKG summit 20:20:34 but if the docs are not awesome, it's going to fall to the devs with the first hand knowledge of the code 20:20:37 i think kebray is a good idea, 2 types of evanagelism i think 20:20:48 agreed, adrian_otto the docs should be awesome 20:21:10 i think i might spend a piece of my day tommorow scanning through them for improvements 20:21:15 in terms of answering the full time role, I doubt that's practical for this particular project 20:21:18 #action harlowja scan through wiki, adjust and make better 20:21:44 adrian_otto well not full time, until critical mass though reachout seems like it would be a fulltime thing 20:21:47 but maybe not 20:21:51 I would prioritize making the solution compelling and helpful, and producing docs to match 20:22:07 all of the most successful open source projects had great documentaion 20:22:23 because docs scale, where handholding does not. 20:22:38 sure, maybe we can just continue managing both, code and docs and reachout, i think we've been doing it pretty well so far 20:22:45 agreed, handholding doesn't in the end 20:23:08 we should offer handholding to key groups in the beginning 20:23:22 well not just key groups, anyone and everyone i think :) 20:23:29 particularly those projects that can really benefit from using the library 20:23:37 sure 20:24:10 well, adoption is important, but having it adopted where it makes a meaningful difference counts more. 20:24:32 FYI guys - in the middle of trove IRC convincing them taskflow is awesome. If you need me, just @ me 20:24:32 hmmm, that brings in the definition of 'meaningful' 20:24:42 yes, indeed. 20:25:17 that means that users of the end solution get something as a result… like a new feature, better performance **better relaibility**, crash recovery, etc. as a result of using Taskflow 20:25:33 the story needs to be more than "I wrote less code using Taskflow" 20:25:56 ah, gotcha, i think i misread your line above 20:25:58 yes, that makes sense 20:26:01 but that "I got crash recovery, and would never have attempted it otherwise" 20:26:16 that's what I eman when I refer to "meaningful" 20:26:23 kk 20:26:24 s/eman/mean/ 20:26:43 as long as 'meaningful' doesn't mean only the core projects of openstack, i think thats fine 20:26:59 just say no to discrimantion, ha 20:27:42 of course. Adoption is an indication of success, and we should enable it as best we can. 20:28:22 sounds good, so for now, i think we can continue our reachout and coding and integration, as long as its not causing anyone problems 20:28:29 Making OpenStack more resilient and reliable is a huge advancement, and one I think can be enabled with what we have started on here. 20:28:42 that meets my criteria of meaningful 20:28:51 sure 20:29:29 parting thought on this subject: lets all kick up our effort level on docs by at least one notch. 20:29:41 agreed 20:29:43 that should pay off in spades 20:30:06 sounds good, lets try to do that also 20:30:52 #topic vote-for-presentation 20:31:04 so kebray what were u thinking of 20:31:30 making sure everyone has voted :-) 20:31:53 Anyone active in this channel right now not voted for the presentation? 20:32:10 * kebray searches around for link. 20:32:15 let me vote, link to the talk? 20:32:18 ah, that vote 20:32:19 gotcha 20:33:07 #link http://www.openstack.org/rate/Presentation/taskflow-an-openstack-library-that-helps-make-task-execution-easy-consistent-and-reliable 20:33:17 thx kebray , u found it before me 20:33:37 don't forget to vote folks, ha 20:33:53 * harlowja durn why is picture still not there 20:33:53 and tell your friends. 20:34:25 yup, and tell your friends friends 20:34:56 ok, lets open up for any further discussion 20:35:01 #topic open-discuss 20:35:32 so changbl back to the question about provides/requires, melnikov are u still around 20:35:44 yup 20:36:05 melnikov are u thinking about adjusting how that works, or not yet 20:36:24 provides/requires connect into the concept of dependency chaining and how tasks transfer 'memory' 20:36:40 changbl would u prefer a more manual way of connecting them 20:36:47 *explicit 20:37:58 i think there is room for improvement, yes of course 20:38:14 basically what I can want is that i write very few and natural code when using the library 20:38:24 agreed 20:38:45 right now, i think there are some overlap between declaring provides/requires and __call__ 20:39:15 yes, there is, __call__ args can be examined to find what is required 20:39:19 as for __call__, akarpinska wanted to use simple execute(...) method instead 20:39:47 i tend to agree, execute/revert make nice simmetry 20:40:09 harlowja, yes, examining __call__ to find out what is required would be better 20:40:33 __call__ => execute, just renaming? 20:40:49 changbl, as a first step 20:41:20 melnikov, any more planned changes? 20:41:24 so the provides one are the weird part changbl, that one is hard to automatically determine, i think we could just switch to args examination (except if someone uses *args, **kwargs) 20:41:31 Hey guys - I have to run to my puppy class, but the Trove guys are definitely interested 20:41:34 kk 20:41:46 thx jlucci 20:42:04 Sorry for the interruption - I'll look back over the meeting notes later tonight. :D 20:42:07 np 20:42:18 harlowja, ok, at least we can remove one overlap 20:42:23 sure 20:42:48 although i think provides might be able to be somewhat removed also, it ties into the question of how much inference is useful/possible 20:43:13 the nice thing about the inference is that it allows us to easily reconnect all tasks on failure of whatever was running them 20:43:52 although if u think of a raw engine, u might not need the inference at all, the engine will just have enough state to continue running, not caring about the reconnect 20:44:25 ex, a car engine doesn't care about the surronding system, it just will run if provided gas, something else gets the gas to it (gas == flow) 20:44:35 car engine analogy ftw 20:45:35 something to think about maybe :-P 20:45:43 not sure of the analogy on engine, melnikov is working on the engine code now? I can take a look 20:46:25 yup, i'm working on separating flows on patterns and engines -- there's blueprint for that 20:46:52 #link https://blueprints.launchpad.net/taskflow/+spec/patterns-and-engines ? 20:46:57 the code will be on review later, idk tomorrow or next week, stay tuned;) 20:47:03 thx melnikov 20:47:14 ok, thanks melnikov 20:47:35 so changbl i think it will get a little easier soon, i believe 20:47:41 harlowja, yes, that bp 20:47:45 harlowja, that's great 20:48:10 it will be a balance though, making it to easy, and it just gets us back into writing python and the library doesn't offer what we are saying it, offer/change to much and it gets hard to use 20:48:23 *saying it does 20:48:47 ekarlso- yt 20:48:48 harlowja, right, we should get more feedback from other users 20:48:53 agreed 20:49:09 ekarlso- and i were talking about how async tasks can work in a flow 20:49:33 which slightly connects into https://review.openstack.org/#/c/34488/ being a potential way to do this 20:49:59 although maybe after melnikov work we can revisit how this can be done 20:50:25 i think ekarlso- wanted to fire off something, then have dependent tasks not activate until whatever that was fired returned 20:51:18 although i'm unsure of the reverting condition for such an async activity, is the revert fired after a timeout, idk 20:51:24 threaded graph flow is a great idea 20:52:35 i think its useful for these types of situations (although one greenthread per-thread might start taxing the python memory usage) 20:52:44 greenthread per-task i mean 20:53:22 why are you unsure of reverting condition? got a bit confused 20:54:02 hmmm, maybe there isn't any problem now that i think about it 20:54:45 i'll continue working with ekarlso- to understand what his usage is about 20:55:05 in a typical linear flow, if one task blocks, then all do 20:55:08 harlowja, all right 20:55:17 Btw, do we have any status update on getting taskflow integrated into other openstack projects? 20:55:18 threaded flow, only those that have dependencies on the blocking task will block up 20:55:45 trove is underway via jessica, cinder i'm continuing with, also starting conversations with glance 20:55:57 and i think a few others are popping up, ekarlso- is doing billingstack 20:56:37 glance i think could be another user, we'll see how the timelines match up 20:56:53 ok, cool. Very promising 20:57:02 yup, cool 20:57:08 alright, any other stuff, 3 minutes! 20:57:27 if not #openstack-state-management is where you'll find us (most of the time) 20:58:12 ok, thx for showing up folks :) 20:58:16 till next week 20:58:26 #endmeeting