13:01:54 #startmeeting senlin 13:01:55 Meeting started Tue Feb 23 13:01:54 2016 UTC and is due to finish in 60 minutes. The chair is Qiming. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:58 The meeting name has been set to 'senlin' 13:02:38 a little bit earlier 13:02:49 o/ 13:02:53 hi 13:03:03 little bit late, you mean? 13:03:04 9:04 on my laptop :) 13:03:28 looks my local time need refresh :) 13:03:38 was trapped by the policy doc thing I'm working on 13:04:34 pls check agenda and see if you have things to add 13:05:02 first things first, let's run the work item etherpad 13:05:12 #link https://etherpad.openstack.org/p/senlin-mitaka-workitems 13:05:40 api side, I'm not aware of any high priority bugs/fixes 13:06:07 I'd suggest we move advanced 'filters' back to TODO list 13:06:32 agree 13:06:47 the reason is ... 13:06:51 it's a work with lower priority 13:06:59 it is very complicated ... see: http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering 13:07:20 consider: GET /app/items?size=gt:8 13:07:29 GET /app/items?foo=in:buzz,bar 13:08:13 heat resource type 13:08:19 yes 13:08:33 only one resource left. 13:08:36 OS::Senlin::Node 13:09:16 I update it according to reviews 13:09:29 there is not serious problems as I see it in the code 13:09:34 just one thing 13:09:47 do we want to expose a node to be created with cluster specified? 13:10:02 the final answer to that would be YES 13:10:16 do we want to support that right now? 13:10:23 I'm not sure, to be honest 13:10:50 haven't got bandwidth to deal with the NODE_CREATE problem 13:11:10 What's the problem with node_create? 13:11:14 i.e. item listed on line 45 13:11:31 when you are creating a new node INTO a cluster 13:11:45 you will respect all policies attached to that cluster 13:11:47 elynn_, policy check I think 13:12:00 say, region placement, zone placement, load-balancing, ... 13:12:44 the same applies to NODE_DELETE 13:12:45 Do I need to hide the property in heat resource? 13:13:02 I'd suggest so 13:13:46 speaking of Heat resource types, I don't see a strong use case to create an out-of-band node into a cluster, via a template 13:14:07 So for now we don't support attach a node to cluster? 13:14:28 that is the question 13:14:38 Qiming: Yes, it's not that necessary to create a node from template. 13:14:52 Qiming: I mean in heat. 13:14:54 we do support cluster-add-nodes 13:15:12 we are checking that action in our policies 13:15:41 but we never checked NODE_CREATE, NODE_DELETE 13:16:14 ok... That would make codes of node resource more complicate. 13:16:28 so .. I'd suggest we hide 'cluster' property of nodes 13:16:53 at least for now 13:17:13 Qiming: ok, I will hide it in next patchset. 13:17:15 it can be left as an attribute 13:17:31 also, node details should be left as an attribute 13:18:43 ok 13:18:46 is there a problem if we have 'cluster' as an attribute of Node and in future we add it as a property? 13:20:08 a practical goal for mitaka is to have the basic cluster/node/policy/profile concepts demonstrated in a template 13:20:10 Qiming: I don't think so, since we can say that cluster attr is ID of cluster while cluster property could be name. 13:20:11 that is enough 13:20:34 fair point 13:20:43 moving on, testing 13:20:55 have we started stress testing? 13:21:00 no yet 13:21:05 just have some basic idea 13:21:29 may need further discussion with xinhui and brian 13:21:39 need to fork this work thread soon so that branw can work on it 13:21:46 yes 13:22:00 will try to setup a discussion with them this week 13:22:14 more functional tests for cluster/node coming in? or we can delete line 16? 13:22:24 cool, yanyanhu 13:22:28 still need to add a test case for cluster update 13:22:36 okay 13:22:38 other parts have been done I think 13:22:59 I'm removing the senlinclient unit test line 13:23:09 ok 13:23:24 health management/policy ? 13:23:38 I have submit the patch 13:23:39 https://review.openstack.org/#/c/282299/ 13:24:01 collect comments 13:24:15 I will change accordingly 13:24:29 ah, I reviewed, but haven't written comments 13:24:37 :( 13:24:45 the general feeling is that the patch is still a half-baked solution 13:24:54 en 13:24:59 it is dangerous if we are moving along this way 13:25:27 it may induce a lot of overheads if we are checking every single cluster and try to recover them 13:26:01 I'd suggest we only care about clusters that are somehow 'registered' for this kind of checking/recovery 13:26:06 a candidate way to check only the clusters attached with health policy 13:26:27 the best way I can think of is to see if they have a health policy attached AND enabled 13:26:42 yes 13:27:05 but not sure what priority with health policy 13:27:13 so a health policy, when being attached to a cluster, will "register" that cluster for health management 13:28:06 okay 13:28:07 a health policy is triggered by timer events, not actions 13:28:21 so 'priority' may be not relevant 13:28:55 we can have a simple, naive version of health policy to drive this 13:29:23 okay 13:29:33 cluster/node check/recover apis all done? 13:29:36 could you give some example on timer events? 13:29:50 yes, they all be done 13:30:09 once the client patch got into, I will add doc accordingly 13:30:23 can be triggered by crond, for example, or timer event from ceilometer, 13:30:36 and saw Yantanhu has helped to write the functional tests :) 13:30:45 can be invoked from within senlin engine, from a perioc_task 13:30:51 lixinhui, yes :) 13:30:56 those API are available now 13:31:13 okay 13:31:19 I will try 13:31:20 how about the SDK side, I think we have them all merged? 13:31:27 Yes 13:31:28 great, thanks!! 13:31:49 moving on 13:31:52 documentation 13:31:53 One thing I also tried in the past week 13:32:03 okay? 13:32:06 is about neutron member health status 13:32:12 LB based? 13:32:18 Yes 13:32:34 I still do not give up to get status trigged recover 13:32:47 please don't 13:32:49 :) 13:32:53 oh 13:33:19 I mean, please don't give up 13:33:20 weekly meeting is very important :) 13:33:47 but found a bug that member status can be updated 13:33:52 by healthmonitor in V@ 13:34:00 inv2 13:34:05 lixinhui, hope can have some time to work on healthmonitor support in lb policy in coming week 13:34:09 can or cannot? 13:34:13 s/can/cann' 13:34:18 s/can/cann't 13:34:25 could be some config problem? 13:34:50 status of lb pool_member? 13:34:54 great yanyanhu! I know your work efforts already very heavy 13:35:11 I tried but think not config issue 13:35:19 lixinhui, no problem, just being trapped in some other stuff :) 13:35:26 okay, let's wait for feedback from neutron team 13:35:52 okay, will not give up 13:36:18 cool 13:36:50 documentation side, I've started drafting something, hopefully they will serve a summary or design doc 13:36:54 http://docs-draft.openstack.org/58/283558/2/check/gate-senlin-docs/b75599a//doc/build/html/developer/index.html 13:37:11 you will see the Built-in Policy Types section 13:37:36 just commited a patch about deletion policy 13:37:49 great job! 13:37:52 link is here: http://docs-draft.openstack.org/58/283558/2/check/gate-senlin-docs/b75599a//doc/build/html/developer/policies/deletion_v1.html 13:38:40 writing docs really helps clear my mind 13:39:01 will continue working on that 13:39:04 :) 13:39:11 zan 13:39:24 I'm finding quite some bugs when writing the doc and reread the code 13:40:03 will do that too 13:40:27 don't think we have any progress in other areas listed in the etherpad 13:40:54 yes, I'm afraid that's true... 13:41:06 oh, about the resource property renaming in sdk, have all related patches been merged yet? 13:41:12 we did something that are not listed on the page, :) 13:41:17 do we need to prepare rework our driver? 13:41:25 yanyanhu, not yet 13:41:29 Qiming, yep :) 13:41:38 ok 13:41:46 still some patches coming in 13:41:48 will wait for new release of sdk 13:42:51 Richard is working on message service 13:43:05 zaqar? 13:43:12 when will it be possibly? 13:43:27 seems so 13:43:53 oh, I forgot that '-2' is sticky 13:44:09 which -2? 13:44:14 I was surprised to see Yanyan's patch still has a -2 13:44:35 ah 13:44:36 that one 13:44:46 I guess terry hasn't got time to watch it :) 13:45:06 okay, that is one of the SDK issues we need to deal with 13:45:10 we really need that workaround for pool_member resource creating 13:45:15 yes 13:45:25 yes 13:45:33 are you aware of others? 13:46:10 I think I have heard some complaints about ksa1, things not found, etc etc 13:46:10 no, as of now, only pool_member has this problem I think 13:46:28 ksa1? 13:46:36 keystoneauth1 13:46:43 oh 13:46:59 really need spend some time to understand it 13:47:06 okay 13:47:14 as you know, I'm trying to install Senlin in SV 13:47:18 which is a Juno env 13:47:20 cool 13:47:29 what is SV 13:47:31 that would be a very risky test, :) 13:47:32 ? 13:47:38 do meet some issues when access keystone service through sdk 13:47:43 yes 13:47:43 lixinhui, a power cloud 13:47:53 okay, Qiming 13:47:59 sdk 0.7.4 ? 13:48:00 especially about trust 13:48:01 yes 13:48:04 0.7.4 13:48:10 authentication is ok 13:48:39 good luck, boy 13:48:41 but exception happened during listing trust 13:48:45 thanks :) 13:48:48 hope so 13:49:08 lixinhui, any outstanding issues building the autoscaling poc? 13:49:32 so far good 13:49:52 I will ask for help once meet issues 13:49:57 you can point me to the ceilometer patch about lbaas v2 13:50:01 :) 13:50:10 I can help poke the ceilometer team on that 13:50:24 https://blueprints.launchpad.net/ceilometer/+spec/lbaas-v2-enablement 13:50:44 Qiming, the code works in my tests 13:50:55 you mean that patch? 13:50:57 cool 13:51:01 yes 13:51:06 ji zilian works on it :) 13:51:16 yes, yanyanhu :) 13:51:19 cool, the author has been working with us for quite a long time 13:51:21 really a good news for us 13:51:28 great!!! 13:51:40 RP is so good 13:51:46 oh, his BP 13:51:47 haha 13:52:05 feel free to speak up when there are questions 13:52:12 yep, he has worked on monitoring in openstack for a long time 13:52:22 okay! 13:52:36 #topic open discussion 13:52:57 I think you guys may need to prepare for the trip to Austin :) 13:52:59 ^ will be the first/last topic in the meeting minutes 13:53:19 especially the visa 13:53:22 trapped by several things these days 13:53:37 Are you all going to Austin? 13:53:42 flight connection is a headache, according to Deng Hui 13:53:56 :) 13:54:01 elynn_, we follow you 13:54:03 I did not reply to him 13:54:05 elynn_, myself is not sure 13:54:38 because I am still thinking the trip plan 13:54:41 I'm reading ttx's proposal on separating design summits out of the main conf 13:54:44 sigh ... 13:54:48 go to PA or not 13:55:16 if you are very active, it means you will need to justify four trips a year now 13:55:17 any decision about separating design summit? 13:55:54 don't know the outcome yet 13:56:33 I planned to repond to that proposal, but ... 13:56:38 bandwidth 13:56:54 right... 13:57:24 TBH, I don't get the idea of separating devs into a 'clean' room for pure tech discussions 13:57:59 somehow we are stepping away from users 13:58:01 sigh 13:58:26 anything else? 13:58:29 2 mins left 13:58:35 nope from me 13:58:46 nope from me 13:58:47 Israel openstack day 13:58:51 haiwei is in hospital I think 13:58:57 just hope can have more time to work on those items in etherpad 13:59:05 do you guuys feel interested? 13:59:06 oh? 13:59:10 lixinhui, going Israel? 13:59:11 is he ok? 13:59:22 hope so, yanyanhu 13:59:23 poor guy 13:59:32 What happend? 13:59:33 yes will send link to all of you 13:59:33 lixinhui, when is it? 13:59:41 lixinhui, thanks 13:59:47 to see if anything want to propose 13:59:49 lixinhui, al ways interested in any tech discussions 13:59:50 NP 13:59:55 the only problem is travel budget 13:59:59 :) 14:00:02 yes... 14:00:03 come to vmware 14:00:05 big headache 14:00:08 enough 14:00:09 thanks 14:00:13 haha 14:00:13 #endmeeting