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