13:02:11 #startmeeting senlin 13:02:12 Meeting started Tue Dec 27 13:02:11 2016 UTC and is due to finish in 60 minutes. The chair is yanyanhu. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:02:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:02:15 The meeting name has been set to 'senlin' 13:02:20 hi 13:03:54 hi, lxinhui, evening 13:04:38 ok, lets wait for a while 13:04:43 hi 13:04:51 hi, xinhui 13:04:52 Merry Xmas 13:04:56 you too :) 13:05:00 :) 13:05:07 how is the holiday 13:05:13 any celebrating? 13:06:13 hi 13:06:19 hi, Qiming 13:06:31 ok, lets get started 13:06:38 https://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Agenda_.282016-12-27_1300_UTC.29 13:06:47 here is the agenda, please feel free to add items 13:07:02 #topic ocata workitem 13:07:05 https://etherpad.openstack.org/p/senlin-ocata-workitems 13:07:11 testing 13:07:16 no progress 13:07:28 Health management 13:07:44 hi, lxinhui, any update about it? 13:08:13 I am working on mistral support in Senlin 13:08:17 didn't saw further response from octavia team for that patch 13:08:22 lxinhui, cool 13:08:36 https://review.openstack.org/414979 13:08:37 Qiming is working on sdk support I think 13:08:49 https://review.openstack.org/414919/ 13:09:14 and small fix to Qiming's early patch on mistral 13:09:19 https://review.openstack.org/414755 13:09:21 nice 13:09:28 will help to review that patch 13:09:56 one thing I wanna more discussion is about https://review.openstack.org/414979 13:10:17 that is spec drafted for this workflow service support 13:10:58 change in Senlin will include driver, profile, and policy 13:11:06 profile? 13:11:20 you mean a profile type for mistral workflow? 13:11:26 in profile, I plan to add one method in nova server named as do_worflow 13:11:47 lxinhui, I see 13:12:05 or maybe that should be part of health policy? 13:12:16 in policy, I think we need support operation named as 'WORKFLOW' 13:12:39 and define new tags named as 'work_flow_parameters' 13:12:42 lxinhui, yes, that makes sense 13:12:48 should we trigger the workflow from within the policy? 13:13:12 do you mean all profile types should be extended with workflow awareness? 13:13:12 under 'work_flow_parameters 13:13:40 users can provide workflow_name, input, definition alike key-value 13:14:00 yes, then that workflow should be triggered as one step of the recovery process 13:14:19 it is a procedure to be called from the health policy, isn't it? 13:14:20 Qiming, instead of base profile, I prefer to add do_workflow into nova only 13:14:35 it is one of opetions of recover_action 13:14:59 does that mean health policy is only applicable to nova server? 13:15:07 just I feel maybe we don't need to define do_workflow for profile type? 13:15:21 since heat itself can coordinate with workflow 13:15:24 yes, that is what I was thinking 13:15:40 I guess we can mix the operations of nova server/heat stack in the same mistral workflow? 13:15:51 not sure that understanding is correct 13:15:56 I do not think so 13:16:07 heat itslef can support workflow 13:16:22 what do you mean by heat support to workflow? 13:16:32 if the stack need that function, they can think about how to achieve by their stack definition 13:16:47 heat has mistral resources 13:17:00 so what? it is not about a resource pool 13:17:15 Senlin is not resource pool :) 13:17:20 as we discussed 13:17:29 it only care about array operations 13:17:48 * Qiming speechless 13:18:12 that is my conservative opion about definition of resource pool 13:18:27 I come from Vmware and have own defintiion about resource pool 13:18:41 but it is not directly realted to stack 13:19:11 hi, lxinhui, I feel a workflow which is triggered during HA progress could be consist of multiple different operations on different type of resources, e.g. nova server, heat stack or even loadbalancer. 13:19:15 here I would suggest to only support nova working together with mistral 13:19:51 yanyanhu, so you suggest put do_workflow in base profile? 13:19:57 so I guess it could be more clear to splitting the workflow defintion from the profile types 13:20:26 what your suggestion 13:20:30 ? 13:20:36 let me see 13:20:51 I understand what senlin suggest about stack, nova, container 13:21:05 just trying to deliver proper implements 13:21:20 so please suggest where to change? 13:21:41 put do_workflow into base profile? or somewhere else 13:21:44 lxinhui, yes, understand. Just feel implementing workflow as an individual conception might be better? 13:21:55 what do you mena 13:22:08 I can add a driver about workflow service 13:22:09 I mean workflow is just for HA purpose 13:22:31 we allow users to define a workflow and pass its ID to senlin when creating HA policy 13:22:42 this is the simplest case 13:22:59 that is what users can see 13:23:00 sure 13:23:08 but I think we are discussing about 13:23:14 where to put the do_workflow 13:23:35 the function will call mistral driver I will add to execute the given workflow 13:24:08 let me see 13:24:22 I just mentioned the planned change to health policy 13:24:55 that is where users can point to use workflow and all paramerts need 13:25:27 if the do_workflow is for wrapping the workflow exection, maybe we just define it in side HA policy? 13:25:44 inside 13:26:06 when to execute? 13:26:18 attach? 13:26:19 when failure is detected? 13:26:34 detection is executed else where 13:26:55 yes, but the recovery method is defined in HA policy 13:26:56 you mean in heatlth manager? 13:27:02 yes 13:27:04 lxinhui, ah, right 13:27:11 my fault, didn't express it clearly 13:27:18 in health manager 13:27:31 you mean we will parse the recover acions and all paramerts in health manager? 13:27:43 nowdays, actaully we only call cluster_recover 13:28:09 and cluster_recover will execute the defined action like rebuild or recreate... 13:28:28 lxinhui, I'm not quite clear about the detail. So the recovery method is passed to cluster_recover as input params? 13:28:44 by implement do_workflow, I will add one option into do_recover 13:28:59 I see 13:29:06 pre_op is determining exact recover operation to be done 13:29:08 policy attach will parse eerything and put it into cluster data 13:29:23 we are about to add other options such as reboot, evacuate for nova servers 13:29:30 once the SDK releases a new version 13:29:39 driver side is ready 13:29:41 yes 13:30:03 before or after a recover action is taken, we can invoke the named workflow with the provided parameters 13:30:06 so that is the reason I think can put workflow as parallel option as these operations 13:30:36 why before or after? 13:30:55 that is something we will add as conditions for users to specify 13:31:29 what something, could you explain more 13:31:35 before doing nova server recovery operations, call this workflow to backup some data 13:31:52 that is just somewhere can be done 13:32:03 but for HA functions 13:32:06 then after nova server recovery is done, call that workflow to recover something once the server is up 13:32:16 in my current understanding, we add the workflow parameters to health_policy, when we detect failure of the nodes, we will call cluster_recover, and we can load the workflow parameters when do_revocer? 13:32:16 workflow itself can be one options of recover action 13:33:08 if we define do_workflow, it can be called in before, after, and one of recover_actions 13:33:14 that is my understanding 13:33:15 yes, in an ideal world, workflow should be easy to write and debug 13:33:42 yes, we are talking about the same thing 13:33:55 just I'm suggesting leaving the do_workflow call inside the health policy 13:35:08 that means the do_workflow will be either pre_op or post_op of recover action 13:35:12 ok, little bit like lbaas implements 13:35:34 then should we define these parameters in heath_policy and load them in pre_op 13:35:34 lbaas policy 13:35:36 or modeled properly, can do both 13:35:44 right. 13:35:44 lxinhui, yes, policies all work in that way 13:35:54 lbaas is the example 13:35:55 yes, can be both 13:36:17 okay, I will revise the spec 13:36:21 accoringly 13:36:25 do need more thinking here 13:36:29 if, unfortunately, we found that mistral is not trustworthy, we can advise users to use the healthpolicy cautiously 13:36:37 but trust our profile implementation 13:36:46 just like lb policy 13:37:03 if lbaas is forever immature, we abandon lb policy 13:37:47 make sense 13:37:57 actually it's not difficult to write a new lb policy 13:38:05 maybe we have been pushing too hard on the aspect-oriented programing (AOP) design philosophy 13:38:08 even for some HW LB like f5 13:38:32 if lbaas keeps failing us, it is not our fault 13:38:33 Qiming, please explain more about AOP 13:38:36 in senlin 13:38:48 users can still develop their own lb policies 13:39:21 we are modeling HA, LB, AutoScaling, Cross-AZ placement ... all as independent aspects of clusters 13:39:34 ... ok 13:39:36 they can be combined in whatever way to meet user requirements 13:40:32 I'm not saying this is a good philosophy ... just want you know what I came from 13:40:55 just wanna confirm conceret meaning of aspect in Senlin. thanks 13:41:00 it helps a lot 13:41:49 ok, lxinhui, please update the spec and lets have more discussion based on it 13:41:53 I think I got clear minds now and will revise the spec 13:42:16 need more thinking on both design and implementation detail 13:42:22 thanks a lot 13:42:24 great, some examples there would be very helpful 13:42:33 agreed, yangyapeng 13:42:40 oops 13:42:44 i will add live migration and resize as examples 13:42:51 :) 13:42:57 simple but useful 13:43:02 great 13:43:03 into exmaples 13:43:09 nice 13:43:20 if the specs is clear enough, people will be more familar with the design 13:43:43 ok, if there is no further question on this item, lets move to next one 13:43:45 they can help share the implementation, debugging, reviewing things 13:44:07 yep 13:44:15 ok, documentation 13:44:19 User/developer doc for event dispatchers is done 13:44:26 it has been merged 13:44:31 also updated wiki pages 13:44:33 thanks, Qiming 13:44:55 also the API doc for node operation 13:45:04 there are picky eyes finding errors I made in the doc 13:45:05 will help to review it soon 13:45:11 :) 13:45:14 a lot help we are getting recently 13:45:48 ok, next one 13:45:51 senlinclient test 13:45:54 XueFengLiu, around? 13:46:03 yes 13:46:23 For senlinclient 13:46:24 I think you're working on it:) 13:46:59 if there are resources 13:47:10 I'd suggest we start adding functional tests for senlinclient 13:47:23 OK 13:47:26 maybe not for our own CLI 13:47:29 Just begin to do 13:47:29 Qiming, yes, that will be very useful 13:47:33 for the osc client plugin 13:47:46 XueFengLiu, if you need help on how to setup the gate job 13:47:46 so that we can ensure things are not broken along the way 13:47:50 please just ping me 13:48:10 will show you how to do it 13:48:22 ok, after this check work finish 13:48:29 XueFengLiu, sure, no hurry 13:48:39 will try to ad functional tests 13:48:45 great 13:49:02 ok, next item. Versioned request 13:49:15 so we are now working on renaming service calls 13:49:38 Most of them have finished 13:49:53 thanks XueFengLiu, hongbao's work :) 13:50:17 such as call2... still need to rename 13:50:27 yes 13:50:35 need to clean them all 13:50:39 there have been some conflicts 13:51:04 but they are happy problems, it shows us how folks are working hardly recently 13:51:09 yep 13:51:17 they are all working on service module :) 13:51:23 yes 13:51:42 ok, container profile 13:51:52 haiwei is not here? 13:51:52 no update recently 13:51:56 ok 13:52:07 I think we will need to add a lot features there 13:52:08 Events/Notifications 13:52:18 so this job has been done, right? 13:52:20 fixed some bugs in config 13:52:26 documented 13:52:28 I see 13:52:32 about docker 13:52:40 yes, documentation for user/developer has been added and updated 13:52:41 yes can close the event/notification topic now 13:52:48 Qiming, ok 13:52:57 we can add some tutorials about consuming senlin notifications 13:53:03 QiMing fixed a problem:cluster and node is not both in config 13:53:11 Qiming, yes, that will be very helpful for users 13:53:33 just heads up, a quick update on profile type operations 13:53:52 we are adding a lot operations that are supported by the backend resources 13:54:04 ah, right 13:54:12 for example, nova server supports start, stop, reboot, evacuate, migrate ... 13:54:14 for those operations have been supported in sdk 13:54:25 we are adding three calls recently 13:54:29 senlin profile-type-ops 13:54:50 will return a list of operations (with parameters specification) supported by a profile type 13:55:12 senlin node do reboot -f role=slave -p type=soft 13:55:24 will reboot the specified nova server node 13:55:42 senlin cluster do reboot -f role=slave -p type=soft 13:55:57 sounds great 13:56:00 will reboot all nodes that have a role == slave to do a soft reboot 13:56:28 patches are almost all there 13:56:31 All of them are useful 13:56:39 yes 13:56:54 very useful 13:57:02 ok, that's all items in the list 13:57:09 we have only 3 mins left :) 13:57:25 maybe we need a plan for O3? 13:57:29 just reminding, we have less than a month before r3 release 13:57:33 yes 13:57:45 far less tan 1 month I think 13:57:47 :D 13:57:51 yep 13:58:03 3 weeks, including the holiday 13:58:22 or should we schedule a PTG somewhere? 13:58:23 so please focus on the important feature on our plan 13:58:29 and critical bugs 13:58:39 Qiming, sure, that will be great 13:58:54 maybe we can have a discussion on it 13:59:02 tomorrow, for the detail 13:59:08 would be good to know how people are or want to use senlin 13:59:13 yes 13:59:33 ok, will think about it and sync with you guys 13:59:47 \o/ 13:59:51 to see when and where is acceptable for all of us 13:59:59 ok, time is almost over 14:00:04 thanks you guys for joining 14:00:15 good night:) 14:00:18 have a good night and merry christmas and happy new year :) 14:00:25 #endmeeting