13:00:20 #startmeeting senlin 13:00:22 Meeting started Tue Jun 23 13:00:20 2015 UTC and is due to finish in 60 minutes. The chair is Qiming. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:25 The meeting name has been set to 'senlin' 13:00:34 hello 13:00:38 hi 13:00:58 hi 13:01:30 please add/edit agenda items here: https://wiki.openstack.org/wiki/Meetings/SenlinAgenda 13:01:36 hi 13:02:16 first of all, action from last meeting 13:02:52 I have checked with openstacksdk about their roadmap/plan for migrating from stackforge to openstack 13:03:13 ok 13:03:22 good news? 13:05:03 the answer is the same as last time I checked 13:05:03 they have been focusing on hardening the code at the moment 13:05:03 migrating to openstack namespace is not yet the top priority 13:05:04 it is on their their todo list 13:05:05 judge it by yourself, haiwei, :) 13:05:09 #topic test case coverage 13:05:58 so ... for any project to be considered mature enough, it has to have a stable design, no radical changes to the architecture is expected 13:06:03 it's on the todo list, so not bad I think 13:06:21 another criteria is to have test case coverage 13:06:37 that is one of our big problems as of today 13:06:51 if you check here: http://git.openstack.org/cgit/stackforge/senlin/tree/senlin/tests 13:07:06 hi qiming... sorry im late. on the heat call as well 13:07:20 we have api, engine test cases there 13:07:34 hi, jruano, glad you can attend both, ;) 13:08:00 agree with you, Qiming, and we also don't have integration test yet 13:08:05 we don't have any test cases for policies, profiles, drivers, actions 13:08:16 that would mean quite some work to do 13:08:26 what about the coverage of senlin currently, do you have a number of it Qiming 13:08:45 exactly, yanyanhu, funtional testing is also very important 13:09:05 haiwei, check tox.ini, there is a command you can run and get the report 13:09:18 ok 13:09:21 tox -e cover 13:17:31 my rough estimation is about 50% or so 13:17:31 in the client side, seems less 13:17:31 does openstack require a specific number for test coverage? 13:17:31 before we are getting our hands dirty, I'd like to propose a split of the cluster_action.py file, for example 13:17:31 it is too big, too complex 13:17:31 Hi Qiming, sorry I'm late 13:17:31 lkarm, not that I'm aware of 13:17:31 nice see you here, karolyn 13:17:31 good test case coverage is a strong proof of code maturity 13:17:31 writing test cases is fun, :) 13:17:31 ok, let's do it 13:17:32 so, please try navigate the source tree, and find some modules to work on 13:17:32 it also helps understand the function of senlin 13:17:32 definitely, haiwei 13:17:32 maybe we can also add this work to TODO.rst 13:17:32 please raise questions if you are not familiar with writing test cases 13:17:32 no problem 13:17:32 yes, give them a higher priority seems not a bad idea 13:19:02 no problem 13:19:09 besides the exception type design, and I think we may also need to consider where to catch and how to conver these exceptions 13:19:17 especially those ones from driver 13:19:31 exactly 13:19:38 any questions so far? 13:19:39 since I think most of them should not be exposed to enduser 13:20:05 yanyanhu, I believe haiwei is on the right track: catch them as internal errors, expose to users when necessary, with clear message translated 13:20:33 hmm, actually when I was working the patch of lb-policy, sometimes, I'm a little confused about how to catch them 13:21:06 if you have come up an idea, we can discuss it 13:21:28 or we can discuss the problems you met 13:21:38 yes, you are right. Just I'm thinking something more detailed, e.g. whether we should catch exception in create_lb or attach method in lb_policy module 13:22:03 like in this patch 13:22:05 https://review.openstack.org/#/c/188691/ 13:22:06 yanyanhu, I saw your patch, currently raise exception.Error is ok, I think, you can also raise exception.InternalError, if you are sure that is an internal error 13:22:27 in that case, I'd suggest we start with a better structure of the lb specific code 13:22:52 once the layer/structure is there, we will have a better idea how to catch/filter/translate exceptions 13:22:55 haiwei, yes, I think the type of exception that raised from driver should be finally changed 13:23:04 in the future, we will delete exception.Error and use exception.InternalError instead 13:23:17 Qiming, yes, this is what I'm thinking 13:23:20 haiwei, +1 13:23:45 yanyanhu, still reading your patch, will post comments tomorrow 13:24:00 ok, thanks 13:24:08 okay, let's move on 13:24:26 #topic talk proposal for Tokyo summit 13:24:54 the deadline is drawing near, we will have some company internal reviews before submission 13:25:05 again? 13:25:21 I hope someone from the team can get an opportunity to give the audience a deepdive 13:25:44 not just a design summit session, I mean a talk for the conference 13:26:02 we have propose one 13:26:06 that will be great 13:26:14 lkarm, karolyn, jruano, do you have travel plans for the summit? 13:26:23 i will be attending 13:26:29 I'm trying to get my team to send me but nothing official yet 13:26:38 so i am more than willing to help 13:27:03 okay, in any case, I will propose haiwei to be one of the presenters 13:27:08 we can have a session held by more than one person 13:27:14 haiwei is located in Tokyo 13:27:32 yes, I am 100% there I think :) 13:27:41 if, for any reasons, we cannot go there, there is still be someone showing up 13:28:11 right :) 13:28:14 you are sure coming, right? 13:28:18 Qiming 13:28:23 I'll start a draft of the talk proposal and send you all for review tomorrow 13:28:44 haiwei, nothing official yet 13:28:53 hopefully, I will be there, :) 13:29:06 I'm with Lisa, we are hoping, but nothing official yet 13:29:30 karolyn, let's try our best, :) 13:29:55 Tokyo is not far from Beijing, you can come I think, Qiming 13:30:15 just refreshed the agenda wiki, nothing was added besides these topics I have in mind 13:30:36 haiwei, sure, I will swim there 13:30:59 #topic open discussions 13:31:41 anything you want to talk about? 13:31:45 hi, Qiming, I'm thinking whether we should give a time schedule for each TODO item 13:31:50 about the presentation, you will mainly use the slides shown in the last summit? 13:32:06 agree 13:32:12 to make it easier to track their progress 13:32:30 okay, a schedule sounds good 13:32:50 maybe just a brief plan given by the owner 13:32:56 I've copied the milestones for Liberty cycle 13:33:25 yeah i think having a schedule is a good idea 13:33:31 we can assign todo items to each milestone: L2, L3, for example 13:33:41 yes, something like that 13:34:02 should we use blueprints for test cases? 13:34:16 I think it's a good idea 13:34:16 I think it's not bad 13:35:06 maybe one bp for each module 13:35:08 or bug reports? 13:35:31 it looks a little weird to have bps for test cases 13:35:55 how about we report each missing test case as a bug 13:36:00 not bug reports, each module may need many patches to it 13:36:02 then we track the "bugs" 13:36:04 +1 Qiming, i think so too... 13:36:19 hmm, if using bug report, I think the unit can be smaller, like lb policy, autoscaling policy 13:36:31 blueprints, to some extents, are for new features 13:36:44 yanyanhu, exactly like that 13:37:06 yeah i bug report makes sensu and agree with yanyanhu should be smaller units 13:37:18 *makes sense 13:37:34 #action everyone work hard to file "bugs" 13:38:00 a module a bug report? 13:38:25 yes, haiwei, that sounds a plan 13:38:50 if the module is too big, like the cluster_action module I just mentioned, we may need to split the module first 13:38:58 but to one module, you may need to submit many patches 13:39:11 or in your patches, you can add tag: #partial-bug: #123456 13:39:12 bug 123456 in xine-lib (Ubuntu) "podcast crashes amarok" [Undecided,Fix released] https://launchpad.net/bugs/123456 13:39:35 It is difficult to handle big modules 13:39:41 meetbot is smart 13:40:17 haiwei, if the module is too big, we need to split either the module or the test case 13:40:28 just like 'partially implement blueprint' 13:40:37 any module beyond 2000 lines would be a headache for maintenance 13:40:55 it will cause a lot of rebases when people are working on the same module 13:41:15 but if a patch is more than 100 lines, it's also difficult to review 13:41:41 for test cases, it won't be very difficult, haiwei, don't worry 13:42:09 ok, just like you said, we have a try 13:42:09 I think for the start point of test cases, it's difficult to avoid big patch... 13:42:43 let's give it a try and see if it works 13:42:46 ok 13:42:56 ok 13:43:06 plans are meant to be changed 13:43:17 anything else? 13:43:51 I will have a morning vocation again tomorrow :) 13:43:53 we can end the meeting a little bit early? 13:44:13 haiwei, package me, I want to go 13:44:13 yes, I guess so :) 13:44:22 oh, thomas said he will move heat meetings to wed to avoid conflict here 13:44:33 thank you all for your time 13:44:36 great 13:44:55 let's move to #senlin 13:44:55 yes, jruano, I also saw that reschedule 13:45:05 #endmeeting