20:00:26 #startmeeting state-management 20:00:27 Meeting started Thu Oct 17 20:00:26 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:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:30 The meeting name has been set to 'state_management' 20:00:39 howdy folks 20:00:47 state-management fun time starts nnooow 20:00:53 #link https://wiki.openstack.org/wiki/Meetings/StateManagement#Agenda_for_next_meeting 20:02:27 anyone here, ha 20:02:30 if not, short meeting :-P 20:02:40 Hi, I am here 20:02:46 hi hi 20:02:48 Hi. 20:02:53 hi there 20:02:55 hello there 20:02:59 howdy 20:03:03 new people, sweet! 20:03:12 * harlowja will wait a few for others 20:04:30 alright :) 20:04:40 #topic last_time_action_items 20:04:55 #link http://eavesdrop.openstack.org/meetings/state_management/2013/state_management.2013-10-10-20.00.html 20:05:04 i think i had the action items so can describe results 20:05:17 one was from a previous week, and finally did it @ https://wiki.openstack.org/wiki/TaskFlow/Best_practices 20:05:26 some of what i consider good practices for taskflow usage 20:05:34 *feel free to tell me they aren't good, ha 20:06:19 melnikov do u want to add any, or do those sorta make sense? 20:06:27 *if u've checked them out 20:07:43 other things i was supposed to do 20:07:53 manila chit-chat about taskflow 20:07:53 i checked them out, looks nice 20:08:17 so i did manila chit-chat, gonna talk with one of there folks about taskflow (who is actively using/investigating it) 20:08:27 since manila is based off cinder, they'd like to follow some of the same patterns 20:08:38 thx melnikov 20:09:49 alright, don't think there was any other action items that i can remember 20:09:59 #topic overall-effort 20:10:24 so i think today is a pretty big milestone for us, 0.1 i think will be going onto pypi very shortly 20:10:40 its been like 4 months to get here, and i think we have a pretty good base to move forward with :) 20:10:52 i still see a few commits in review? 20:11:04 ya, 2 i think 20:11:13 i don't expect the infra people to +2 for a day though 20:11:25 Sounds great. Is it related to Havanna release, or these are independent milestones? 20:11:26 #link https://review.openstack.org/#/c/52283/ 20:11:36 #link https://review.openstack.org/#/c/52462/ 20:11:49 ativelkov_ for now they are independent milestones, although i think its good to keep in a similar pace 20:12:30 so after i think 2 more reviews, melnikov do u want to approve, https://review.openstack.org/#/c/51338/ 20:12:48 then when the above 2 reviews are infra approved, a package should show up on https://pypi.python.org/pypi/taskflow 20:12:56 *at least thats what the infra people told me would happen, ha 20:13:11 +- some additional voodoo, ha 20:14:32 I guess commits like (https://review.openstack.org/#/c/52352/) will be left out from 0.1? 20:14:52 lets see, hopefully melnikov can get your comments addressed 20:15:08 i think its ok if it is, i don't think its critical 20:15:14 k 20:16:09 so thanks to all that helped make it possible :) 20:16:55 *high five* 20:16:55 ha 20:17:03 harlowja: I have some questions on the BestPractices page. Shift over to #state-management or just talk about them here? 20:17:03 +1 to all 20:17:19 caitlin56 maybe in open-discuss we can do that? 20:17:22 +1 20:17:35 ^^ for high five) 20:17:41 harlowja: sounds good. 20:17:53 coolness 20:18:30 so i hope by this weekend, we will have 0.1 package on pypi, all things working out, it seems reasonable 20:18:53 *unless i missed some voodoo that i have to do 20:19:02 i hoped to address those two storage things before release 20:19:24 if anyone knows i missed some voodoo, please let me know :) 20:19:24 should finish tomorrow 20:19:52 sounds good melnikov 20:20:05 #topic integration next steps for icehouse 20:20:30 so this one is an interesting one, and i think we have some good traction that likely will just have to wait for the summit to see whats next 20:20:44 although i'm all for trying to work with others before the summit, and i think we have some of that ongoing 20:20:52 nova @ https://etherpad.openstack.org/p/IcehouseConductorTasksNextSteps 20:21:09 cinder, https://etherpad.openstack.org/p/CinderTaskFlowFSM 20:21:10 and a few others 20:21:16 and lots of summit sessions 20:21:39 so i think we can just continue that, try to organize as much as we can, and then 'just make it happen' 20:22:13 maybe we should start a common icehouse etherpad, sound reasonable? 20:22:26 to keep track of what/where/who 20:22:42 sounds good 20:23:03 k 20:23:08 #action harlowja start that etherpad 20:23:13 what about adding milestone to launchpad, to tag blueprints and stuff 20:23:26 agreed 20:23:35 melnikov do u want to try that, i think its not so hard 20:23:48 what future milestones do we have now? 20:24:10 0.2? :) 20:24:15 haha 20:24:19 contents? 20:24:31 i think we need to get the basic job stuff going, since thats missing 20:24:50 and maybe a basic locking api 20:25:11 or others on https://blueprints.launchpad.net/taskflow that people think are relevant 20:25:44 it'd be nice to have basic https://blueprints.launchpad.net/taskflow/+spec/conditional-flow-choices to 20:25:50 *etherpad there on whiteboard 20:25:56 and whatever else comes out of icehouse discussions 20:26:03 seem reasonable? 20:26:30 * harlowja we can adjust the priority of those blueprints if we want to 20:27:00 When do you plan to release a version 0.2? 20:27:31 i thinking we need just one Icehouse milestone, and release 0.2 (0.3 and so on) as soon as we have enough major features ready 20:27:38 *thought 20:27:59 Can someone illustrate more on conditional flow? seems we are making flows more complex 20:28:09 i'm fine with that, melnikov so at openstack milestones we would have a declared 'major' release, minor in between 20:28:11 Sounds good. I am just thinking about other project that might depend on taskflow. 20:28:31 Thay will not want to wait until Icehouse official release. 20:28:46 sure, then they can take in minor releases? 20:29:02 They can always use the latest trunk as well 20:29:12 * caitlin56 agrees with gokrokve. I want to add cinder code using taskflow by end of icehouse, not be ready to code for j*whatever. 20:30:31 So you need to have 0.2 release tested and release at Icehouse M1 to allow others to use stable version for development and testing 20:30:32 caitlin56 i think thats fine, there will be a release, just i think what qualifies as 0.2 (0.3...) we can debate on, maybe each blueprint is a minor release 20:31:08 we need an API freeze date well before the implementation freeze date. 20:31:31 sure, seems reasonable 20:31:37 harlowja: You can do a release per feature but your VC tree will have a lot of branches for parallel deelopment. 20:32:07 API freezy sounds very reasonable. 20:32:16 API freeze sounds very reasonable. 20:32:34 ok, then maybe a good idea is for folks to check out https://blueprints.launchpad.net/taskflow and think about what they want in 0.2, the above was my suggestion :) 20:32:46 and i don't think those suggestions alter the API 20:33:07 then we can come back to this also after summit discussions 20:33:08 I think you need to have some estimations for each BP and than plan release 0.2 accordingly taking into account dates and estimations. 20:33:22 Don't forget to multiply ETA by 2. :-) 20:33:26 ha 20:33:43 also depends on who is going to do all those BPs ;) 20:33:49 or even 3.1415 :) 20:34:09 ya, release 0.31415 ftw, ha 20:34:39 harlowja: this is multiplication factor Pi for estimations :-) 20:34:46 ah 20:34:49 haha 20:34:53 right :) 20:35:05 * caitlin56 isn't sure that you want to admit a given release is irrational. 20:35:11 kind of a joke, but it usually works pretty well from the experience 20:35:15 :) 20:35:42 ok, so how about the following, we can work on https://blueprints.launchpad.net/taskflow and expand and clear those up, so certain ones are more clear (addressing changbl question) 20:36:04 and we can then see about 3.145 estimations 20:36:10 and then come back here and fight over that, ha 20:36:20 *don't all take all the work at once, ha 20:36:25 Sounds good. 20:36:29 harlowja, please assign zk-logbook BP to me 20:36:32 good to me 20:36:33 sure 20:36:42 cool 20:37:10 So lets agree that on next meeting we will have rough estimations for each BP. 20:37:12 and if some of them aren't clear, #openstack-state-management so that we can make them clear 20:37:17 i think thats fair gokrokve 20:37:31 *and pretty detailed summary of what it is 20:37:36 By the way who is responsible for testing? 20:37:50 mr.jenkins 20:37:59 :) 20:38:14 haha 20:38:21 so u have only unit tests? 20:39:07 correct, but its a library, so we can pretty much tests the full system 20:39:09 I believe it doesn't assume anything else 20:39:20 yep 20:39:23 * harlowja not sure what a integration test would mean in this case 20:39:25 You really need two distinct layers of testing. 1) test the engine. 2) test the patterns that use the engine. 20:39:30 ya, we have that 20:39:32 understandable 20:39:33 ok. so we have ongoing testing with jenkins. 20:39:39 *mr.jenkins 20:39:43 :) 20:39:59 yes, on going mr.jenkins tests stuff 20:40:09 *not sure of the coverage, although we can probably get it 20:40:10 it's all, in fact, unit testing 20:40:14 i think we've been pretty dillegent about it 20:40:19 What is the coverage? 20:40:46 unsure, haven't ran that, we should probably get an idea there 20:40:51 Do you use static analysis? It should work great for library like code. 20:41:08 ya, openstack uses pylint and flake8 which are its static analysis 20:41:13 The syntax allows specification of patterns that make no sense. So exhaustive testing is clearly not feasible. 20:41:15 *as static as u can get 20:41:36 gokrokve and mr.jenkins runs those static analysis for us 20:41:42 ok. 20:41:42 mr.jenkins is very nice 20:41:49 i think we can get him to run coverage for us to 20:41:59 just likely haven't turned on that job 20:42:23 i can investigate that, shouldn't be hard 20:42:33 Yes. It will be great. It is a good indicator of confidence. 20:42:40 sure 20:42:48 #action harlowja see about turning on coverage 20:43:01 i think its a small change to do that 20:43:02 but not 100% guarantee, imho 20:43:16 is anything a 100% guarantee :) 20:43:28 not even US government 100% guarantee 20:43:29 ha 20:43:29 This is a real life. Nobody guarantee 100%. 20:43:29 ok, even 80% 20:43:30 :) 20:43:55 +1 not even US government 100% guarantee :) 20:43:58 ;) 20:44:07 I mean, I've seen people making test coverage 100% 20:44:26 taskflow not recommended for missle/mars usage 20:44:26 buy the system kept working wrong 20:44:39 *my disclaimer, ha 20:44:40 I saw projects with 100% coverage and great failures in production :-) 20:44:41 *but 20:44:51 exactly 20:45:01 if u running your missle system on taskflow, u might want to reconsider, ha 20:45:23 coverage is not a purpose itself, need to realize that 20:45:31 +1 20:45:36 not a goal evean 20:45:40 even 20:45:54 k, i'll get u guys that going 20:46:15 switching topic :) 20:46:20 #topic HK summit speaker ideas 20:46:26 Yep. I remember a story when Soviet Lunar probe missed Moon because of floatin number used in math library. Small errors produces a big deviations on large scale. 20:46:42 :)))) haha 20:46:42 ya, i think NASA did the same thing with mars 20:46:51 some metric conversion problem, lol 20:46:53 and not once :))) 20:47:19 #link https://etherpad.openstack.org/p/TaskflowHKIdeas 20:47:24 so i tried to fill in more of that one 20:47:39 *although currently the page isn't loading for me :-/ 20:47:43 ah there we go 20:47:47 I have seen that 20:47:57 i'll likely have to slim it down 20:48:02 as i start making slides and stuff for the speaker stuff 20:48:06 good points, nothing actually to argue about 20:48:17 rakhmerov in openstack, always something to argue about :) 20:48:25 i bring my battle armor 20:48:30 harlowja: Do you have a presentation on HK summit? 20:48:30 well, not in this case :) 20:48:38 seriously 20:48:46 gokrokve yup, not only presentation, complete speaker session 20:48:53 good point to bring up on the summit 20:48:54 where people ahve to listen to me and kebray talk 20:48:59 *points 20:49:34 #link http://openstacksummitnovember2013.sched.org/event/29f1f996b36aaf0febc5d43b6f53f2a4#.UmBNWSSoV-Q 20:49:34 Great. 20:49:51 if u guys want to writeup some mistral stuff, i can try to include also 20:50:01 since Convection is mentioned in that overview 20:50:07 *aka mistral 20:50:26 seems mistral is quite similar to what taskflow does? 20:50:38 i read the blog from mirantis 20:50:38 well, I think we have things to discuss in this context 20:50:39 harlowja: Sure. 20:50:55 changbl ongoing discussions there, is mistral just a API/service using taskflow... 20:51:00 idk quite yet either 20:51:08 got it 20:51:15 changbl: It is not a substitution of taskflow. it is a next layer around taskflow. 20:51:15 we need to figure out 20:51:25 changbl of course 20:51:32 working with gokrokve rakhmerov (and others) on that 20:51:38 #openstack-mistral 20:51:43 basically, yes, that's right. Mistral was targeting to implement ideas in Convection 20:51:44 but 20:51:56 We have so many ideas above that :))) 20:52:03 lots of ideas :-P 20:52:12 right :) 20:52:23 so rakhmerov gokrokve not only speaker session, but also summit sessions 20:52:24 dont' be angry at me for this :)) 20:52:32 rakhmerov, you are here, you wrote the blog:) 20:52:32 ha 20:52:34 can we have a combined meeting with Mistral folks prior to summit? We should figure out our similar and different views and at least know where we all stand prior to summit. 20:52:50 kebray i think thats a reasonable ask, i'd be up for that 20:52:51 Anyone want to volunteer to pull that meeting together? Can be over IRC, or google hangout, or whatever. 20:53:05 yeah, that's exactly what we're trying to do 20:53:09 If not, I'll do it.. but, would prefer if someone else can drive it. 20:53:18 also i have http://summit.openstack.org/ (search for taskflow) so those are 2 different type of meetins 20:53:25 rakhmerov i think is workin on that 20:53:28 we have so many great things to discuss, you won't believe :) 20:53:32 a 20:53:34 *ha 20:53:42 *waiting for mind to be blown 20:53:51 rakhmerov cool.. good to have more people involved! 20:54:06 yup, and it turns out that some of them require some beer to understand :-) 20:54:11 np, we're interested in that very much 20:54:21 :)) haha 20:54:32 rakhmerov so maybe when we decide a time, openstack-dev list, then others can join 20:54:36 recalling today's discussion, definitely 20:54:56 yes, sure 20:54:59 cool 20:55:28 #AI Renat to organize a hangout meeting 20:55:47 #action Renat to organize a hangout meeting 20:55:53 one of those will work, ha 20:56:06 so i might skip a few of the agenda, for next time, not enough for time left 20:56:17 seeing that 4 minutes left :) 20:56:24 #topic open-discuss 20:56:27 #AI Gosha has to provide some text about Mistral for Josh 20:56:48 thx, that'd be suepr 20:56:59 *super 20:57:12 caitlin56 u around, 3 minutes, or maybe we can continue in #openstack-state-management 20:57:29 wanted to answer your question on the best practices i created 20:57:35 guys, I just wanna deliver the main message here: looks like we dont' have a service like this in the whole ecosystem. We need to carefully think about the target user group, project mission and main conceptual ideas 20:57:47 rakhmerov +1 20:57:50 Can start. The key thing that is missing is a definitionof what a "Flow" is. 20:58:16 https://wiki.openstack.org/wiki/TaskFlow#Flows ? 20:58:17 the further is more interesting ;) 20:58:29 Specifically, if you launch two tasks of the same pattern, what happens. Who is responsible for keeping the work separate? 20:58:32 yep, have seen that :) 20:59:14 caitlin56 so engines are what actually run the 'work' 20:59:38 lets continue in other channel i think 20:59:38 not a question for now. We need to define first what we want users (who exactly?) can do with this service 20:59:45 Do the engines name all resources that the tasks work with? If so, highlight that in the best practices. 20:59:50 harlowja: agree 20:59:57 k 20:59:59 #endmeeting