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