13:02:06 <Qiming> #startmeeting senlin 13:02:07 <openstack> Meeting started Tue May 24 13:02:06 2016 UTC and is due to finish in 60 minutes. The chair is Qiming. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:02:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:02:11 <openstack> The meeting name has been set to 'senlin' 13:02:19 <Qiming> had to try again 13:02:23 <elynn> o/ 13:02:26 <Qiming> seems some networking problem 13:02:30 <Qiming> hi, elynn 13:02:31 <yanyanhu> hi 13:02:33 <Qiming> hi 13:02:34 <elynn> sorry a little late 13:02:41 <Qiming> not at all 13:03:03 <Qiming> I don't have outstanding issues for discussion today 13:03:14 <Qiming> if you have some, please update the meeting agenda 13:03:21 <Qiming> #link https://wiki.openstack.org/wiki/Meetings/SenlinAgenda 13:03:46 <Qiming> #topic newton work items 13:04:09 <Qiming> testing 13:04:35 <elynn> only event show and api show are needed. 13:05:11 <Qiming> you mean the other API tests are all done? 13:05:16 <elynn> I think 13:05:21 <yanyanhu> patches have been proposed for these two cases. And elynn has started working on negative cases 13:05:28 <elynn> Except for negative tests 13:05:38 <Qiming> great 13:05:58 <elynn> Saw your comment on event show 13:06:02 <elynn> patch 13:06:12 <Qiming> have tests in tree can help us ensure that the api changes are reflected into the tempest test cases soon, if any 13:06:33 <elynn> https://review.openstack.org/#/c/320227/1/senlin/tests/tempest/api/events/test_event_show.py 13:06:36 <Qiming> yes, don't think cls.event is necessary 13:07:10 <elynn> If put these lines in to test_show_event() 13:07:26 <elynn> In this test will contain 2 API access 13:08:24 <Qiming> emm, right 13:08:30 <elynn> one for event list and one for event show. just for remind. 13:08:41 <Qiming> another workaround is to set limit=1 when doing listing 13:09:12 <elynn> hmm, that's a good idea 13:09:29 <Qiming> the reason is that we only allow specifying event_id for event_show 13:09:50 <Qiming> gate patch is still pending review, right? 13:09:58 <elynn> Yes... 13:10:10 <elynn> I rebase it today, to get it on top~ 13:10:12 <yanyanhu> looks like a lot of patches are pending 13:10:16 <yanyanhu> for lack of workflow 13:10:17 <Qiming> em, may be time to ping the reviewers 13:10:23 <elynn> But still no progress. 13:10:46 <Qiming> it's been there for a while now 13:10:52 <elynn> Okay 13:10:57 <Qiming> and we'd better turn it on 13:11:04 <elynn> I will reach them after meeting. 13:11:11 <Qiming> thx 13:11:17 <Qiming> Rally test ? 13:11:21 <yanyanhu> https://review.openstack.org/318453 13:11:24 <yanyanhu> also pending there 13:11:36 <yanyanhu> this patch tries to add senlin support to rally-gate 13:11:56 <yanyanhu> after that, any changes related to senlin in rally project can be verified 13:12:39 <Qiming> the other one has been hanging for over 40 days 13:12:49 <yanyanhu> it has been updated :) 13:12:50 <yanyanhu> https://review.openstack.org/301522 13:12:54 <yanyanhu> and ready for review now 13:13:27 <elynn> Which channel should I use to find the right guy to review? Qiming 13:13:29 <Qiming> also need to ping the rally team 13:13:41 <yanyanhu> yep 13:13:41 <Qiming> openstack-infra I think 13:14:04 <elynn> Thx 13:14:13 <yanyanhu> I guess the first step is merging the patch to add gate job 13:14:23 <Qiming> yes 13:14:30 <yanyanhu> then more plugins can be added 13:14:48 <Qiming> and we can manage those plugins by ourselves 13:15:00 <yanyanhu> yes, in senlin repo 13:15:06 <Qiming> okay 13:15:40 <Qiming> #action yanyan and elynn to push infra and rally gate reviews 13:16:04 <Qiming> health management 13:16:22 <Qiming> don't think I have got any feed back on the etherpad 13:16:57 <lixinhui_> this topic is indeed complicated 13:16:59 <Qiming> I have started working on adding event listener to health manager 13:17:13 <yanyanhu> saw that patch you proposed 13:17:14 <Qiming> hi, lixinhui_ 13:17:20 <lixinhui_> I saw your patch 13:17:24 <lixinhui_> hi, Qiming 13:17:37 <lixinhui_> fencing agent works now 13:17:47 <Qiming> the patch is about reorg the functions so that an event listener can be squeezed in 13:17:48 <lixinhui_> just can not keep long run 13:17:54 <yanyanhu> yes, it looks good 13:18:16 <Qiming> fencing agent will crash? 13:18:24 <lixinhui_> just stop response 13:18:36 <Qiming> fencing agent should be just about some scripts 13:18:44 <lixinhui_> have to reload it 13:19:05 <lixinhui_> do not sure what will do? 13:19:21 <lixinhui_> will we install the agent into Senlin profile 13:19:22 <lixinhui_> ? 13:19:26 <Qiming> haven't touch that thing for 2 years now 13:19:37 <lixinhui_> me never :) 13:19:49 <Qiming> could be a new type of drivers I think 13:20:08 <lixinhui_> ? 13:20:19 <Qiming> it will always be some model specific IPMI calls or something alike 13:20:22 <lixinhui_> do you mean with some software intalling functions 13:21:05 <lixinhui_> what can be primary categories of model 13:21:39 <Qiming> I was looking at openipmi 13:21:45 <xuhaiwei_> do you want to do something keeping pinging the vms? 13:21:53 <Qiming> there are many other vendor specific interfaces I think 13:22:21 <Qiming> xuhaiwei_, hi 13:22:37 <xuhaiwei_> ping the vms to check if it is alive? 13:22:42 <xuhaiwei_> yes, Qiming 13:23:10 <lixinhui_> no, that is detection part 13:23:10 <Qiming> xuhaiwei_, it is doable, but cannot be sure: 1) the VMs have not blocked ICMP traffic, 2) cannot be sure the VM is dead if ping fails 13:23:31 <Qiming> xinhui and I were talking about fencing 13:23:56 <Qiming> the term is called STONITH -- Shoot The Other Node In The Head 13:24:02 <xuhaiwei_> oh, it seems tacker has a feature of pinging vms 13:24:17 <xuhaiwei_> not very sure what you are talking about 13:24:42 <Qiming> ping is one way, but event if a ping fails, you cannot declare that VM is dead 13:24:44 <lixinhui_> xuhaiwei_ are you investigating Taker these days? 13:25:16 <xuhaiwei_> yes, lixinhui_, just installed it, don't know much about tacker 13:25:16 <lixinhui_> s/Taker/tacker 13:25:21 <Qiming> I think he is investigating the integration of tacker and senlin? 13:25:31 <xuhaiwei_> yes, Qiming 13:26:01 <Qiming> great, I should help them, if they allow us to do that 13:26:04 <xuhaiwei_> In fact I am investigating nfv need for tacker more 13:26:28 <Qiming> okay 13:26:41 <xuhaiwei_> about auto-scaling feature in tacker, they seems not interested in senlin 13:26:42 <lixinhui_> will NEC provide any SDN controller? 13:26:53 <Qiming> two features needed from tacker side is HA and AutoScaling 13:26:59 <lixinhui_> as backend of tacker? 13:27:15 <xuhaiwei_> no definite task from my boss currently lixinhui_ 13:27:15 <Qiming> xuhaiwei_, they are not familiar with senlin 13:27:42 <Qiming> I left some comments to their specs 13:27:56 <lixinhui_> where are the specs 13:28:11 <xuhaiwei_> yes, I am not familiar with tacker too, need to investigate it and see if we can propose senile to them 13:28:21 <xuhaiwei_> I saw your comments 13:28:25 <Qiming> if they want to retry what we have failed, that is fine 13:28:43 <xuhaiwei_> the current Heat PTL is reviewing tacker much now? 13:28:44 <Qiming> in an open community, you cannot force others to do something they don't believe 13:29:08 <Qiming> xuhaiwei_, I don't think so 13:29:22 <xuhaiwei_> at least he is a heat core 13:29:30 <Qiming> it is a heat core from huawei 13:29:36 <xuhaiwei_> I can't remember his name 13:29:44 <xuhaiwei_> ok 13:30:10 <Qiming> kind of misleading the tacker team ... sigh 13:30:13 <Qiming> anyway 13:30:26 <Qiming> documentation 13:30:44 <Qiming> resumed my work on adding tutorials 13:31:03 <Qiming> need to add a simple guide on how to achieve auto-scaling with and without heat 13:31:31 <Qiming> and some simple tutorial on exercising the policies 13:31:45 <Qiming> API documentation was cleansed 13:31:52 <Qiming> it was a tedious work ... 13:32:11 <Qiming> every single parameter has to be reviewed several times 13:32:25 <Qiming> hope it is done this time 13:32:42 <Qiming> container support 13:32:55 <Qiming> xuhaiwei_, reviewed your patch 13:33:05 <xuhaiwei_> thanks 13:33:10 <Qiming> I think we are touching some implementation details in the review 13:33:43 <Qiming> for example, a container cluster should memorize the 'hosting nodes' for each container 13:33:48 <xuhaiwei_> since we got an agreement on adding a new property 'host' to Node api, I will start to implement it soon 13:33:56 <Qiming> yes, that is true, we can decide where to put this data later 13:34:05 <Qiming> it can be a policy data, can be a cluster data 13:34:17 <Qiming> but we don't have to worry about it 13:34:43 <Qiming> em... 13:35:06 <xuhaiwei_> ok, I was not sure whether we needed to add a similar property to Cluster api 13:35:22 <xuhaiwei_> it seems not now 13:35:24 <Qiming> I'm more worried about the placement policy implementation 13:35:45 <Qiming> xuhaiwei_, that can be driven by requests 13:36:12 <Qiming> speaking of extending the node-create api so that the 'host' can be specified, that would be useful 13:36:50 <Qiming> I was also thinking about adding a --profile parameter to the cluster-scale-out call, so that new nodes added can use a different profile 13:37:01 <Qiming> it is for the use case of rolling upgrade 13:37:08 <xuhaiwei_> the placement policy implementation depends on the existing nodes, but the current nodes are not a definite thing 13:37:35 <Qiming> what do you mean by "not a definite thing"? 13:38:09 <xuhaiwei_> I mean the vm cluster which will host the container cluster is not definite 13:38:33 <Qiming> then we have the policy to handle that 13:38:39 <xuhaiwei_> in placement policy we need to get the vm nodes information first 13:38:52 <Qiming> yes 13:39:11 <Qiming> each time you do a placement decision, you will get all the nodes 13:39:28 <Qiming> among which, there could be some nodes newly added 13:39:31 <xuhaiwei_> yes 13:40:00 <Qiming> those are things you will keep in mind when developing the policy, they are not blockers, right? 13:40:37 <xuhaiwei_> a little complicated but not very difficult I think 13:40:50 <Qiming> right 13:41:11 <Qiming> okay, looking forward to your patches 13:41:18 <Qiming> engine improvement 13:41:25 <xuhaiwei_> ok 13:41:30 <Qiming> batch control is done, removing line 34 now 13:42:22 <Qiming> as for line 33, NODE_CREATE, NODE_DELETE, I'm thinking of translating NODE_CREATE to CLUSTER_SCALE_OUT if cluster parameter is specified 13:43:02 <Qiming> in that way, all cluster policies that can handle CLUSTER_SCALE_OUT action will automatically apply on the NODE_CREATE request 13:43:45 <Qiming> just a rough idea, haven't got time to think through yet 13:44:07 <lixinhui_> sounds reasonable 13:44:11 <Qiming> a brutal way is to remove --cluster from node-create call 13:44:47 <Qiming> but this is really a big hole we have to fix asap 13:45:10 <Qiming> or else, node-create calls can skip all policy checks ... 13:45:48 <Qiming> please find me on IRC if you have any suggestions on this 13:46:07 <Qiming> receiver of zaqar, no one is onto yet I believe 13:46:25 <Qiming> notifications 13:46:47 <Qiming> em, I read the versioned notification api spec in nova 13:47:12 <Qiming> no matter we will do the same thing or not, that spec is a good writeup 13:47:32 <Qiming> so, I have added a starting point for versioned objects 13:48:16 <Qiming> as I have noted in the commit message: oslo.versionedobjects will help serve two use cases -- live upgrade of senlin service; versioned notification 13:48:18 <xuhaiwei_> a versioned notification api? 13:48:31 <Qiming> yes, notification should be versioned 13:48:49 <Qiming> we need to control what senlin is saying to other services when it speaks 13:49:08 <xuhaiwei_> control what? 13:49:13 <Qiming> all contents should be predictable 13:49:33 <xuhaiwei_> ohh 13:49:41 <Qiming> say, if senlin wants to post a message into zaqar or oslo.notification when a cluster is scaled out 13:49:59 <Qiming> there needs a spec for the message payload 13:50:42 <Qiming> so the receiver can always expect that there will be a 'nodes' key which is a list of new nodes added, ... 13:51:07 <Qiming> we cannot assume that we will never change the content 13:51:23 <Qiming> so at the very beginning, we will do version control for this 13:51:49 <Qiming> thanks god, we are a new service, we don't have to do a lot backward compatibility things 13:52:13 <Qiming> we learned a lot from lessons in other services 13:52:32 <xuhaiwei_> yes 13:52:32 <Qiming> anyone can jump in to that thread if interested 13:53:08 <Qiming> we may need to revised the db schema for this purpose 13:53:27 <Qiming> add a new multi-string option: "event_backend" 13:54:05 <Qiming> then the same event api can be used to save records into db or post messages to queue or BOTH ... 13:54:25 <Qiming> #topic open discussion 13:54:51 <lixinhui_> https://review.openstack.org/#/c/318577/1/specs/newton/manual-and-auto-scaling.rst 13:55:25 <lixinhui_> is the link referred to the mentioned tacker AS discussion? 13:56:12 <Qiming> that is one of them 13:56:46 <elynn> Maybe we can propose a spec based on senlin? 13:56:46 <Qiming> also this one: https://review.openstack.org/#/c/306562/ 13:56:59 <Qiming> elynn, we want to help 13:57:21 <Qiming> but someone else should sign on get the job done 13:59:10 <Qiming> anything else? 13:59:14 <Qiming> time is up 13:59:18 <xuhaiwei_> no 13:59:29 <lixinhui_> no 13:59:42 <Qiming> thanks guys, already very late, good night 13:59:48 <Qiming> #endmeeting