20:01:14 #startmeeting state-management 20:01:15 Meeting started Thu Aug 1 20:01:14 2013 UTC and is due to finish in 60 minutes. The chair is harlowja. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:18 The meeting name has been set to 'state_management' 20:01:57 howday all! 20:02:04 hello there 20:02:13 hi hi 20:02:23 Hi 20:02:28 hi hi 20:02:51 * harlowja waits a few for others 20:03:26 jlucci u around, kevin? 20:04:08 ok well anyway, all fine 20:04:14 #topic status 20:04:35 so i've been trying to rebase the cinder patch and make sure thats all working, currently hitting some CI weirdness 20:04:43 #link https://review.openstack.org/#/c/29862/ 20:04:55 working with the infra folks to try to figure out whats going on 20:05:15 also trying to help do reviews at the same time (and other internal y! stuff) 20:05:23 harlowja my apologies, I just got summoned to another meeting. 20:05:27 np 20:05:28 Yeah I'm here -sorry 20:05:35 Just got back from Dallas a couple minutes ago 20:05:38 ?? 20:05:39 woah 20:05:41 ha 20:05:48 Yeah. I'm that good. haha 20:06:09 np, just going through status, not sure if u have anything to mention 20:06:30 kebray i think submitted the speaker session, so thx kebray :-) 20:06:39 Um -just the distributed stuff online, and about to have a tasfklow video/tutorial thingy online 20:06:47 Was just going to e-mail it out to openstack-dev 20:06:49 about, wow 20:06:52 nice 20:07:01 very cool 20:07:09 speaker abstract btw 20:07:12 #link https://wiki.openstack.org/wiki/TaskFlow/HavanaSummitPresentationAbstract 20:07:18 (for HK summit) 20:07:31 Awesome kebray :D 20:07:40 good job, like the abstract 20:07:45 yahoo will hopefully have a few others, time will tell :) 20:08:16 changbl thx for fixing a few issues u found :) 20:08:27 np, the code is written well:) 20:08:37 i looked through the code base 20:08:59 ha, its a continual WIP, thx 20:09:19 sure, will keep watching the code :) 20:09:20 akarpinska1 anything for u to report, know its late for u so thx for showing up 20:09:32 don't give up on blocks, still think it has a place :) 20:10:15 thx changbl the more eyes the better of course :) 20:10:50 I'm a little bit confused about what I really need to do with my TaskFlow tasks and with my patch. Want to hear some comments about it. 20:11:59 sure, np 20:12:14 akarpinska1 - anastasia I'm guessing? 20:12:20 yes 20:12:32 haha Awesome. Yeah - I'm still looking through that doc you sent out 20:12:48 so akarpinska1 i put a few review comments up, nothing major, so that will be part 1 i think 20:13:05 kevin i think will land his db stuff soon to, so then there will be the question of how thats used there to 20:13:10 Awesome. I'll get to those/doc as soon as I post that video 20:13:22 yup. got about 2/3 of it commented today 20:13:26 sweet 20:13:30 taking a break from commenting for a little bit 20:14:00 but it will be up there by tomorrow morning at the latest 20:14:19 akarpinska1 so also once jlucci i think is ok with the block stuff (or other comments) then i think that will allow for a little more work there, then we can get that in, make more adjustments and such 20:14:24 kchenweijie sounds great 20:14:28 more comments the better :) 20:14:40 akarpinska1 sound good? 20:14:58 its a in progress library, so nothing will always be clear :) 20:15:03 although i'll try to help it be, ha 20:15:46 of course 20:15:55 sounds great 20:16:40 #topic projects_using 20:17:04 so if its fine just want to see where we are with other projects on getting usage of taskflow in 20:17:18 after i fix this cinder stuff, i'm gonna try to see about possible nova 'small' use-case soon 20:17:32 akarpinska1 might also be doing another cinder use-case, which is cool 20:17:38 Awesome - I'm getting ready to start doing some trove integration 20:17:39 and jlucci maybe reddwarf/trove 20:17:40 dkranz: mtreinish: there is regex exclusion 20:17:41 cool 20:17:50 dkranz: mtreinish: will find you in -qa to follow up. 20:18:09 lifeless: Thanks. 20:18:16 hmmm 20:18:19 I think, we need to choose one implementation and then apply it to Cinder 20:18:51 Implementation being patterns, or current task flow vs. new block approach? 20:18:57 Now we have two commands rewritten in different manner 20:19:13 Can I ask what is "block"? 20:19:26 https://review.openstack.org/#/c/36472/ 20:19:34 It's a new way of running tasks 20:19:47 I'm sure akarpinska1 can explain it much better than me though. (: 20:19:59 what is different? any brief intro? 20:20:13 akarpinska1 i'm fine with picking one way, just unsure which way still, i think the current refactoring can be adjusted, but i don't want to miss H release for that 20:20:59 There is a documentation https://docs.google.com/document/d/1376-8vRgJRvbvQLY4ZBqmClJVa3HwCOaMoO2yRpOC1o/edit?usp=sharing 20:22:04 to me a block is similar to a way to structure a task right 20:22:15 *structure the way a task set is ran 20:22:41 which also can be composed of sub-blocks 20:23:22 ok 20:23:30 harlowja: in your implementation there are three types of flows, blocks give us a possibility to combine different behavior in one flow 20:23:33 will read the doc, thanks 20:23:54 akarpinska1 ya, which i think is good 20:24:03 changbl thx, hopefully it makes it more clear 20:24:13 harlowja, np 20:24:34 also I tried to split it on small components to make it flexible to change 20:25:14 ya, which is good stuff, i'm still myself trying to figure out how it fits, thats all :) 20:25:56 the challenge becomes make something really easy for library users to use, without adding to much new syntax/structure that they need to learn 20:26:13 agree, harlowja 20:26:22 blocks has alot of new structure right now that they must learn, thats my current worry about it 20:26:26 but user need to know only about the blocks 20:26:28 as long as it can do the job, the simpler, the better 20:27:54 by default user should know nothing about the actions and builders until he wants to change internal implementation of the flow 20:28:40 User will describe his tasks and the flow structure with the blocks. That's all 20:29:13 sure, sure, not saying its bad or anything, just the block way does require a little bit more learning 20:30:26 i'm still working through my understanding of it also, so it might just be fine :) 20:30:46 its just the harder it is to compose these, the more pushback i think we will get 20:31:07 the nice thing about the linear_flow is that it likely solves most of the use-cases of openstack, ha 20:31:21 i can see the sequential block possibly being the same thing 20:31:54 Yes, like in Cinder create_snapshot, I used only the sequential block 20:32:09 ya, i'll try to find some time to mess around with the code also, that i think will help 20:32:30 maybe jlucci and changbl and others with free time (if any) can also 20:32:38 sound good akarpinska1 ? 20:32:56 sure, will read the code and help with code review 20:33:02 thx 20:33:03 Sounds good 20:33:10 Will be excellent to get feedback 20:33:13 def 20:33:28 sounds great 20:34:05 i had another random idea also, but might not be needed if blocks works out 20:34:08 #link https://wiki.openstack.org/wiki/TaskMachine 20:34:20 something else to read over, ha 20:34:23 might be to much though 20:34:41 let me change topic to open discussion, since thats more releated to that :) 20:34:46 #topic open-discuss 20:35:32 one question: shall we have more examples in docs/ ? Those examples are quite helpful 20:35:45 i think so :) 20:36:02 harlowja, great 20:36:04 i'll try to make some of those up also, jlucci will your video introduce any? 20:36:25 akarpinska1 if u have any thoughts on https://wiki.openstack.org/wiki/TaskMachine let me know 20:36:35 it might be to similar to blocks that its not needed 20:36:40 Interesting, trying to understand 20:36:43 np 20:36:55 Yup. Although the video is geared towards a distributed backend, so the majority of the examples lean more towards that pattern 20:37:07 sure sure 20:37:24 looking forward your video, jlucci 20:37:43 changbl i think after we get some of the DB stuff in it will become really neat with examples 20:37:55 harlowja, yep! 20:38:03 like start a example process, have it do something, kill it, then see it resume after starting another process up 20:38:13 like magic, ha 20:38:37 hehe 20:38:58 But yeah - the DB stuff will provide for a ton of new functionality 20:39:17 akarpinska1 the idea was along the line that all these task things could be instrumented in a 'machine' that is devoted to running them with its own concept of 'memory' 20:39:24 then openstack is powered by a machine that runs tasks 20:39:25 ha 20:39:32 was just an interesting idea :-p 20:39:48 *not a physical machine, but a mini-one that runs in memory 20:40:04 and has enough control over what its running and its own 'memory' that we can just save/restore the machine 20:40:13 I'm trying to imagine how it can be implemented) sounds interesting, but it can be a lot of questions 20:40:27 well its similiar to the block stuff i think in a way 20:40:37 you have a concept of 'memory' there 20:40:44 and a runtime stack (block structure) 20:41:24 flow.kwargs is a memory ) 20:41:27 ya 20:41:36 so they are similar in that way 20:41:48 if we had such machine it could be the base for all other patterns ontop 20:41:52 block pattern, linear, ... 20:41:59 *maybe* 20:41:59 I thought about some flows manager, maybe it can be a TaskMachine 20:42:11 possibly could be 20:42:36 the neat thing about the machine is that i think jlucci and all the dynamic stuff that is wanted there can also use the same machine 20:42:46 i'm not sure how blocks would fit into the dynamic modification model 20:42:56 Yeah, I'm still working through that 20:43:10 Need to get more familiar with the block code as well before I can really say something one way or the other 20:43:15 ya, same here :) 20:43:31 me too ~ 20:43:33 But one problem is that the service executes each command in the separate thread, as I know 20:44:00 what do u mean there 20:44:50 if we have a task machine, OpenStack services must be redesigned not to create a thread for the API request, but to redirect it to the TaskMachine 20:45:06 well depends on what level it is integrated with 20:45:22 an API request could just use a pool of machines 20:45:26 or make a new one 20:45:44 doesn't have to be 1:1 since the machine isn't phsyical 20:45:49 one machine for one request? 20:46:05 well the machine is just software, so it could be that 20:46:37 probably to complex for the foreseable future i think, but an interesting idea, ha 20:46:48 most of openstack i think will do with the basics for a long time, ha 20:47:03 *or be happy with the basics, even just the restructuring into 'tasks' is a big accomplishment 20:47:21 so maybe this is at stage ++++++ 20:47:22 haha 20:47:43 extremely like this is the case:) 20:47:49 ;) 20:47:52 s/like/likely/ 20:48:51 ya, interesting to think about, i'm pretty sure it will take a while to just do the task restructuring in all the projects 20:48:56 one machine for the whole service can easily lock resources 20:49:22 ya, akarpinska1 i don't think we would want 1 'task' machine 20:50:08 but if we can offer some neat possiblities, which i think we already are starting to, the more adoption we will get, which is great, but have to keep the complexity low, but features high, not an easy balance :) 20:50:24 1 machine for one request is easily to implement =) 20:50:57 akarpinska1 ya, it likely is, it becomes an interstsing question if the 'machine' thing could be the base for all task patterns 20:51:11 be nice to have 1 lowest level component that everything is built on for said patterns 20:51:17 blocks, distributed... 20:51:52 In my implementation Flow class is like a flow controller, maybe it could be a machine later 20:51:53 the neat thing about the machine is that there can be conditional tasks that let u choose which task to put on the 'machine' stack next 20:52:10 akarpinska1 it might be able to 20:53:05 anyway, somethign to think about, think if we can get more project adoption that will be the key for the short-term 20:53:28 which means just beginning to use what we have and adjusting openstack code to use it, while at the same time learning from said adjustments and changing taskflow 20:53:43 then we'll have the best library and the usage in openstack in many places :) 20:53:45 a win for all 20:54:11 :D 20:54:18 sound good to everyone? :) 20:55:02 yup 20:55:15 sweet! and just in time 20:55:28 any further stuff, #openstack-state-management 20:55:32 keep up the good work all! 20:55:57 thanks 20:55:58 harlowja, sounds good 20:56:01 :) 20:56:07 agree :) 20:56:24 woot 20:56:26 #endmeeting