13:00:53 #startmeeting senlin 13:00:54 Meeting started Tue Dec 15 13:00:53 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:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:57 The meeting name has been set to 'senlin' 13:01:01 evening 13:01:09 \o 13:01:22 hi, Liuqing 13:01:38 o/ 13:01:43 hi 13:01:59 #link https://wiki.openstack.org/wiki/Meetings/SenlinAgenda 13:02:12 please check the agenda and see if you want to add something 13:02:18 haiwei is logging, he met some network issues 13:02:32 yes, saw that, yanyanhu 13:02:53 let's get started 13:03:01 #topic mitaka work items 13:03:09 #link https://etherpad.openstack.org/p/senlin-mitaka-workitems 13:03:22 heat resource type support 13:03:31 Hi 13:03:43 I'm working on update for cluster 13:03:56 need help? 13:04:07 but I notice that there are many adjustment when doing update 13:04:15 Yes, have some questions 13:04:26 https://github.com/openstack/python-senlinclient/blob/master/senlinclient/v1/shell.py#L774 13:04:37 Do we need to support them all? 13:05:00 think from heat's perspective 13:05:11 If so, I might need to add more properties... 13:05:13 we won't be able to support all IMO 13:05:21 because heat is about nouns, not verbs 13:05:22 like update_policy or something... 13:05:42 the only way to make change is through the single command 'stack-update' 13:05:56 So for now, it's easy to support this adjustment type https://github.com/openstack/python-senlinclient/blob/master/senlinclient/v1/shell.py#L768 13:06:37 the resize operation is too flexible for heat to invoke 13:06:51 I'm suggesting that we think from heat's perspective 13:07:06 Qiming: Yes, I think so... 13:07:14 what Heat sees is a cluster resource with 'desired_capacity', 'min_size', max_size' etc 13:07:29 those are properties you can change through heat 13:07:53 change <=> update 13:07:57 So we need to have an agreement here, that we are not support to resize cluster by percentage for now. 13:08:00 yes, just as Qiming said, we actually don't need to support anyone of them for cluster update 13:08:27 there is no 'resize' operation from heat 13:08:32 yes 13:08:47 so we just need to pick one for backend implmentation 13:08:55 OK I got your point, for now I will only support to update desired_capacity', 'min_size', max_size' etc 13:09:01 right 13:09:19 other questions? 13:09:30 ok, then my codes for that will be ready soon. 13:09:38 cool 13:09:39 Have you review exists codes? 13:09:48 yes, they look fine to me 13:09:53 They are ready for review. 13:10:03 cool 13:10:05 I'm holding my +2 13:10:25 good, let's wait a while for other reviewers. 13:10:28 will continue to help review to make the code satisfactory to all reviewers 13:10:35 moving on 13:10:41 #topic client test 13:11:11 patch #251798 is merged 13:11:12 Qiming: https://review.openstack.org/#/c/251798/ - Add test case for v1/shell.py part2 (MERGED) 13:11:31 I'm not working on that recently 13:12:00 haiwei is offline again 13:12:05 let's move on 13:12:12 #topic API modification 13:12:31 I think we are almost done with it 13:12:53 I saw related workitem has been removed from TODO 13:12:59 yes 13:13:19 need a release note for this 13:13:25 yes 13:13:37 will remove it from etherpad after adding a release note 13:13:47 #topic health policy 13:14:08 xinhui and I had a discussion last weekend 13:14:27 cool 13:14:36 Any conclusion? 13:14:46 I think we have got a rough idea for implementing this, xinhui has already started playing with some polling code 13:15:15 well, we need some design docs for this, at least a blueprint for guys to review 13:15:23 okay 13:15:33 Qiming, I will draft one 13:15:51 okay, it's yours now, lixinhui 13:15:53 for you and everyone's review 13:16:09 let's wait for something to review 13:16:19 #topic profile support for update 13:16:41 this is a huge topic, will stay there for a long time I guess 13:16:56 besides nova server profile, we also need to consider heat stack profile 13:17:12 yes 13:17:17 yanyanhu, anything new from you? 13:17:26 sorry just didn\t spend so much time on this work last week 13:17:29 I think heat stack profile might be easy to update by calling stack-update 13:17:41 yep 13:17:43 trapped by mesos works... 13:17:51 will resume the progress this week 13:17:56 cool 13:18:00 #topic receiver 13:18:12 last week we have db layer and engine layer merged 13:18:18 and I will start thinking about update of heat stack profile type 13:18:25 will continue to finish the engine layer 13:18:50 yea, I saw engine and db realted support have been added 13:18:56 when creating a receiver of webhook, we will do something simpler 13:19:15 previously, we over-designed the authentication support 13:19:32 I'm thinking of simplifying it 13:19:40 yes, saw your comment in whiteboard 13:19:42 will propose something for review this week 13:19:45 I think I agree with it 13:20:10 thanks 13:20:10 quick question, so refactoring of Webhook class will come later? 13:20:27 there won't be a refactor of webhook class 13:20:27 especially about the creation 13:20:37 I'm working on it 13:21:03 Hi 13:21:05 the credential generation and url creation process is too/unnecessarily complicated 13:21:11 just saw a simple definition here https://review.openstack.org/#/c/257046/3/senlin/engine/receiver.py 13:21:12 hi xuhaiwei 13:21:14 hi xuhaiwei 13:21:15 hi 13:21:15 finally, xuhaiwei, :) 13:21:26 hi haiwei 13:21:46 I come from my phone 13:22:11 i'm thinking of an alarm_url of format: http://ip:port/v1/webhooks/ haha anyway.. 13:22:19 I guess we still need a function like 'generate_channel' for each type of receiver? 13:22:37 each receiver type will override that method to create a channel 13:22:37 I'm ok with that 13:22:41 yes 13:22:46 this is what I mean 13:23:04 moving on 13:23:18 #topic engine improvement 13:23:40 funtional test for lock breaker? 13:23:46 I found it's hard to simulate lock breaker in functional tests 13:23:52 maybe I have missed a lot, about the web hook creation, I agree that we should improve the url creation 13:24:21 we need to kill senlin-engine during functional tests, but that might affect other tests. 13:24:26 xuhaiwei, you can (i.e. have to) catch up later, :) 13:24:31 elynn, yes, the most difficult part is how to avoid influencing other test cases that run concurrently :) 13:25:15 Unless I can operated db_api directly to create a fake dead action, but it's not doable in functional tests. 13:25:17 maybe we need a different gate job? 13:25:20 about the engine-lock breaker, can we test it by hand, maybe not by source code? 13:25:37 anyway to enforce functional test cases run sequently? 13:25:55 yanyanhu, I have no idea 13:25:56 xuhaiwei: Yes, we can tests it by hand, I write the reproduce steps in the bug report 13:26:09 Qiming, that is possible.Or we just split them in post_test_hook? 13:26:19 agree with xuhaiwei , now could we reproduce the lock breaker? 13:26:43 looks like we need a separate gate job for this 13:26:50 but that still needs individual tox test entry definition 13:26:57 yes 13:27:15 please keep digging 13:27:28 Liuqing, we can produce it by 'kill -1 $PID_ENGINE' 13:27:29 unit test for parser is done 13:27:48 ok, so the worst situation is to create a new gate job for this? 13:27:55 service will be restarted and new engine will be created 13:28:03 elynn, yes, I guess so 13:28:06 Qiming: Yes 13:28:10 but maybe we can avoid it 13:28:21 unit test for v1/shell.py is alomost, I will submit part3 tomorrow 13:28:32 thanks, xuhaiwei 13:28:36 elynn, lets make some further discussion later 13:28:38 yanyanhu: let me dig more deeper. 13:28:46 xuhaiwei, then we will need to cleanse the senlinclient code 13:29:09 we are removing the models and client code from senlinclient 13:29:13 by writ ing test case, I fixed some bugs , so it took a little time 13:29:18 yes, Qiming 13:29:47 #topic functional test broken 13:29:54 you mean we should try to put them all in SDK? 13:30:02 we are still trapped by the db concurrency problem 13:30:09 will keep digging into that 13:30:36 first thing is to remove the MutableList data type, it is not concurrency friendly anyway, and see if that solves the problem 13:31:08 the last resort woud be some per-session isolation level customization, which will make the code veeeeeeeeeeeeery ugly 13:31:41 Qiming, I think the latest patch has fixed this issue? 13:31:54 yanyanhu, not 100% sure 13:32:05 still need to watch it 13:32:12 ok, will also help to do some tests locally 13:32:26 #topic High priority bugs 13:32:35 https://review.openstack.org/#/c/256949/ 13:32:40 the first one is what we have been talking about 13:33:38 yanyanhu, 'check experimental' still fails with that patch, though in different ways 13:33:49 need to look into the detailed logs 13:34:03 Qiming, ok, will dig it 13:34:19 bug #1486381 seems not completely solved yet, need to watch it 13:34:19 bug 1486381 in senlin "node-deadlocked-by-action" [Undecided,New] https://launchpad.net/bugs/1486381 - Assigned to Yanyan Hu (yanyanhu) 13:34:30 bug #1509145 is solved 13:34:30 bug 1509145 in senlin "node status should update to 'ERROR' when fail to create nova instance " [Undecided,Fix released] https://launchpad.net/bugs/1509145 - Assigned to lvdongbing (dbcocle) 13:34:59 yes, I remeber this bug 13:35:17 will check whether it is still there after applying elynn's patch about lock breaker 13:35:21 bug #1495449 is the same? 13:35:22 bug 1495449 in senlin "cluster action dependency list can't be updated correctly" [Undecided,In progress] https://launchpad.net/bugs/1495449 - Assigned to Yanyan Hu (yanyanhu) 13:35:42 Qiming, this is the bug about concurrency issue in DB 13:36:00 I reopened it about two weeks ago 13:36:15 okay, we still need to solve 1486381 right? 13:36:21 I think we need more tests and verification before closing it again 13:36:36 hmm, not sure, but I guess so 13:36:45 I hope elynn's patch have resolved it 13:36:57 but need confirmation 13:37:00 okay, please help verify 13:37:04 ok 13:37:11 yanyanhu, If not, I will work on it... 13:37:17 elynn, thanks :) 13:37:32 I have spent some time on clearing the backlog of bug reports 13:37:37 #action recheck assigned bugs 13:37:50 now it is almost clean 13:38:08 good 13:38:23 cool 13:38:24 with recent changes at gate, we will have bugs automatically closed 13:38:58 Haven't spent time on the blueprint backlog 13:39:44 okay, feel free to comment 13:40:07 I assigned a new BP about cross az/region deletion policy 13:40:07 and ... I'm moving on, :) got quite some topics to cover today 13:40:20 #topic mid-cycle meetup 13:40:24 thanks xuhaiwei 13:40:32 I like this topic 13:40:40 mid-cycle meetup 13:40:54 should we have it in Beijing? 13:40:58 yes, would like to hear what you think 13:40:59 the key is where is the meeting site :) 13:41:20 I want to breath some Beijing's air 13:41:26 :P 13:41:31 brave man 13:41:35 xuhaiwei, ... 13:41:37 you're brave 13:41:40 okay, we can host you 13:41:57 if you need some masks, I will take for you 13:42:23 wow, that will be great :) 13:42:34 :) 13:42:41 do we actually need one? if it is, how long will last 13:42:42 ;) 13:42:53 if guys are interested in sitting together for a hot discussion, please propose a date time? 13:42:53 and when 13:43:11 maybe just a simple meetup, like what we have done in Tokyo 13:43:36 ... we will have meeting room 13:43:40 okay? 13:43:44 not just a table, :) 13:43:51 IBM will host? 13:43:57 maybe in our office? 13:44:19 yes, we'd love to 13:44:24 I guess that is ok for us? 13:44:50 or we can go to vmware site? 13:44:57 sure 13:45:10 we can offer free drinks and cakes 13:45:21 yes, i like your office! 13:45:25 about the date, I think that depends on when is convenient time for you guys who have to travel to Beijing 13:45:30 sounds great 13:45:31 :) 13:45:33 Qiming, me too! 13:45:49 great! 13:46:04 next week would be a busy week for me 13:46:11 I may have to travel 13:46:32 what about you, xuhaiwei ? 13:46:43 most of us are in Beijing :) 13:46:48 and for me, the new years vocation will be about 10 days 13:46:48 right, xuhaiwei, you will be the VIP 13:47:17 Liuqing, can you come? 13:47:24 if the meet up is long enough, I will probably go 13:47:31 i'm coming 13:47:36 Liuqing is not in Beijing? 13:47:44 thanks. let's schedule for two days 13:47:46 if it is only half of a day, I think I can't go 13:47:55 I'm in wuxi,jiangsu 13:48:11 nice place :) 13:48:21 I like wuxi too 13:48:22 Qiming, two days is ok for me 13:48:37 haha thanks yanyanhu, lixinhui 13:48:52 xuhaiwei, please let us know your preferred date 13:48:56 I will report to my leader tomorrow to get the budget 13:48:58 we will schedule this 13:48:59 Anytime is ok for me ;) 13:49:10 ok, Qiming 13:49:14 #topic release model 13:49:43 just got email from ttx, he suggests we switch from release:independent to release:cycle-with-intermediary 13:49:57 it is for better release management 13:50:24 eventually, we are moving to that model 13:50:28 intermediary means? 13:50:38 since ttx is encouraging us to do that earlier 13:50:47 maybe we should follow his suggestions 13:50:58 http://governance.openstack.org/reference/tags/release_cycle-with-intermediary.html 13:51:05 http://governance.openstack.org/reference/tags/release_cycle-with-milestones.html 13:51:05 also don't understand what we should do 13:51:25 Any code change in senlin? 13:51:31 The “release:cycle-with-intermediary” tag describes which projects follow the second option: multiple releases during the development cycle, with a final release to match the end of the cycle. 13:52:03 no code change in senlin 13:52:25 we will be doing release tagging more frequently 13:52:35 I see 13:52:45 have to set clearer goals for each milestone 13:53:22 just want to share with the team where we are 13:53:33 we could have produced a release earlier 13:53:43 There are many temptations to do that 13:54:08 but we are trying to get our code as stable as possible before doing the first release 13:54:22 that is the only reason we are not releasing things so far 13:54:31 #topic open 13:54:44 sorry for always talking tooooooo much 13:55:17 this is what you should do :) 13:55:19 as the ptl 13:55:26 haha 13:55:31 Qiming, I think we can catch next milestone since the API reorg has almost been done 13:55:40 and also the rework of receiver is in good progress 13:55:49 some new guys came to senlin recently 13:55:55 yes, we also need to get the top priority bugs fixed 13:56:07 after verifying the DB concurrency issue is resovled, I think we are ready for it 13:56:22 yanyanhu, agreed 13:56:32 ... receiver 13:56:47 * Qiming is kicking himself 13:56:54 :P 13:57:03 does anyone hear about tempest-plugin? 13:57:09 xuhaiwei, great 13:57:29 what is that for? 13:57:54 that is something for external project unit test which can be ran in tempest 13:58:12 not know well about that 13:58:29 If I'm understanding it correctly, it can help do some surface test 13:58:29 there is a tempest core in our team who is an expert 13:59:08 I know the defcore project is relying on tempest 13:59:12 like make a link from senlin unit test to tempest, and then ran it from tempest 13:59:14 he suggest we move functional tests base on tempest plugin? 13:59:25 xuhaiwei, go ahead 13:59:36 no, elynn 13:59:51 we will continue to be a good citizen in the community, following whatever guidance if needed 13:59:53 some projects are importing it 14:00:11 maybe we need someday 14:00:13 time's up guys 14:00:18 see u 14:00:21 thanks for joining 14:00:25 #endmeeting