20:01:16 #startmeeting openstack-state-management 20:01:17 Meeting started Thu Feb 6 20:01:16 2014 UTC and is due to finish in 60 minutes. The chair is harlowja. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:21 The meeting name has been set to 'openstack_state_management' 20:01:34 #link https://wiki.openstack.org/wiki/Meetings/StateManagement#Agenda_for_next_meeting 20:01:45 anyone around today (if not, short meeting, ha) 20:02:38 hi there 20:02:42 iv_m howdy 20:03:09 * harlowja waits a few minutes for others 20:04:30 ok, guess might be short meeting 20:04:30 haha 20:04:41 #topic last-action-items 20:04:44 #link http://eavesdrop.openstack.org/meetings/state_management/2014/state_management.2014-01-30-20.00.html 20:05:03 so oslo transition will happen this weekend, or early next week 20:05:13 it will mean reviews will have to be reposted 20:05:16 scheduled for 20:00 UTC tomorrow 20:05:27 thx dhellmann 20:06:22 hopefully thats not to much of a pain, but just something to be aware of (likely involving adding a new git remote...) 20:07:10 iv_m any progress on the writeup for reversion/retry strategies? 20:07:27 not yet, sorry 20:07:35 np 20:08:14 k, not many other action items 20:08:20 #topic taskflow 0.1.3 20:08:35 so the reason for this is a unicode problem in 0.1.2 20:08:43 hey guys 20:08:47 hi changbl 20:09:03 #link https://etherpad.openstack.org/p/TaskFlow-0.1.3 20:09:11 i think we are ok to release that 20:09:20 ya 20:09:25 looks like we are ready 20:09:27 great 20:09:28 k, i'll do that shortly 20:09:36 after meeting /lunch 20:09:50 then i think 2.0 we can merge in after move to oslo 20:09:54 0.2 20:09:57 not 2.0, lol 20:10:00 2.0 :) 20:10:04 oops 20:10:38 if we adopt the firefox/chrome versioning scheme we should be at 10.0 already ,lol 20:11:01 i was also thinking about a 0.1.3 tag and a stable/0.1 branch? 20:11:08 just incase this happens again :-P 20:11:37 since after 0.2 code starts coming in, not gonna be easy to do small releases of 0.1 20:11:40 *if we need to 20:11:46 i think we should choose lazy approach and branch it when that happens again, if ever 20:11:56 ok 20:12:05 i'm fine with that to 20:12:41 hi 20:12:53 also, we might want to enforce some policy for bugfixes -- to know for sure what needs to be backported for stable branch when/if we make one 20:12:54 k, after https://review.openstack.org/#/c/71362/ goes into the incubator, we can use that instead of our mini-version 20:13:07 iv_m sure, what where u thinking? 20:13:09 hi akarpinska1 20:13:54 i was thinking of smth like '-1 all real bugfixes unless there is launchpad bug and it is reffered from commit message' 20:13:57 i was hoping stable would just be for tiny stuff (like some unicode stuff we missed somehow) 20:14:09 iv_m thats fair 20:14:33 sounds good to me 20:15:35 k, so next release 20:15:38 #topic 0.2 release 20:15:58 so this one i think we all know whats going into it, nothing unexpected afaik 20:16:08 just lets merge things after move to oslo 20:16:35 i'm also thinking we should put a release notes on ML 20:16:42 *some type of release notes 20:17:30 sure 20:17:39 iv_m maybe for each release we should follow the pattern @ https://etherpad.openstack.org/p/TaskFlow-0.1.3 20:17:42 that one seems nice 20:17:57 make a https://etherpad.openstack.org/p/TaskFlow-0.2.0 for example 20:18:07 with whats new, what changed ... 20:18:21 when to have 0.2? 20:18:21 sounds good 20:18:28 changbl ah that question :) 20:18:46 #action harlowja start https://etherpad.openstack.org/p/TaskFlow-0.2.0 20:19:00 changbl i think the goal is next week or the week after 20:19:08 ok, that is quick 20:19:13 very soon 20:19:20 well we can change that :-P 20:19:34 0.1.3 wasn't supposed to exist, lol (more of a patch release) 20:20:05 changbl do u think we should wait more? 20:20:19 i can see a nice to have being more examples for 0.2.0 20:20:28 that would help show to people the new features 20:20:39 * harlowja always likes more examples :-P 20:22:00 harlowja, depends on what to achieve in 0.2:) 20:22:19 well i think its composed of the following 20:22:31 * jobboard reference impl (ready for people to start trying it out) 20:22:45 * remote workers 20:22:56 * retry controlling that akarpinska1 is working on 20:23:21 + any other bug fixes 20:23:31 your zookeeper backend will be in 0.1.3 (since it merged) 20:24:35 i think probably more time is needed to nail down all above TODOs. 20:25:01 agreed, i think changbl its mostly review time though and documentation and examples 20:25:25 hopefully those don't take to long 20:25:33 review take time... 20:25:54 ya, np, no rush there :) 20:26:05 if it takes more time to review, thats fine 20:27:04 we can revisit release date to, just seems like ~2weeks should be able to review, document, make examples (and all that) 20:27:10 if not, we can change to >2weeks 20:28:03 sound fine? 20:28:05 harlowja, yes 20:28:08 k 20:28:19 #topic cinder-integration-process 20:28:31 so this one is connected to http://lists.openstack.org/pipermail/openstack-dev/2014-February/026184.html 20:28:47 i just wanted to see how we can improve there (along with others and the cinder work) 20:29:06 John G mentioned persistence is wanted right? 20:29:12 changbl ya 20:29:23 we'd get persistence ready for cinder 20:29:39 seems they really like persistence from taskflow 20:29:41 changbl i am thinking so, i need to see if i can get the nttdata folks to jump in 20:30:09 akarpinska1 do u see any major issues doing this, it will likely change a little bit how they run there workflows (its split across 3 components still) 20:30:33 i imagine the simplest approach is to add persistence in the 3 places (is it the same logbook, not sure) 20:30:50 which 3 places? 20:30:55 I started to move common parts to separate tasks 20:30:58 changbl also i think part of the improvement that was desired, is to make sure that all the refactoring that was happening was well understood 20:31:11 harlowja, yes 20:31:14 changbl api node, scheduler node, volume node 20:31:18 when I finish with retries I'll finish it 20:31:43 akarpinska1 lets also see if we can get the ntt folks to jump in, they seem willing and able 20:32:15 now we can give some recommendations about the coding style for flows, but the most important part is a persistence, I think 20:32:16 some of these ideas i wrote up and have updated @ https://etherpad.openstack.org/p/cinder-taskflow-persistence 20:32:28 akarpinska1 agreed, even the basic persistence model they would benefit from 20:32:39 and that i think would then unblock these other reviews (once they see what it means) 20:33:55 i'll try to catch the nttdata folks, see if they want to take ownership of this (or i can work with them to make it happen), just want to make sure they are visible and communicating the changes they are doing 20:34:12 and the overall plan (which i think was confusing some of the cinder folks, thus the above ML email) 20:34:17 harlowja, rohit and another folk from nttdata? 20:34:54 changbl i think abhishek (and a couple other folks) 20:35:04 harlowja, ok 20:35:20 rohit (who used to be doing some orchestration work) i think went to another company (unless its a different rohit u are thinking) 20:35:37 oh, we mean the same rohit:) 20:35:41 k 20:36:20 #action harlowja engage cinder folks, nttdata folks to get some movement on persistence writeups,ideas... 20:36:53 the other thing that cinder wants to gain from taskflow is there state consistency issues 20:37:00 *is to resolve there state-consistency issues 20:37:37 i think there will be a feb cinder mid-cycle meetup where everyone will try to figure out what to do here, i'll try to be there if its in the bay area 20:38:23 not so easy to nail down what it means, is it resource consistency problems, race conditions on manipulating resources, other.... 20:38:49 jgriffith has the location for this been finalized yet (so that i can try to go :)) 20:38:57 *this == cinder mid-cycle meetup 20:39:34 anyways i'll followup on that, anyone that wants to attend to help please join ;) 20:39:45 akarpinska1 ^^ ;) 20:40:17 k 20:40:54 #action harlowja determine when is the cinder meetup so that taskflow people can jump on phone, in person... 20:41:01 #topic new use-cases 20:41:35 any new things that people are thinking about that we should have (that we don't) 20:41:45 if not i guess we can just jump into open-discuss 20:42:05 5 20:42:10 4 20:42:17 sold:) 20:42:17 3 20:42:21 http://lists.openstack.org/pipermail/openstack-dev/2014-February/026403.html 20:42:22 we have winner 20:42:42 just kidding:) 20:42:46 go on 20:42:50 anything relevant in sdakes message there? 20:42:55 ccrouch interesting 20:43:04 i.e. integration with Heat 20:43:13 * harlowja reading 20:44:03 its a *big* thread, but thats the part that seemed most relevant to taskflow 20:45:08 hmmm, so partially that seems to be suggesting a workflow service right, which to me brings into the picture what mistral is 20:45:22 although there has been much discussion about heat using taskflow 20:45:44 *which changes alot of how heat runs (for better or worse) 20:46:19 although the mistral dsl seems to be turning into a 'full-fledged programming language' 20:46:59 (2:45:23 PM) harlowja: although there has been much discussion about heat using taskflow 20:46:59 i will go and try and find that 20:47:02 ccrouch i've been working with the mistral folks on using taskflow, there initial prototype still isn't using taskflow but i think they want to 20:47:21 ccrouch http://icehousedesignsummit.sched.org/event/ced7d22ac4c037f102b3cf3ade553104#.UvP00fY71ro 20:47:26 i think there was a etherpad somewhere 20:47:53 ccrouch https://etherpad.openstack.org/p/icehouse-summit-heat-workflow 20:48:19 the problem with changing heat was the coroutine style in heat makes it really hard to alter/change it to something else (something say that uses remote workers) 20:48:29 i'm all for bringing the question up again 20:49:51 from the HK summit i think the conclusion was that heat needed to do some refactoring before changing how it ran was even possible 20:50:01 *which was also desired to fix there scaling bottleneck 20:50:22 and they wanted taskflow to have a remote-worker model (now @ https://review.openstack.org/#/c/63155/) 20:50:35 harlowja: ok, i can trying poking sdake about where this is at, if you would be receptive on your side to pushing the "workflow" ball down the field with heat 20:50:54 * harlowja unsure what that exactly means :) 20:51:08 the pushing the workflow ball down the field to heat :) 20:51:36 that folks won;t say "too busy doing cinder integration, sorry cant talk" :-) 20:51:48 oh, sure, i'm always up for talking :) 20:52:02 *unless i'm in mad crazy programming mode, lol 20:52:24 ccrouch sounds good, lets start this conversation up with sdake (and any others) 20:52:30 and see what happens 20:52:33 ok i'll see where sdake is at 20:52:34 +1 20:52:40 cool, thx much 20:53:51 alright final topic 20:53:54 #topic open-discuss 20:54:09 sooo the only thing that i have is to get more input on https://etherpad.openstack.org/p/taskflow-atlanta-speaker-ideas :) 20:54:15 so that we can start filing little speaker abstracts 20:54:27 'Hurry, the deadline to submit is February 14, 2014. ' 20:54:54 so start adding in anything that might be cool to show 20:54:56 or talk about 20:54:57 or... 20:56:07 anyways, that all i got 20:57:08 anybody else, if not we can end :-P 20:57:12 5 20:57:22 4 20:57:29 3.1 20:57:35 2 20:57:39 0.5 20:57:42 0.0 20:57:43 boom 20:57:48 thanks for coming again folks 20:57:59 more excitement always found in #openstack-state-management 20:58:02 #endmeeting