13:00:43 #startmeeting senlin 13:00:45 Meeting started Tue Feb 16 13:00:43 2016 UTC and is due to finish in 60 minutes. The chair is Qiming. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:48 The meeting name has been set to 'senlin' 13:00:54 hello 13:00:59 hi 13:00:59 hi 13:01:03 hi 13:01:04 hi 13:01:29 hi, pls check meeting agenda and see if you have things to add: https://wiki.openstack.org/wiki/Meetings/SenlinAgenda 13:01:58 welcome back, guys, hope you all have enjoyed a pleasant vacation, :) 13:02:17 thanks, you too :) 13:02:36 #topic Mitaka work items 13:02:45 #link https://etherpad.openstack.org/p/senlin-mitaka-workitems 13:02:46 yes, you four 13:03:11 API revision 13:03:36 don't think we have progress on it, or we can make them into M release 13:04:13 so ... maybe we should move them back to the TODO.rst 13:04:34 Heat resource type 13:04:36 ethan? 13:04:42 in progress 13:04:49 codes are submitted 13:05:01 waiting review 13:05:12 I have some problems regarding the logics you used for testing action completion 13:05:37 Can't access to gerrit now... 13:05:38 there might be some cleaner ways to do that 13:05:49 I will check that later. 13:05:49 good luck, :) 13:06:14 okay 13:06:20 You mean move them to senlin plugin? 13:06:39 maybe you can paste the links to the related patches into the etherpad 13:06:52 yes, it could be a routine on senlin plugin 13:07:02 check something (action) has completed 13:07:03 Will do after my network back to normal... 13:07:11 great 13:07:36 also, some checkings are better offloaded to some threads 13:07:37 I reply you, it's not that easy... I reply you in that patch, I will have a look if I can move them to senlin plugin. 13:08:11 I'm not quite sure I have a good understanding on doing things asynchronously in Heat 13:08:28 There might be some ways ... need some homework on that 13:08:55 I think some of them are asynchronously in my codes. 13:09:06 great 13:09:06 Can you be more specific? 13:09:25 have to look at the code to be more specific 13:09:31 :) 13:09:35 ok :) 13:09:49 testing 13:10:01 cannot recall why we have oslo.messaging scalability there 13:10:32 someone has got a higher memory capacity? 13:10:33 also have no idea 13:10:47 okay, two overflowed 13:10:57 Not sure about that... 13:11:02 3 13:11:13 neither 13:11:19 seems xujun mentioned about scalability test 13:11:20 I could be from Junwei Liu's talk during our meetup 13:11:20 oh, maybe about a discussion in midcycle meeting 13:11:24 yep 13:11:39 but not sure what we can do on this 13:11:45 right ... 13:11:56 about API service stop responding request in some cases 13:12:05 maybe need to check with xujun and see if there are resources from their side working on this 13:12:25 good idea 13:12:30 yanyanhu, you mean senlin API? 13:12:36 yes, I think this is job is about best practise 13:12:41 if anything need more testing, Bran_W can help too 13:12:43 Qiming, yes 13:12:44 Seems you told him to increase workers to see if that can be solved? 13:12:59 e.g. when creating a cluster consists of 500 nodes 13:13:05 lixinhui_, please do 13:13:17 okay, Qming 13:13:23 we need to know the limits 13:13:44 with both cloud backends, the usual one, and the faked one 13:13:48 elynn, yes, increasing worker is most direct solution 13:14:00 but still need more evaluation 13:14:08 Bran_w has some data already, will send all the results for review and suggestion. 13:14:20 yanyanhu just added some more items? 13:14:26 COOOL 13:14:29 Qiming, yes. about test 13:14:48 I'm now working on completing functional test for cluster/node 13:14:59 maybe those are the samething bran has already started? 13:15:04 to add test cases for cluster add/del node, cluster update 13:15:19 oh, you mean stress test? 13:15:21 right, those are yours 13:15:27 yes, stress tests 13:15:37 Yes, Bran_w focus on Stress tests 13:15:47 actually my plan is not just doing stress test :) 13:16:08 I'm putting xinhui's name under that item 13:16:13 I'm thinking whether we need to add a gate job for it :) 13:16:31 gate job for stress test? 13:16:38 to test the scalability for some important changes 13:16:42 yes 13:16:56 I remember there's a project in community can help us do stress test? 13:16:58 emm ... don't think that's a good idea, :) 13:17:00 rally? 13:17:06 I have got clear idea how to do this 13:17:23 okay, Qiming, yanyahu, let me know if anywhere need labor work 13:17:26 yea, so we need more discussion here:) 13:17:44 :) 13:17:45 great if you have already got a good idea 13:17:45 xinhui, will talk more with you about this issue 13:17:51 lets think it together 13:18:05 my concern is resources at gate are very precious ones 13:18:11 okay :) 13:18:19 Qiming, yes, understand 13:18:46 so maybe a manually trigger one. Or just a test tool in senlin source tree 13:19:10 also, need a clear design to ensure that we are stressing the correct target 13:19:22 absolutely 13:19:35 stress testing a cluster of 1000 m1.huge nova servers sounds crazy 13:19:41 haha 13:19:45 :) 13:19:46 sure 13:19:53 it is not gonna yielding any useful insights 13:20:26 how about we bring bran into this 13:20:39 Yes, Qiming 13:20:41 please 13:20:55 great 13:21:05 who is bran? 13:21:08 I believe VMware has a lot interests in seeing the scalability report 13:21:19 cool 13:21:32 VMware guy? 13:21:39 bran is lixinhui_ 's assistant, you can think of him that way 13:21:45 Yes, Haiwei 13:21:53 niubility 13:21:56 I believe built stress test tool and test results are very useful for user who want to manage large scale cluster using Senlin 13:22:01 technical assistant 13:22:07 s/built/builtin 13:22:13 absolutely 13:22:16 just trying to get more resource to help senlin 13:22:17 haha Qiming:) 13:22:25 although maybe it's just prototype or an example 13:22:34 and bring senlin into VMware market engagement 13:23:06 move on? 13:23:15 ok 13:23:18 ok 13:23:22 it's better so 13:23:24 oh, functional test for failure scenarios 13:23:37 I think that sounds a tempest job 13:23:41 not sure how to do this 13:24:03 yea, maybe not use existing functional test 13:24:04 currently, we are only testing the 'correct' execution paths 13:24:43 need to test all weird inputs and make sure api and engine always behave as designed 13:25:08 that will be a huge effort 13:25:18 yes, and I think we need a design for 'fault injection' 13:25:52 actually, the functional test for lock breaker also faces similar problem 13:25:54 em ... that would be cool 13:26:02 yep :) 13:26:20 but before that, I really hope we have a good idea about some typical cases 13:26:34 agree 13:26:53 say, creating a cluster of 100 nodes, but only first 80 were successful 13:27:19 scaling-in by 10 nodes, but we only managed to remove 3 nodes ... 13:27:35 yep 13:28:02 these are more realistic challenges 13:28:27 very import for industry level quality 13:28:31 maybe add a TODO item for this? 13:28:45 good idea 13:28:46 yes, I think so 13:29:05 yes, that would be good! 13:29:08 hopefully, we can get something done before M release 13:29:29 maybe not only Senlin need this kind of tool/design :) 13:29:29 is there sad path testing already in other projects? 13:29:34 document the rest as 'known issues', haha 13:29:35 like HEAT 13:30:08 okay 13:30:12 don't know if any project is doing defensive programming 13:30:34 off topic now 13:30:42 :) 13:30:46 okay 13:31:00 #action Qiming to add TODO item about testing typical failure scenarios 13:31:02 Heat has a internal resource, it can fake it's status. you can set to failed to success. 13:31:36 good idea 13:31:46 in that way heat can test failure cases. 13:31:48 in senlin we can have some fake actions 13:31:57 it may and may not succeed 13:32:13 do we need to expose API/rpc interface for it? 13:32:21 oh, no 13:32:34 it is a testing support 13:32:47 so we need to consider how to trigger it 13:32:59 yep 13:33:23 let's think of it offline 13:33:31 ok 13:33:49 btw, should we create a senlin-specs project? 13:34:06 not that necessary I think 13:34:20 in this cycle 13:34:34 or we can have a specs dir in tree 13:34:37 maybe a folder in senlin repo is enough? 13:34:59 doc/specs ? 13:35:22 there we can discuss designs like this asynchronously 13:35:23 yes, should have that kind of thing 13:35:36 sounds good 13:35:47 though we didn't use it at all 13:36:13 I just wrote spec for nova 13:36:26 and think we will need that when allow others to extend senlin 13:36:41 according to my limited experience 13:36:45 let's practice a small scale specs discussion 13:36:55 honestly that is the formal way 13:36:59 and migrate to a dedicated project when we feel necessary 13:37:35 sound great start point 13:37:35 so you prefer a senlin-specs project ? 13:37:53 not really a project at this time 13:38:02 okay 13:38:02 but at least something others can follow 13:38:17 spec dir would be good and doc seems not enough 13:38:57 if we discuss things in tree 13:39:14 we can always easily migrate the outputs into design docs 13:39:30 anyway 13:39:38 yes 13:39:38 moving on 13:39:45 you mean using mailing? 13:39:50 progress on health mgmt? 13:39:51 ok, go on 13:40:17 the senlinclient change is blocked by sdk change 13:40:26 yep, sadly, that's true 13:40:34 but I am still working on senlin and sdk side 13:40:50 yes 13:41:03 hope to commit them into firstly then extend client once sdk problem resolved 13:41:20 for the semi-automation part 13:41:40 I will commit into some patch firstly for comments in this week 13:41:40 okay, hopefully everything will gets sorted out by the end of this week at sdk side 13:41:51 cool 13:41:54 and will add functional test for node check/recover 13:42:01 documentation side 13:42:06 and for cluster as well after xinhui's job is done 13:42:11 did a little revision to the senlin wiki 13:42:28 need to work more on that 13:42:37 okay, yanyanhu and Qming 13:42:49 Yes, Qiming 13:42:49 container support 13:43:09 emm ... I have tried something 'last year' 13:43:32 I also did something in the last few days 13:43:33 I think I'm stuck by a scheduling problem 13:43:39 cool 13:43:43 you mean last days on horse year 13:44:04 when you want to create a container, you need to specify on which VM/host to start it 13:44:12 yes 13:44:24 that becomes a huge scheduling problem 13:44:42 though we can do some very naive 'placement' today 13:44:56 that's because no underlayer service helping to do a default scheduling decision 13:45:02 this could be a spec for discussion 13:45:18 yanyanhu, exactly 13:45:32 k8s/mesos/swarm can do schedule task? 13:45:34 I think if you want to create a container cluster by Senlin, you will have to do something similar to k8s and swarm 13:45:36 can't 13:45:43 I know Haiwei has proposed a topic for the coming summit on this 13:45:58 cool, haiwei 13:45:58 elynn, they can 13:46:25 an idea from Qiming 13:46:34 :) 13:46:39 and also some magnum guys 13:46:39 we need to help him getting something solid before the summit, not matter the talk is accepted or not 13:47:05 #action Haiwei to start a spec discussion about container support 13:47:14 haiwei, okay? 13:47:23 ok 13:47:34 Receiver functional test, done? 13:47:42 yep 13:47:48 we can remove this item 13:48:02 omg, finally find someething to remove 13:48:09 haha 13:48:11 :) 13:48:16 :D 13:48:18 NODE_CREATE/DELETE 13:48:26 no progress I know of 13:48:36 another diffult work 13:48:36 engine status list 13:48:39 done? 13:48:45 seems so. 13:48:48 still minor issue there 13:49:05 function is ok now 13:49:07 yes, still have a but openning. 13:49:15 don't feel shy to file a bug 13:49:27 yes, elynn has done that 13:49:45 okay, last item 13:49:45 sdk change 13:49:47 It's already filed :) I will look into it tomorrow :) 13:49:58 elynn, no hurry :) 13:50:05 it was a series of disruptive change 13:50:21 almost all resources have their property name reinvented ... 13:50:38 so we have to stick to 0.7.4 for senlin testing/functioning 13:50:45 em, need rework senlin driver modules 13:51:02 then see if we can get a chance to catch up with 0.8.0 if that can be released next week 13:51:10 time window is very short 13:51:16 Seems sdk is always changing... Hope it can be stable soon. 13:51:16 http://releases.openstack.org/mitaka/schedule.html#m-final-lib 13:51:33 will work on it if 0.8.0 can be released soon 13:51:33 not this kind of changes ... sigh 13:51:41 great 13:51:51 may need one or two days, mainly for test 13:51:53 that is something just want to raise awareness in the team 13:52:05 don't try clone latest sdk code for senlin development 13:52:54 got it 13:52:56 #topic sdk issues 13:53:00 done 13:53:14 #topic DB concurrency problem 13:53:24 it happened again? 13:53:26 I think chuck has reported the db concurrency problem again 13:53:32 sadly, yes 13:53:33 ... 13:53:40 Is there any bug open for it? 13:54:27 this time, I'm gonna monkey patch the oslo.db 13:54:42 just like what mistral has todo 13:55:09 from engine level? 13:55:12 s/todo/to do 13:55:12 will propose a fix tomorrow 13:55:12 or sesssion level 13:55:26 engine level 13:55:33 ok 13:55:53 when doing get_engine, we set isolation_level to READ_COMMITTED 13:56:20 ok 13:56:22 don't see other way out 13:56:22 okay, 4 minutes for open 13:56:24 #topic open discussion 13:56:56 no other topic from me :) 13:57:13 no from me 13:57:16 Nope from me :) 13:57:41 what do you think of k8s and docker swarm 13:57:50 ok, no from me 13:58:09 haiwei, you mean use them as backend service to manage container? 13:58:15 haiwei, I am all ears to any entry level talks on k8s or docker swarm 13:58:24 I mean replace them :) 13:58:31 :) 13:58:44 sounds impossible 13:58:45 haiwei, don't think that should be the goal 13:58:47 wow, haven't thought that before :) 13:59:04 the goal should be 'openstack native way to manage container clusters' 13:59:09 just got some experience about Mesos and glad to share it with you guys 13:59:15 ok, I will think that more 13:59:22 or 'make containers first class citizens on openstack' 13:59:23 will join the discussion about container cluster 13:59:39 thanks 13:59:43 haiwei, be sure to start a spec or two on that 13:59:45 interesting, yanyanhu 13:59:50 time is up 13:59:56 no problem, Qiming 13:59:58 lixinhui_, yes, lets talk this offline 14:00:01 thanks for joining everyone 14:00:01 good night 14:00:04 #endmeeting