13:00:49 #startmeeting senlin 13:00:50 Meeting started Tue Dec 8 13:00:49 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:51 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:54 The meeting name has been set to 'senlin' 13:01:09 good evening/morning/... 13:01:16 hi 13:01:25 hello 13:01:26 o/ 13:01:31 hi 13:01:53 please check agenda and see if you have things to add 13:02:02 https://wiki.openstack.org/wiki/Meetings/SenlinAgenda 13:02:35 as usual, lets start with the etherpad 13:02:44 #topic Mitaka work items 13:02:51 #link https://etherpad.openstack.org/p/senlin-mitaka-workitems 13:03:08 Resource type -- elynn 13:03:53 hi 13:03:56 previously, it was delayed by the api change 13:04:15 no progress this week, api change is done? 13:04:17 I think the API modification is drawing near its end 13:04:38 we will do some modifications next to the senlinclient 13:04:50 good to know, I will update these patches this week 13:05:09 okay, the latest patch to sdk is about profile type 13:05:14 I would like to add a template to heat-templates, what do you think? 13:05:14 ref: https://review.openstack.org/#/c/253817/ 13:05:31 elynn__, we can do that later 13:05:46 first we need to make sure things work stable 13:06:04 Qiming: you mean after other resources added to heat? 13:06:14 yes, elynn__ 13:06:20 like policy or webhook 13:06:34 for example, the update operation is not fully supported I think 13:06:45 policy and webhook are midterm goals 13:07:00 ok, I will focus on cluster and node resources now. 13:07:01 will need specs on that before working on the code 13:07:11 yes, focus on the basics please 13:07:33 Qiming: yes, I haven't fully tests update now, I might wait for senlin to get stable. 13:07:49 the last missing resource type in sdk is policy-type 13:07:56 that won't be a big deal 13:08:08 after that senlinclient can be pretty simplified 13:08:31 elynn__, please help get it stable instead of waiting if you have cycles 13:08:44 Qiming: ok , I can start to test the codes now. 13:08:48 we need at least CRUD working properly 13:09:02 great 13:09:08 #topic senlinclient unit test 13:09:19 Qiming: yes, I will do some test on senlin. 13:09:25 I didn't do it this week 13:09:28 the unit test 13:09:28 https://review.openstack.org/251798 13:09:35 this one was reviewed 13:09:39 focused on the api side 13:09:49 okay 13:10:07 honestly I don't know why jenkins failed 13:10:08 please check if changing 'MagicMock' to 'Mock' makes sense to you 13:10:42 every single test case can be passed but when running all the tests some of them failed 13:11:00 replacement of MagicMock is Ok to me 13:11:07 alright, when help is needed, pls let the team know, :) we can share tears 13:11:28 okay, another concurrency problem 13:11:28 I will update the patch soon 13:11:37 good luck 13:11:47 yes 13:11:47 :) 13:11:58 #topic api modification 13:12:23 you and me, right? 13:12:25 201/202 response code is already done, right? 13:12:51 I uploaded two patches in the afternoon 13:12:53 current focus is to make sure we are returning a 'location' header when appropriate 13:13:06 yep, saw that, progress is good 13:13:22 most of the APIs have been done, I think 13:13:38 I will check if anything is missing 13:14:01 201/202 are done 13:14:12 okay, when you are checking it again, please cross verify it with the docs 13:14:19 Is there any change for senlinclient? 13:14:24 #link https://review.openstack.org/#/c/252245/ 13:14:31 ok, I will check the docs 13:14:41 this is the doc patch, finally got some commens from cores 13:14:56 the long doc 13:14:59 the PDF version is easier to read: http://docs-draft.openstack.org/45/252245/10/check/gate-api-site-tox-doc-publish-checkbuild/d1f26a1//publish-docs/api-ref-guides/bk-api-ref-clustering-v1.pdf 13:15:35 the HTML version is more interation oriented: http://docs-draft.openstack.org/45/252245/10/check/gate-api-site-tox-doc-publish-checkbuild/d1f26a1//publish-docs/api-ref/api-ref-clustering-v1.html 13:16:06 400/404 rework is completed 13:16:20 release notes commited as well 13:16:46 #topic health management 13:17:04 I've being thinking about it 13:17:09 need another brain 13:17:42 lixinhui, want to work on this? 13:17:52 Sure 13:18:14 I was told that your brain quality is good, :) 13:18:30 can you explain the basic goal of health policy 13:18:34 really? 13:18:40 health management 13:18:41 :) 13:19:08 explain please :) 13:19:09 network problem again 13:19:37 i heard something, then I was disconnected 13:20:02 Powerful ears :) 13:20:15 lixinhui, let's start with some use cases 13:20:25 seems someone want Senlin to control like : if a vm is dead senlin will start a new one 13:20:28 we are not about to solve all problems 13:20:56 yes, haiwei it sounds pretty simple a scenario 13:21:04 but it is not that straightforward 13:21:06 yes, whole picture is so complicated 13:21:09 but it seems not easy 13:21:22 maybe need a new command for it? 13:21:36 yes, there are at least three factors for consideration: 13:21:50 1. failure detection; 2. failure notification; 3. failure recovery 13:22:42 senlin will have to do recovery, either manually or automatically 13:23:00 because it is MANAGER of the groups 13:23:17 seems there is a long way to go 13:23:23 senlin will provide receivers for notifications 13:24:14 it should allow recovery to be triggered by any external alert/alarm/event/monitoring systems 13:25:14 finally, we will look into some naive (builtin) detection mechanisms 13:25:14 there is no easy answer to any of these three questions 13:25:24 is that possible the failure detection and notification is from senlin service inside? 13:25:59 off line again? 13:26:01 ...my question make him disconnected again? 13:26:08 haha 13:26:12 haha 13:26:49 sigh ... I was out again 13:26:57 did I miss something? 13:27:04 nope 13:27:11 :) 13:27:22 hexchat is very unstable 13:27:23 is that possible the failure detection and notification is from senlin service inside? 13:27:32 so the last question is 13:27:45 I'd say yes 13:28:03 I also think so 13:28:26 but reliable failure detection is a domain by itself 13:28:40 I'm using mIRC now 13:28:50 just bought a license 13:29:06 okay, moving on? 13:29:14 yes 13:29:15 or there are questions? 13:29:16 ok 13:29:24 no 13:29:29 #topic update operation 13:29:45 actually didn't have time to work on it this week... 13:29:53 I think yanyan was completely trapped by the DB concurrency problem 13:29:59 yea... 13:30:17 finally, functional tests are passing now 13:30:26 I'm a little worried there could be no perfect solution for this issue... 13:30:28 except for the webhook one 13:30:30 saw the patch , but can't help 13:30:52 I spent some time reading sqlalchemy docs as well 13:31:03 maybe this is the only workaround we have today 13:31:15 yes, I also have the same feeling... 13:31:29 maybe we have to make a tradeoff here 13:31:39 listen to the developers, they may cheat you, but they are the most honest people you are talking to, :) 13:31:50 yes 13:31:52 so we will follow the docs 13:32:14 and I found some most useful info sometimes came from stackoverflow :) 13:32:17 okay, moving on 13:32:24 #topic Receiver 13:32:40 I don't think Julio will have cycles in the coming weeks 13:32:46 so I'm gonna take over that 13:33:06 ok 13:33:14 #topic lock breaker 13:33:35 I will 13:33:49 find a way to add related tests this week 13:33:50 haven't do some real tests on the lock breaker thing 13:34:10 cool, thanks, god 13:34:27 #topic parser test case 13:34:30 elynn__, great 13:34:38 cool 13:34:47 em ... anyone want to claim this? 13:35:05 I can do that 13:35:16 thanks, god^2 13:35:38 ;) 13:35:53 #topic functional tests 13:36:16 I think after DB sync issue is resolved, we can have a clean basement for new coming test cases 13:36:20 we are almost there? 13:36:25 especially for those ones about lock 13:36:27 yes 13:36:49 hope can finish it this week 13:36:56 it is rebased on the webhook patch? 13:37:07 yes, I rebased it 13:37:11 cool 13:37:27 good to hear! 13:37:34 lets wait for the result :) 13:37:45 I was thinking maybe not just mark_succeed needs this, other similar functions will needed the fix as well 13:37:49 for completeness 13:38:19 #topic bug clearance 13:38:46 I did spend some time on reviewing the bugs, but ... I need to spend more 13:39:04 manually mark them as 'fix released' 13:39:09 it's a hard work... 13:39:18 this will be done automatically in future, fortunately 13:39:20 robot model 13:39:26 there are many ones which are open? 13:39:42 Qiming, http://lists.openstack.org/pipermail/openstack-dev/2015-December/081612.html this mail link you shared 13:39:56 haiwei, you got to do an 'advanced' search, to find the open ones 13:40:13 currently, 'fix commited' ones are still not treated as closed 13:41:04 let's take a look at the blueprints? 13:41:08 #link https://blueprints.launchpad.net/senlin/+specs?show=all 13:41:13 ok 13:41:49 some are started but not approved 13:41:54 most backlogs have been marked as implemented 13:42:48 em ... 13:43:01 lock breaker patches were not linking back the the bp 13:43:36 Seems most of my patch didn't link back to launchpad 13:43:36 I can see three patches there 13:44:15 Hmm, This BP have all my patches links. 13:44:40 this one? https://blueprints.launchpad.net/senlin/+spec/lock-breaker 13:44:41 okay, maybe because it was not approved? 13:45:23 I don't think so Qiming 13:46:40 okay, maybe this has to be manually reviewed 13:47:16 #topic open discussions 13:48:35 elynn__ has submitted a patch https://review.openstack.org/#/c/254254/4 13:48:52 anything folks want to discuss? 13:49:07 ah, this one 13:49:40 I am a little confused about the original implement 13:49:41 quick question about action API rework. So we still have action_id returned back in resp body right? 13:49:55 haiwei: You mean after policy/profile_create, we should retrieve policy again ? 13:50:08 Yanyanhu, it was not mentioned anywhere 13:50:15 Yanyanhu, I think so, client side is using it 13:50:25 yes, just check the code and feel so 13:50:38 I was thinking about the same question 13:51:01 however, no one is preventing us from doing so 13:51:21 elynn__ I just don't know why we should both support policy_id and policy 13:51:48 Qiming, what question? 13:52:20 returning action id in body 13:52:31 elynn__ since only one way is in effect 13:52:48 Good question, the codes are already there before I modify it... If use policy, we can save a call to get resource back. 13:52:59 whether we should do that, my feeling is that it is okay, no one said 202 cannot return a body 13:53:27 for update, we do return a body 13:53:47 haiwei: It's ok to remove policy support and always retrieve resource after creation. 13:54:14 I feel the same way, elynn__ 13:54:27 I was lost, seems the patch is about profiles, and you are talking about policies 13:54:59 :) 13:55:05 Qiming: It's a bug report by you 13:55:23 policy should be done exactly as profile, but it is not 13:55:38 I don't know why 13:55:38 Qiming, about the action_id. I agree to keep it in resp body 13:55:40 ah, that title should be changed 13:55:49 I mean the commit message 13:56:23 it is talking about both profile and policy, but the patch only fixes profile, not policy, that is the issue you are talking about? 13:56:39 I just make them behave the same. 13:56:54 this patch touches both of them. 13:57:10 Qiming: It also fixes policy 13:57:25 actually no, I don't know both policy_id and policy are both in the parameters Qiming 13:57:31 Qiming: https://review.openstack.org/#/c/254254/4/senlinclient/v1/client.py L90 13:58:11 I am lost too when reviewing this patch for the first time 13:58:42 heihei, Seems my commit message mislead you... 13:58:51 em... need some time to understand the 'extra_attrs' parameter 13:59:28 If extra_attrs is True ,will use response body to update resource attributes 13:59:52 sdk code says so? 13:59:53 like created_time, so that we can display them correctly. 13:59:59 No... 14:00:16 okay, let's continue in #senlin 14:00:20 time is up 14:00:20 #endmeeting