13:00:21 #startmeeting senlin 13:00:22 Meeting started Tue Mar 7 13:00:21 2017 UTC and is due to finish in 60 minutes. The chair is Qiming. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:26 The meeting name has been set to 'senlin' 13:00:32 evening, morning 13:00:47 hi 13:00:54 hi,all 13:01:32 let's see who else is joining 13:01:40 I know yanyan is on biz trip 13:02:10 proposed meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Weekly_Senlin_.28Clustering.29_meeting 13:02:15 oh, so happy 13:02:20 pls feel free to add items 13:03:39 okay, maybe we can get started 13:03:45 #topic pike workitems 13:03:54 #link https://etherpad.openstack.org/p/senlin-pike-workitems 13:04:06 profile-only support 13:04:26 the sdk side and client side patchs are merged 13:04:39 however, we are still missing the api layer patch 13:04:43 that is ... weird 13:05:05 need check 13:05:39 oh, request objects have been changed 13:06:46 just the history.rst needs a change and we need to bump microversion to 1.6 to enable this 13:07:47 Yes , tow hongbing and guoshan cooperate to do this bp 13:08:04 alright, changed the work item to reflect the reality 13:08:24 ok 13:08:25 next item 13:08:32 feature rich nova server 13:08:38 maybe we can notice them to add history 13:08:58 Saw your comments 13:09:09 Sorry I haven't got time to update it. 13:09:17 last time we discussed working on nova server and vdu profile in parallel, maybe elynn_ still wants to fix vdu first 13:09:21 i'm fine with that 13:09:46 just want to let you know, I'm starting to look at server adoption 13:09:56 Yes, I would like to let vdu stable first 13:10:03 Then back port to nova profile 13:10:06 which means I'm gonna propose changes to nova server profile 13:10:14 Qiming,greate 13:10:25 okay... 13:10:34 so ... it may make your future back port a little difficult 13:10:37 When you do that, add me as reviewer 13:10:50 hopefully I'm not changing a lot of existing code 13:11:04 pls keep working on the vdu profile 13:11:15 I will update them this week 13:11:20 rumors said we have got the talk on this accepted 13:11:39 it means ... at least we have a preview version for people to try out 13:11:56 Haven't got any emails about the results yet. 13:11:56 On my side, still test VDU with vims 13:12:05 hi, xiao xin 13:12:06 some problems jum out 13:12:11 hi Qiming 13:12:30 not sure if it is caused by template or wrong attributes 13:12:48 the ims service can not serve normally as heat template did 13:12:57 will dig more to root cause the error 13:13:04 great we are making progress on this, ... 13:13:27 Maybe I should not swallow the jinja2 errors... 13:14:08 right, that 'pass' is masking out a lot of error conditions 13:14:32 The design now is when encounter attributes error raised by jinja2 , it will silently pass and use the un-replaced user_data instead. 13:14:56 em, that deserves a -1 13:16:09 I did that because if someone just want to use {{}} in their user_data, then senile won't raise errors... 13:16:52 I guest I worry too much... 13:16:53 failing silently is not good anyway 13:17:09 Will modify that 13:18:10 left a comment with a -1 as reminder, :) 13:18:21 more on this topic? 13:18:23 :) 13:18:50 moving on 13:18:53 engine improvement 13:19:18 cracking NODE_CHECK actions 13:19:32 yes, Qiming 13:19:41 not update 13:19:45 need review 13:19:55 I'm thinking if we should make this a little bit self managed 13:20:43 for NODE_CHECK, CLUSTER_CHECK actions originated/derived from health manager 13:21:02 we can label them as self destroyable 13:21:32 when we do action_mark_complete in database, the action delete itself 13:21:51 OK 13:22:00 I thought this before 13:22:05 for end users, actions not originated from client requests are strange 13:22:32 i was even thinking of other alternatives instead of forking actions 13:22:52 a little bit difficult ... 13:23:20 next thing is about server adoption, and maybe stack adoption 13:23:35 yes 13:23:37 current thought is to add a node-adopt api 13:23:52 implemented as a do_adopt() method in each profile type 13:24:23 the method carries a 'confirm=False' parameter and a 'snapshot=False' parameter 13:24:52 yes ,this is the base for adopt 13:24:59 which means by default, do_adopt will extract relevant properties from an exising server, filling a new profile spec using the property values 13:25:26 but ... since confirm is False, we don't create a new profile yet 13:25:40 since snapshot=False, we don't create a server snapshot yet 13:25:55 Ok 13:25:59 I got the idea 13:26:00 from client side, user must explicit specify confirm=True 13:26:11 then a new node will be created, with a new profile created 13:26:36 user can provide a dict to override the properties extracted from an existing server/stack 13:27:30 with confirm=False, user will always get a chance to "preview" what kind of a new profile senlin will create for him/her 13:28:11 a skeleton is ready, need some test cases to be added before submit for review 13:28:30 one thing I met is about networks 13:28:51 OK 13:28:51 which problem 13:29:00 from server properties extracted, it is really hard to determine whether the server should be created using network name, port id or fixed ip ... 13:29:16 the input and the output are different for network properties 13:29:34 that could be something we really need user's intervention 13:29:56 another problem is that I haven't find an api to get the admin password for a nova server 13:30:11 although we can specify it when creating one 13:30:58 just an update on the current progress, pls let me know if you have suggestions, on #senlin channel 13:31:06 moving on to next topic 13:31:18 RDO shipment 13:31:24 Ok 13:32:09 Add requirements in sepc and debug in centos 7 13:32:27 Not difficult 13:32:29 have you consulted RDO guys? 13:32:50 have not 13:33:04 Will ping them in #rdo 13:33:21 okay, feel free to ask questions, there is not many cannibals on earth today 13:33:38 thanks for driving this 13:33:49 Ok 13:33:58 My pleasure:) 13:34:05 alright, meeup in Nanjing 13:34:12 your input, XueFengLiu ? 13:34:33 Yes 13:34:48 thanks for drafting the tutorial, I'll spend some time reading it 13:34:51 There is a meetup in NanJing 2017,3,18 13:35:04 Ok 13:35:30 please also check my paper, it is a more comprehensive introduction from developer's perspective 13:35:35 On the meetup the first topic is about senlin:) 13:35:44 Will 13:36:18 I'll try my best to join you, but ... cannot promise a thing yet 13:36:44 I'm overcommitted ... 13:36:55 OK:) 13:37:12 next topic 13:37:15 health 13:37:25 I'm not aware of progress in this thread 13:37:44 If you can come, it will be more professional 13:38:02 :D 13:38:21 next is about senlinclient functional test 13:38:41 I think the gate is ready, we can start adding test cases now 13:39:04 That's good 13:39:30 We can distribute ti to team to help do this 13:39:39 s/ti/it 13:39:44 sure 13:39:56 policy improvement 13:40:05 :) 13:40:18 ruijie has been improving lb policy for CLUSTER_RECOVER action 13:40:46 yes, two patches for this 13:40:49 yes, but still need improvement 13:41:00 for parsing action data 13:41:10 okay 13:41:34 so far... for actions, we are not fully utilizing its "outputs" property 13:42:10 we have been heavily using its 'inputs' and 'data' property for input parameters and policy decisions respectively 13:42:36 It is used outer Senlin .. e.g. MQ message 13:42:38 I cannot recall whether LB policy is alreadying using action.outputs 13:43:10 we may want to make sure all actions record there results into 'outputs' 13:43:23 though we don't have a strong use case for it yet 13:43:50 it's just an option, ruijie_, you can still use action.data for LB improvement 13:44:14 it is not the only valid solution 13:44:24 Qiming, you mean dump the data to action.data but not action.outputs? 13:44:33 it depends 13:44:50 I mean for the LB policy 13:44:54 if the data you are dumping are more suitable to be treated as 'outputs', you can do it 13:45:03 What is the different about action.data and action.outputs 13:45:03 then in LB policy you will check it 13:45:39 action.data is designed for internal use, policies use action.data to pass information from one to another 13:46:01 Currently, we dump the data to outputs only if node_recover succeeded 13:46:02 action.outputs is about the final result from an action's execution 13:46:12 okay 13:46:14 that is fine 13:46:51 I was not saying it has to be done this way or that way 13:47:07 yes Qiming 13:47:22 okay, take your time on this, sir 13:47:35 :) 13:47:46 guess that's all about pike work items, 13:48:04 OK ,I see, if action finished, all policies also finished, then we can use "outputs" which is designed for final result 13:48:20 not really Xuefeng 13:48:31 looking ahead ... we are about to prioritize things we want to get done duing Pike 13:48:34 there is still an post_op be executed after the action 13:48:45 I've checked the blueprints 13:49:08 some are already approved, some need more clarifications 13:49:27 #topic pike goals 13:49:52 Yes, ruijie_ 13:50:02 my personal opinion on pike goals 13:50:35 container support, complete health support, usable VNF support 13:51:10 others may include node adoption 13:51:23 which has already started 13:51:37 Yes 13:51:53 a more dirty work is to rebase profile and policy schema onto versioned objects 13:52:11 then we have a better versioning support all profile/policy versions 13:52:13 Qiming, this is you personal things want to do or personal option? 13:52:25 my personal view 13:52:44 pls don't view them as all in my plate 13:52:51 I cannot eat that much 13:53:04 haha:) 13:53:08 Got it 13:53:19 I'm asking your suggestions 13:53:31 what do you think should we give a higher priority 13:53:59 if you don't have an answer right now, pls think about it and share with team later 13:54:16 Ok 13:54:25 adoption is high 13:54:44 others I will share later 13:55:03 In next weekly meeting 13:55:05 check TODO.rst and FEATURES.rst 13:55:26 need some tuning to those lists 13:55:34 Yes 13:55:34 And about https://blueprints.launchpad.net/senlin/+spec/cluster-lock-cluster-unlock 13:55:40 for example, api wg conformance is not a big issue now 13:55:52 we have been closely following their guidelines 13:56:06 need discuss wiht ruijie_ and Qiming 13:56:28 Which is senlin want for cluster-lokc-unlock 13:56:49 right, that blueprint needs some details 13:57:30 #topic open discussions 13:57:36 still a few minutes 13:57:39 My thought is mark it as ERROR or something before. 13:58:06 ERROR is a state you can recover from 13:58:22 I was thinking that a cluster is frozen 13:58:46 no more actions are accepted before an 'unfreeze' ... :) 13:58:53 Right Qiming, only recover action could make it alive again 13:59:18 how about adding your comment to the etherpad 13:59:33 sure Qiming 13:59:33 time's up, guys, thx for joining 13:59:37 ttyl 13:59:40 OK, will add more in that 13:59:41 #endmeeting