13:00:01 #startmeeting senlin 13:00:02 Meeting started Tue Jan 3 13:00:01 2017 UTC and is due to finish in 60 minutes. The chair is yanyanhu. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:05 The meeting name has been set to 'senlin' 13:00:10 hello, everyone 13:01:04 evening, yanyanhu :) 13:01:09 hi, Ruijie_ 13:01:43 lets wait for while for other attenders 13:01:47 hi, yanyan,ruijie 13:01:52 hi, XueFeng 13:02:21 good evneing 13:02:21 hi 13:02:26 hi, Qiming 13:02:52 here is the agenda, please feel free to add topics https://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Agenda_.282017-01-03_1300_UTC.29 13:03:13 ok, lets get started 13:03:22 #topic ocata workitem 13:03:26 https://etherpad.openstack.org/p/senlin-ocata-workitems 13:03:35 lets get through the list first 13:03:52 enhance tempest API test 13:04:24 for our versioned request support has been done, this item can be started 13:04:32 although with low priority maybe 13:04:48 please feel free to claim and work on it 13:04:54 next one 13:05:01 health management 13:05:08 hi, lxinhui 13:05:14 hi 13:05:21 there has been some dicussion on the spec 13:05:25 Yes 13:05:29 about mistral workflow for HA 13:05:59 https://review.openstack.org/414979 13:06:17 In the past week, there are many discussion there. 13:06:31 I think finally the chained recover actions design are the best 13:07:15 if my understanding is right, we need to implment do-worklfow in profile 13:07:32 Yes, and I think Qiming gave a great suggestion that we can use workflow to manage the entire recovery progress and also use it perform operation before/after node recovery 13:07:50 then pre-op, post-op, and the action can call the workflow channel 13:08:03 just I'm also not sure where is the best place to implement do_workflow logic 13:08:12 lxinhui, yes 13:08:28 where do you suggest? 13:08:31 yanyanhu 13:08:44 well, I thought health manager is the better place 13:08:53 how? 13:09:00 but after more thinking, I feel profile could be better now 13:09:01 directly call workflow? 13:09:08 lxinhui, if so, yes 13:09:17 as a parallel option of cluster recover? 13:09:29 just I'm now feeling health manager should be a module to hold more generic logic 13:09:55 but mistral workflow is openstack-specific conception 13:10:04 (at least for mistral workflow) 13:10:43 that is kind of hack for me 13:10:47 the current operation sequence is like this 13:11:05 I look at the health manager like a extention of senlin engine service 13:11:06 1. user request an explict cluster recover operaiton 13:11:18 but the action and policy as plugin framework 13:11:22 2. a cluster recover operation triggered by the detection logic 13:11:55 in both cases, we are initiating a CLUSTER_RECOVER action, which is subject to check by the health poliy 13:12:14 if there is no health policy attached, the default behavior would be recreate 13:12:31 in health policy, we are trying to tune that action to be executed 13:13:06 once that action, e.g. REBUILD, REBOOT, "RUN A WORKFLOW" is determined by the policy 13:13:15 Qiming, yes. If the mistral workflow is operated before/after recovery action, obviously implementing it in health policy will be the choice 13:13:27 just like what we are doing for lb policy I think 13:13:29 the CLUSTER_RECOVER action will call the base profile to do the job 13:14:01 but if we use mistral workflow to drive the entire recovery progress, the situation becomes a little complicated... 13:14:06 it is not only for aspect calling now 13:14:17 maybe we can trigger all recovery actions there 13:15:45 yanyanhu, workflow is one option, even one step of whole recover process 13:15:57 Qiming, all recovery actions? you mean node rebuild/reboot and also workflow operations? 13:16:03 mistral is not the driver but senlin does 13:16:44 lxinhui, yes, just we need to consider where to implement the workflow exection logic 13:16:47 yanyanhu, yes 13:17:06 that is question I proposed :) 13:17:06 I see. if so, profile should be the place to hold it? 13:17:15 like do_recovery 13:17:26 only the base profile 13:17:30 it is dirty ... 13:17:31 yes 13:17:36 that is 13:18:02 or another option is we parse the list of actions user specified in the policy spec 13:18:07 I also feel only implementing it in base profile can help to avoid code duplication. 13:18:19 if it is a workflow, we invoke it directly, as another action 13:18:22 what code duplication? 13:18:34 something I mist here 13:18:48 if it is a builtin action or profile operation, we return that in action.data 13:18:49 duplicate with what? 13:18:51 Qiming, invoke it directly in health manager? 13:19:09 health manager is only for the health detection side 13:19:14 it is not a "manager" 13:19:25 yes, yanyanhu 13:19:39 it is not the right place 13:19:43 lxinhui, I mean if the workflow execution logic(do_workflow maybe) is not implemented in profile base, you may need to add do_workflow method for every profile type who needs this logic 13:19:50 There are possibilities that users explicitly request a cluster to be recovered 13:20:02 thus the action sequence is not triggered from the health manager 13:20:06 Qiming, I see 13:20:15 so that will be part of recovery action 13:20:37 so workflow exection logic will be part of do_recovery action impelementation 13:20:46 i think so 13:20:51 yup, in current design, workflow is only used for recovery's purpose 13:21:18 I see 13:21:19 we use use type to switch to workflow 13:21:34 s/use/can/g 13:22:04 considering that we will have to support a list of actions (with and without workflow as action types), placing the iteration logic in base profile sounds fine to me 13:23:01 the parameter passing logic is there, just ... we don't have the code to parse and execute more than one action 13:23:24 http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/cluster_action.py#n657 13:23:27 Qiming, yes, action is the atomic operation for us 13:24:01 so combination of actions should be done at higher level, e.g. API or rpc 13:24:03 line 658 is only extracting the first action for execution 13:24:12 yes 13:24:40 And no one review the SDK patch... 13:25:09 the api twist patch of mistral has been merged 13:25:53 lxinhui, good news :) 13:25:55 another place is here: http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/node.py#n368 13:26:01 https://review.openstack.org/#/c/414919/3 13:26:29 lxinhui, it is not done 13:26:40 that patch still has tons of problems 13:26:50 please review 13:27:13 just I still free that workflow is not a generic conception... 13:27:13 will do 13:27:40 doesn't like other logic we defined in cluster action module 13:27:48 or in node module 13:28:55 lxinhui, you missed '_query_mapping' in those classes, the current code only support create, but allow_get is already there, 'include_output' is only a query parameter, ... 13:29:04 let us finish it little by little 13:29:11 okay 13:29:32 yanyanhu, you can think of it as creating a ceilometer alarm 13:29:38 need read more code of sdk 13:30:40 Qiming, yes 13:31:06 but we usually support those service specific operations in plugins 13:31:10 I feel 13:31:26 not in generic modules, like node, cluster, or action modules 13:31:44 yes, we will add drivers for workflow 13:31:57 yanyanhu, seems you like AOP more than workflow 13:32:11 Qiming, yes, I mean maybe we need to wrap and abstract mistral workflow? 13:32:22 we can invoke workflow APIs from the health policy 13:32:22 lxinhui, AOP is? 13:32:28 just joke 13:32:33 :) 13:32:46 Qiming mentioned the concept in his mind last time :) 13:32:52 Qiming, yes, that makes more sense to me 13:33:01 the problem is that it will be difficult to build dependencies if some actions are triggered in policy, others are in profiles 13:33:15 Qiming, right, that is a headache 13:34:08 till now, we either talk to backend service during action execution, or before/after action progress 13:34:18 but not at the same time 13:34:53 right 13:35:18 so I'm thinking if this is the proper location to iterate all the action items and execute them one by one 13:35:20 http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/node.py#n368 13:36:04 you mean here? http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/node.py#n380 13:36:18 yes 13:36:29 so it will fall into profile 13:36:40 that is only capable of doing some builtin operations 13:36:42 not workflows 13:36:45 this feature also fit heat stacks? 13:36:54 yes, Ruijie_ 13:36:56 Qiming, yes 13:37:10 Ruijie_, yes, also dockers 13:37:15 we provide knives 13:37:15 we hope so :) 13:37:21 you decide how to use it 13:37:29 yes, I think so depspite little mess is heat can call mistral too 13:37:30 kill people or cook meal 13:37:37 yep, that is the logic 13:38:04 so maybe we start from node.py 13:38:04 again, alike ceilometer... 13:38:43 we won't be responsible for debugging the workflows 13:38:56 sure 13:39:16 uses decide how to write workflows to operate a specific nova server, heat stack, ... etc. 13:39:18 precondition is that users have their own trusted workflow 13:39:42 yes, we just help to trigger it according to the rule user defines 13:39:52 in the right place at the right time 13:40:21 mean people :) 13:40:32 :P 13:41:00 there are possibilities users trigger a workflow on a stack which was meant to be used on VM 13:41:05 but that possibility is small 13:41:24 you won't use the same health policy on clusters of different types of entities 13:41:33 at least I will call that stupid 13:41:56 yes 13:42:05 so lxinhui, maybe you can finish the spec based on this discussion 13:42:27 and we can talk more about the implementation detail later 13:42:30 just like you want to delete a cinder volume using 'nova delete', ... it won't work, for sure 13:42:39 :) 13:42:44 yes 13:42:50 let's move on 13:43:00 ok, lets move on 13:43:08 senlinclient test 13:43:16 hi, XueFeng, you're working on it now? 13:43:56 don't think so ... need a starting point I think 13:44:03 I see 13:44:07 one simple test, plust gate setup 13:44:22 yes 13:44:23 then people can share the jobs adding test cases 13:44:27 that will be the basement 13:44:37 ok, will check this work later 13:44:42 basement is floor -1 13:44:53 haha, yes 13:44:54 :D 13:45:00 ok, next one 13:45:01 renaming service calls 13:45:09 saw lots of patches for it last week 13:45:19 I think it hasn't been done yet? 13:45:27 didn't check the code... 13:45:33 but anyway, not very difficult work 13:45:56 ok, next one 13:46:01 container profile 13:46:10 haiwei is not here I think? 13:46:25 and those two patches have been merged 13:46:31 will remove them from the etherpad 13:46:32 it's almost done I think 13:46:33 OMG, it is done 13:46:45 yes, it is done 13:46:52 call2, reqquest_context2 all removed ... 13:46:55 have removed them :) 13:46:59 amazing 13:47:00 cool 13:47:24 yes, the configure option has also been removed 13:47:25 :) 13:47:37 so we have finished the switching 13:47:52 hi, come back 13:47:54 so that's all in the list 13:47:57 hi, XueFeng 13:48:04 about client test 13:48:12 we just talked about the test job for client 13:48:54 maybe a simple test case plus gate job setting up will be a good startpoint 13:48:55 Will ping you tomorrow 13:49:05 then more people can jump into it :) 13:49:11 XueFeng, sure, thanks a lot :) 13:49:23 ok, next topic 13:49:34 #topic Adopt existing VM for scaling 13:49:41 https://etherpad.openstack.org/p/%E5%BC%B9%E6%80%A7%E4%BC%B8%E7%BC%A9%E7%BB%84%E6%94%AF%E6%8C%81%E6%B7%BB%E5%8A%A0%E4%BA%91%E4%B8%BB%E6%9C%BA 13:49:46 WOW... 13:50:04 here is a etherpad created by eldon from cmcc 13:50:14 about adopting exiting vm(s) for scaling 13:50:54 please feel free to leave your comments if you're interest about this topic :) 13:51:14 may need an english version for it... 13:51:45 called "add an exiting node to cluster", I guess 13:51:49 any question about it? 13:52:09 just adoption would be okay 13:52:14 will this combined with another workflow 13:52:17 it may and may not be related to scaling 13:52:34 copy an vm's spec and use it to create VMs 13:52:40 yes, adoption can be individual from scaling 13:52:58 s/can be/is 13:53:18 orthogonal 13:53:30 I learn this word from Qiming, haha 13:53:54 so guys, please read it and share your ideas 13:54:10 so lets move on? 13:54:15 5 minutes left 13:54:24 #topic meetup 13:54:45 so here is the question. Who you guys can join it if we hold a meetup in Beijing :) 13:55:02 * Ruijie_ :) 13:55:07 I can ;) 13:55:12 or you will join it, you know the haze :P 13:55:28 elynn, me too :) 13:55:40 cool, someone volunteered to pay the bill, \o/ 13:55:50 so just want to listen to your idea, especially who are now based on Beijing 13:55:56 Qiming, haha 13:56:37 that will decide the size of our meetup 13:56:50 In BeiJing?When? 13:57:01 XueFeng, should before china spring festival 13:57:01 free coffee serving :) 13:57:09 but haven't decided yet 13:57:15 OK. 13:57:20 elynn, that's good enough :) 13:57:36 XueFeng, where are you working at now? 13:57:44 not in Beijing? 13:58:09 since if not, there will be travel fee need to cover :) 13:58:10 NanJing,haha 13:58:16 not far :) 13:58:38 ok, maybe we can talk about this offline before you guys make decision 13:58:41 Nanjing is a good place :) 13:58:45 just want to remind we have the plan to hold it 13:58:55 lxinhui, agree 13:59:03 :D 13:59:10 I will ask you guys tomorrow in senlin channel 13:59:17 and lets decide it together 13:59:21 :) 13:59:30 great 13:59:34 Will apply for this tommorrow 13:59:42 Maybe it's ok. 13:59:48 meetup and talk are always pleased 13:59:53 pleasing 14:00:04 XueFeng, cool 14:00:09 ok, time is over 14:00:15 thanks all you guys for joining 14:00:18 have a good night 14:00:20 ttyl 14:00:25 #endmeeting