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