13:00:03 <yanyanhu> #startmeeting senlin
13:00:04 <openstack> Meeting started Tue Nov  8 13:00:03 2016 UTC and is due to finish in 60 minutes.  The chair is yanyanhu. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:08 <openstack> The meeting name has been set to 'senlin'
13:00:21 <yanyanhu> hello
13:00:39 <Ruijie> evening :)
13:00:48 <yanyanhu> hi, Ruijie, evening :)
13:01:19 <lvdongbing> hi, yanyan, ruijie
13:01:24 <Qiming> hi
13:01:28 <yanyanhu> hhi, lvdongbing, Qiming
13:01:45 <yanyanhu> lets wait for a while for other attenders
13:01:52 <yanyanhu> https://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Agenda_.282016-11-01_1300_UTC.29
13:02:08 <yanyanhu> here is the agenda, please feel free to add items you want to discuss
13:02:13 <yanyanhu> hi, lixinhui_
13:02:19 <elynn> hi
13:02:20 <lixinhui_> hi, yanyanhu
13:02:23 <yanyanhu> hi, elynn
13:02:31 <lixinhui_> hi elynn
13:02:45 <yanyanhu> ok, lets move on
13:02:46 <Hosam> hi everybody
13:02:54 <yanyanhu> #topic ocata work items
13:03:02 <yanyanhu> https://etherpad.openstack.org/p/senlin-ocata-workitems
13:03:08 <yanyanhu> ocata workitems
13:03:12 <yanyanhu> hi, XueFeng
13:03:18 <XueFeng> hi,all
13:03:33 <lixinhui_> hi
13:03:34 <yanyanhu> ok, lets first go through the item list
13:03:55 <yanyanhu> performance test, still no progress, didn't get time to work on it recently
13:04:09 <yanyanhu> HA
13:04:19 <yanyanhu> hi, Qiming, lixinhui_, any update about it?
13:04:31 <lixinhui_> I tried mistral
13:04:36 <lixinhui_> with basic flow
13:04:40 <yanyanhu> nice
13:05:18 <lixinhui_> and still can not quiet underdtand its definition about flow switch
13:05:27 <lixinhui_> will investigate more there
13:05:39 <yanyanhu> ok
13:05:47 <yanyanhu> thanks for the effort on this
13:05:48 <lixinhui_> and I am not sure if we will put the actions into senlin or mistral itself
13:05:58 <lixinhui_> by "actions", I mean mistral flow actions
13:06:12 <yanyanhu> you mean?
13:06:35 <Qiming> it is a question of engine-centric HA solution or workflow-centric HA solution, I guess
13:06:37 <yanyanhu> using senlin to drive the workflow or using mistral to drive it?
13:06:43 <lixinhui_> if put inside senlin, that means senlin will maitain the flow for recovers or some cluster management purpose
13:06:54 <lixinhui_> if put them inside mistral
13:07:10 <lixinhui_> then users need to maintain there
13:07:18 <yanyanhu> ok, so any pro or con for these two choices?
13:07:43 <yanyanhu> like a template?
13:07:44 <lixinhui_> if we wanna leverage mistral flow as recover of senlin
13:08:03 <lixinhui_> seems we should maintain them
13:08:10 <lixinhui_> yes
13:08:14 <yanyanhu> I see
13:08:38 <lixinhui_> I assume the flow template should be put together with the actions together
13:08:54 <lixinhui_> and openstacksdk does not support mistral today
13:08:55 <Qiming> it is like the design choice we were facing when modeling ceilometer alarms
13:09:16 <yanyanhu> Qiming, have the same feeling
13:09:50 <lixinhui_> so we should leave them inside mistral
13:09:58 <yanyanhu> if so, maybe maintaining the workflow in mistral is better choice, for it is the service for 'workflow' management :)
13:10:07 <Qiming> it seems reasonable to manage those workflows in senlin, however it doesn't make a lot senses
13:10:43 <lixinhui_> ok
13:10:54 <Qiming> if possible, maybe we can have a /contrib directory and get the worflow abstracted there
13:11:04 <yanyanhu> good idea
13:11:11 <yanyanhu> as examples for users
13:11:21 <elynn> contrib +1
13:11:27 <lixinhui_> :)
13:11:27 <Qiming> then we discuss whether we want to keep just a reference to the mistral work flow or we keep the whole workflow definition
13:11:56 <lixinhui_> what is the reference idea?
13:12:01 <Qiming> making decision without checking the code would be difference
13:12:10 <lixinhui_> I think they are python files and yaml...
13:12:24 <yanyanhu> make senses. With that, we can better tell whether holding those workflows inside senlin makes sense
13:12:31 <Qiming> user create a workflow in mistral, we reference it and trigger it when evaluating the health policy
13:12:56 <lixinhui_> for example
13:13:09 <Qiming> if needed, we can provide inputs and grab outputs from those workflows
13:13:11 <lixinhui_> how for users to know how many flows they can choose
13:13:21 <lixinhui_> yes
13:13:23 <lixinhui_> Qiming
13:13:38 <lixinhui_> that is what we may need do
13:13:45 <lixinhui_> I mean
13:14:03 <lixinhui_> to grab recover related flows and list them in senlin
13:14:08 <Qiming> if we provide those choices to users thru senlin, senlin becomes a proxy of mistral, it buys user nothing other than overhead
13:14:19 <lixinhui_> not really
13:14:28 <Qiming> the workflow is supposed to be created by the same user
13:14:37 <lixinhui_> please think from the perspective that senlin acts as cluster manager
13:14:59 <lixinhui_> user will wanna to know what kinds of choice we provide for the cluster recover
13:15:01 <Qiming> just a quick thought, there are many other alternatives
13:15:15 <lixinhui_> and do not wanna to jump out and use other tools
13:15:25 <Qiming> if a workflow-centric solution makes more sense, I'm fine with it
13:15:40 <Qiming> it means we don't need to provide any additional support to this
13:15:48 <Qiming> by we, I mean senlin engine
13:16:15 <Qiming> using openstack is about using a collection of tools
13:16:50 <Qiming> all those tools are exposed thru horizon (the single web UI) or the openstackclient (the sole command line interface)
13:17:02 <Qiming> you cannot say you are jumping from one tool to another
13:17:03 <lixinhui_> if we wanna sell it, the story may be need more useful experience
13:17:16 <lixinhui_> anyway
13:17:19 <yanyanhu> lixinhui_, +1
13:17:31 <yanyanhu> I think we need more investigation result to help us to make the decision
13:17:45 <lixinhui_> yes
13:17:47 <lixinhui_> yanyanhu
13:17:54 <Qiming> users don't care it is mistral or senlin or whatever
13:18:18 <lixinhui_> that is the reason why they wanna good entry point
13:18:20 <lixinhui_> :)
13:18:40 <Qiming> the community is not there yet, but I think that is the right direction
13:18:41 <lixinhui_> I will investigate more then return here for more discussion
13:18:50 <yanyanhu> great
13:18:51 <lixinhui_> agree, Qiming
13:19:04 <yanyanhu> will wait for it, then lets have further discussion on it
13:19:18 <lixinhui_> :)
13:19:37 <yanyanhu> ok, lets move on?
13:19:46 <lixinhui_> yes, please
13:20:07 <yanyanhu> Document, no new work here?
13:20:21 <yanyanhu> versioned request
13:20:32 <yanyanhu> it is in good progress I think
13:20:42 <yanyanhu> cluster support has been done by Qiming I think
13:20:55 <yanyanhu> and node support has been done as well
13:21:10 <yanyanhu> I'm now working on receiver, Ruijie is working on policy and lvdongbing is working on profile?
13:21:18 <Qiming> claim: I'm moving away from that work now
13:21:25 <yanyanhu> just noticed lvdongbing proposed the patch for versioned request support for profile :)
13:21:35 <Qiming> guys pls feel free to pick up any other resources/apis to work
13:21:42 <yanyanhu> Qiming, thanks a lot for that concrete basement u built for this job :)
13:21:46 <yanyanhu> sure
13:21:46 <XueFeng> OK
13:22:23 <yanyanhu> hope we can finish it soon since that's the prerequisite of other refactoring/new features
13:22:50 <Qiming> looking forward, I'm hoping we can rework the common.schema module, use versioned object to define profiles and policies
13:23:01 <Qiming> then we get free versioning support
13:23:16 <yanyanhu> Qiming, yes, that should be managed using versioned obj as well
13:23:21 <Qiming> and we unify all those schemas under json schema
13:23:27 <yanyanhu> yep
13:24:17 <yanyanhu> BTW, guys, plz add an item into etherpad with your name followed before starting work on support for some resources
13:24:33 <yanyanhu> it will be helpful to avoid conflict and duplicated effort
13:25:02 <yanyanhu> ok, next one
13:25:07 <yanyanhu> container profile
13:25:14 <yanyanhu> hi, haiwei_
13:25:17 <yanyanhu> any new progress?
13:25:31 <Qiming> seems patch 368539 will never make its way in
13:26:06 <yanyanhu> https://review.openstack.org/#/c/368539/
13:26:07 <yanyanhu> this one
13:26:12 <Qiming> at the same time, https://review.openstack.org/#/c/394896/ is coming in to remove the dependency
13:26:33 <Qiming> we discussed about this on at Barcelona
13:26:34 <haiwei_> yanyanhu, just made a patch to remove container node infor from cluster dependents as we discussed in the summit
13:26:48 <yanyanhu> haiwei_, ok
13:27:25 <Qiming> the correct dependency is: cluster <-------- profile <--------- container cluster/node
13:27:59 <Qiming> the second dependency is already enforced, but the first one is not yet
13:28:15 <haiwei_> yes, I am doing it that way
13:28:23 <Qiming> we can still delete a cluster even if it is referenced by a (container) profile
13:28:39 <haiwei_> patch 368539 will be modified or abandon
13:28:51 <Qiming> okay
13:28:59 <Qiming> we can reuse the same db schema
13:29:08 <yanyanhu> great
13:30:03 <XueFeng> Will read and study this
13:30:10 <Qiming> just that cluster1.dependents['profile'] == a_container_profile now
13:30:34 <yanyanhu> I see
13:30:39 <Qiming> that dependency is created when the container profile is created
13:31:13 <Qiming> cluster1.dependents can still contain other dependencies later ...
13:31:17 <haiwei_> you mean we should input container profile type into 'dependents' of cluster? qiming
13:31:24 <Qiming> profile id
13:31:39 <haiwei_> ok
13:31:53 <Qiming> when no profile object is created, the dependency doesn't exists
13:32:20 <yanyanhu> cool, will help to review the patch as well
13:32:38 <haiwei_> I will do this soon
13:32:44 <yanyanhu> haiwei_, thanks :)
13:32:54 <yanyanhu> ok, next one?
13:33:09 <yanyanhu> zaqar message receiver
13:33:24 <yanyanhu> after sdk 0.9.9 was released, everything is ready now
13:33:39 <yanyanhu> and the integration test for message receiver works as well
13:33:58 <yanyanhu> (although it is broken now for zaqar-ui installation problem at gate side...)
13:34:07 <yanyanhu> but that is not our fault
13:34:14 <Qiming> cool
13:34:17 <yanyanhu> will propose patch to project-config to fix it
13:34:33 <Qiming> so the zaqar receiver item can be completely removed from etherpad?
13:34:41 <yanyanhu> Qiming, yes, I think so
13:34:44 <yanyanhu> will remove it
13:35:02 <yanyanhu> maybe some more works will be done in future, but the basic workflow is ok now
13:35:19 <Qiming> already removed, \o/, I like the feeling of deleting things
13:35:28 <yanyanhu> thanks :)
13:35:30 <yanyanhu> hah
13:35:37 <yanyanhu> ok, next one
13:35:41 <yanyanhu> event/notification
13:35:51 <yanyanhu> Qiming, your turn?
13:36:11 <Qiming> okay, just added link to blueprint
13:36:19 <Qiming> which needs review and approval
13:36:31 <yanyanhu> great
13:36:39 <Qiming> and drafted a spec today, eyes needed for review
13:36:46 <yanyanhu> sure
13:37:01 <yanyanhu> guys, please help to take a look at it and leave your comments :)
13:37:19 <lvdongbing> ok :)
13:37:20 <Qiming> would rather not waste time in meeting to go through the idea
13:37:28 <Qiming> it all in the wine
13:37:34 <yanyanhu> Qiming, sure, will discuss it offline
13:37:37 <yanyanhu> :)
13:37:38 <elynn> great
13:37:46 <yanyanhu> ok, next one. batch policy
13:37:56 <yanyanhu> I think it has been done by Ruijie ?
13:38:12 <Ruijie> no really yanyanhu
13:38:19 <yanyanhu> ok
13:38:20 <Ruijie> it just support cluster delete and update
13:38:28 <Ruijie> want to add support to more actions
13:38:34 <yanyanhu> Ruijie, nice
13:38:50 <yanyanhu> so lets leave it there
13:39:09 <Ruijie> okay, will resume it after versioned resource support
13:39:29 <yanyanhu> Ruijie, great, and thanks for the hands on versioned req :)
13:39:34 <yanyanhu> and also lvdongbing as well
13:39:45 <yanyanhu> ok, nextone
13:39:56 <yanyanhu> NFV support/baremetal cluster
13:40:08 <yanyanhu> I guess this job has not been started yet?
13:40:20 <yanyanhu> we just got some requirement for it in summit
13:40:52 <Qiming> tacker side, haiwe has proposed a spec for review
13:40:55 <yanyanhu> Qiming, so some guys from huawei have plan to work on it?
13:41:10 <Qiming> yes, haven't seen any activity yet
13:41:11 <yanyanhu> Qiming, yes, saw those update on spec at tacker side
13:41:26 <yanyanhu> Qiming, I see
13:41:34 <Qiming> it is meghaa..f.a.swar ?
13:41:42 <yanyanhu> :P
13:41:46 <Qiming> cannot spell that project name
13:41:48 <Qiming> sorry
13:41:48 <yanyanhu> difficult to spell
13:41:49 <elynn> ...
13:42:09 <yanyanhu> ok, lets focus on the spec proposal to tacker now
13:42:21 <Qiming> meghdwar
13:42:40 <haiwei_> what is that?
13:43:13 <Qiming> https://wiki.openstack.org/wiki/Meghdwar
13:43:16 <elynn> I'm also curious what is that ...
13:43:31 <Qiming> edge cloud gateway
13:44:00 <yanyanhu> will read that wiki as well...
13:44:02 <elynn> Still has no idea...
13:44:32 <yanyanhu> :)
13:44:55 <yanyanhu> because we are lack of knowledge about NFV I think
13:45:08 <yanyanhu> anyway, hope there will be more progress on it in future
13:45:20 <yanyanhu> ok, those are all work items in the etherpad
13:45:40 <Qiming> that wiki contains a lot info
13:45:59 <yanyanhu> yep
13:46:04 <Qiming> including a paste of irc log ...
13:46:06 <XueFeng> Will research it
13:46:19 <yanyanhu> maybe it is a good start point to understand the entire background
13:46:26 <yanyanhu> me too :)
13:46:38 <yanyanhu> oh, elynn, XueFeng, you guys are working on lock recently?
13:46:55 <elynn> I will try to add db api
13:47:02 <yanyanhu> elynn, ok
13:47:17 <yanyanhu> then we can enhance the lock cleaning logic
13:47:33 <XueFeng> Need reconsider my patch
13:47:41 <yanyanhu> XueFeng, I think that will be helpful to address those lock issues we met :)
13:47:50 <Qiming> elynn, that db api can be called when a service is started ...
13:47:52 <yanyanhu> XueFeng, thanks a lot for bring this issue up
13:47:59 <yanyanhu> we do need more thinking on it
13:48:14 <elynn> Qiming: yes, then will add more codes :)
13:48:29 <yanyanhu> elynn, great. will help to review the patch
13:48:59 <Qiming> elynn, I mean here: http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/service.py#n203
13:49:06 <elynn> Not sure doing cleanse on engine start is ok or not .
13:49:15 <Qiming> line 212
13:49:22 <elynn> Might bring race codition.
13:49:47 <elynn> Since normally we will start multi workers.
13:49:51 <Qiming> things are still ramping up, it is a good chance to clean the room before moving in
13:50:28 <elynn> And each worker will do this.
13:50:42 <yanyanhu> do we need extra lock here?
13:50:50 <yanyanhu> for avoid this race condition?
13:50:55 <Qiming> I don't think each worker will do this
13:51:08 <Qiming> at least we can do it before we start the RPC server
13:51:09 <elynn> yes, might, but need more discuss about it.
13:51:37 <yanyanhu> ok
13:51:53 <Qiming> ok
13:51:59 <yanyanhu> maybe after the patch is proposed, we can have further discussion based on it
13:52:26 <yanyanhu> ok, open discussion
13:52:32 <yanyanhu> #topic open discussion
13:52:42 <yanyanhu> any more topics you guys want to talk about?
13:53:25 <yanyanhu> if no, maybe we can finish the meeting a little earlier
13:53:34 <Qiming> one thing
13:53:48 <Qiming> I checked the RDO packaging thing
13:54:18 <Qiming> it seems https://review.rdoproject.org/ has all of it
13:54:44 <Qiming> still no clue how to start it if we want to push senlin into RDO
13:55:06 <yanyanhu> so this is a gerrit maintained by rdo team?
13:55:11 <Qiming> yes
13:55:16 <Qiming> seems so
13:55:25 <yanyanhu> and we need to propose patch to it if we want to add senlin to it, e.g.
13:55:27 <Qiming> there is a #rdo channel, where we can ask questions
13:55:28 <yanyanhu> I see
13:55:35 <yanyanhu> ok
13:56:03 <yanyanhu> I checked the latest release of rdo(Newton), senlin is still not there
13:56:22 <Qiming> it is not replicated into rdo repo
13:56:44 <yanyanhu> yes
13:56:46 <Qiming> some people got to propose it and promise to maintain it
13:57:01 <yanyanhu> I see
13:57:06 <yanyanhu> that is reasonable
13:57:16 <yanyanhu> like each package in debian has its maintainer
13:58:14 <Qiming> just some info collected recently
13:58:30 <yanyanhu> ok, maybe lets keep paying some attention on it
13:58:36 <Qiming> we will need to learn more when we get the request
13:58:53 <yanyanhu> yes
13:59:04 <Qiming> would be good we have a focal from core team to keep an eye on this
13:59:31 <Qiming> no more from me
13:59:53 <yanyanhu> great, thanks for all those info, Qiming
14:00:01 <yanyanhu> will keep looking at it
14:00:04 <yanyanhu> time is over
14:00:09 <yanyanhu> thanks for joining the meeting
14:00:14 <yanyanhu> lets move back to senlin channel
14:00:17 <yanyanhu> #endmeeting