13:00:11 <Qiming> #startmeeting senlin
13:00:12 <openstack> Meeting started Tue Mar 21 13:00:11 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:15 <openstack> The meeting name has been set to 'senlin'
13:00:44 <yanyanhu> hi, evening
13:00:48 <Qiming> hi
13:00:51 <elynn> o/
13:00:56 <XueFeng> hi
13:01:28 <Qiming> agenda posted, please add if you have things to talk about
13:01:35 <Qiming> #link https://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Weekly_Senlin_.28Clustering.29_meeting
13:02:23 <Qiming> le'ts get started
13:02:30 <Qiming> #topic pike work items
13:02:41 <Qiming> #link https://etherpad.openstack.org/p/senlin-pike-workitems
13:03:02 <Qiming> api test for profile-only is in now
13:03:55 <Qiming> we need to revisit if all api changes since microversion 1.2 have been properly tested
13:04:01 <Qiming> so I'm leaving that item there
13:04:15 <Qiming> next, feature rich nova server
13:04:25 <elynn> no progress yet
13:04:32 <elynn> will try to start it this week
13:04:38 <Qiming> okay, sounds great
13:04:48 <elynn> As we talked before
13:04:49 <Qiming> we have some very limited versioning support today
13:05:11 <Qiming> in the long run, maybe we should replace the "schema" module with versioned objects
13:05:21 <elynn> I'm about to say I'm going to use versioned schema for it..
13:05:35 <Qiming> we may need to derive some subclasses from base VersionedObject for this purpose
13:05:41 <Qiming> cool
13:05:57 <elynn> But I haven't tested it yet...
13:06:12 <yanyanhu> hi, Qiming, so the member of the derived versioned object will still be versioned object?
13:06:34 <elynn> will spend some time on it
13:06:44 <Qiming> we don't have to do nested versioned objects
13:06:59 <yanyanhu> e.g. a versioned obj for nova server profile will be consist of a set of versioned object of image/net/storage, etc.
13:07:17 <Qiming> the goal is simple, make sure any changes of the spec would require a version bump
13:07:42 <yanyanhu> ok
13:07:51 <Qiming> if we manage nested objects, there will be two or more layers of objects to be managed in versions
13:07:56 <Qiming> too boring
13:08:20 <yanyanhu> yes, more than one layers of oversioned obj will be there if so
13:08:20 <Qiming> next, engine improvement, wrt CLUSTER_CHECK
13:08:41 <XueFeng> hi,QiMing
13:08:47 <Qiming> yes, yanyanhu, and each of them will have to be versioned
13:09:03 <XueFeng> No update this week
13:09:23 <XueFeng> Attend a meetup in NanJing
13:09:31 <Qiming> alright, would you give an update on your talk during open discussion?
13:09:51 <XueFeng> OK
13:10:01 <Qiming> next item is about node adopt
13:10:06 <XueFeng> And will have a article for the meetup
13:10:26 <yanyanhu> XueFeng, that's great :)
13:10:26 <Qiming> just added some resources to SDK, for getting environment, files and template back
13:10:39 <Qiming> senlin side driver patches are ready for review
13:11:07 <Qiming> em... both are in now: https://review.openstack.org/447001 and https://review.openstack.org/446866
13:12:18 <Qiming> review.openstack.org is slow ....
13:12:45 <yanyanhu> yes, it is...
13:13:01 <Qiming> actually, https://review.openstack.org/#/c/447001/ should not get in
13:13:11 <Qiming> because there is another patch at sdk side to be merged
13:13:41 <Qiming> and we will need to wait for another release from sdk to get the whole thing work
13:13:52 <Qiming> but anyway, cannot wait for so long
13:14:01 <XueFeng> OK
13:14:15 <Qiming> I think we are ready to move forward with node adoption
13:14:54 <XueFeng> Yes
13:15:09 <elynn> It's an important feature in senlin
13:15:14 <Qiming> next is from ruijie
13:15:47 <Ruijie> I cannot open etherpad .,..
13:16:06 <Qiming> the main requirement is about doing an optional health check before doing scaling
13:16:08 <Qiming> right?
13:16:12 <Ruijie> https://etherpad.openstack.org/p/pike-senlin-desired-health-check
13:16:18 <Ruijie> yes Qiming.
13:16:36 <Ruijie> We do desired_capacity check in scaling proces
13:16:37 <Qiming> I'm okay with this feature
13:16:56 <Qiming> desired capacity is expressed by a user's request
13:17:16 <Qiming> that is how we call it "desired"
13:17:58 <Qiming> looking at your story, I'm kind of feeling it is making things too complicated
13:18:17 <Ruijie> em .. Qiming, you mean which part
13:18:34 <Qiming> calculate new desired capacity based on old desired_capacity
13:18:42 <Qiming> the old value is never reliable
13:18:59 <Qiming> it might have been broken since last time you scaled your cluster
13:19:06 <Ruijie> I thought that is the mean of "desired" ..
13:19:25 <Qiming> a more reasonable process is to do your operations based on current scale
13:19:48 <Ruijie> e.g, current desired=3, num of nodes=3, we do scale out to 5. then the desired is 5
13:19:59 <Qiming> we have a long debate several months ago
13:20:39 <Qiming> when you do scaling, you express your expectation in parameters, senlin will compute your "desired capacity"
13:20:44 <yanyanhu> hi, Ruijie, I think the basic idea is senlin won't maintain the "desired" capacity. In opposite, users will maintain/remind this value in their own mind :)
13:20:53 <Ruijie> but if this process failed, say we only have 4 nodes, but the desired is still 5 ... I want 5 nodes in the cluster but not 4..
13:21:05 <Qiming> but this computation has nothing to do with the curren value of "desired_capacity"
13:21:23 <Qiming> this is especially true when you do auto-scaling
13:21:34 <yanyanhu> users can observe and know what is current size of cluster, then they scale their clusters based on the observation result
13:21:50 <Qiming> the metrics that trigger an auto-scaling is the active number of nodes, not the current "desired capacity"
13:21:56 <Ruijie> yanyanhu, you mean the "desired" is invisiable to user ?
13:22:14 <Qiming> desired is calculated from your last scaling operation
13:22:20 <yanyanhu> Ruijie, I mean senlin won't be responsible to maintain the "desired" value
13:22:20 <Qiming> that was your "desire"
13:22:24 <yanyanhu> yep
13:22:40 <yanyanhu> its users' "desire" :)
13:22:55 <Qiming> when senlin adjusts cluster scale, it is always based on the "reality", the current size of the cluster
13:23:07 <yanyanhu> so they always know this value and they don't need to rely on senlin to keep it
13:23:22 <Qiming> if you want to make sure the current size (cached in cluster's nodes list) is correct, you can still do a health check
13:23:27 <Qiming> there is no conflict ther
13:24:08 <Ruijie> okay, I think I got it .. we show the desired and current size, let user decide what to do
13:24:19 <Qiming> yes
13:24:25 <yanyanhu> Qiming, maybe we should consider to rename the property of "desired_capacity"...
13:24:29 <Qiming> that is how a user should be doing
13:24:41 <Qiming> and that is actually what a monitoring software doing
13:24:42 <Ruijie> Here is an problem we met.
13:25:14 <Qiming> yanyanhu, suggestions on renaming?
13:25:23 <Ruijie> current is 3, scale to 5, but 1 failed.
13:25:35 <yanyanhu> Qiming, yes. Or we keep it in current status but add some explanation on it
13:25:55 <Ruijie> then to make the process corrct, I need to scale out 1 again
13:26:12 <Qiming> Ruijie, in that case, the current size is 4, your last desired_capacity is 5
13:26:18 <Ruijie> And now we are using receiver to do scale, that means, I need to create another receiver to scale out 1 ..
13:26:21 <Qiming> you can see that from openstack cluster show
13:26:42 <Qiming> we don't do convergence
13:27:36 <Qiming> uses should check the current size of a cluster after an operation and explicitly tell us what to do next, via another service request
13:28:05 <Ruijie> yes Qiming, I understand, I mean if we based on old desired capacity, senlin will correct this process, then user will be free ...:)
13:28:23 <Qiming> no, it may be too dangerous
13:28:30 <Qiming> we actually don't know what happened
13:28:40 <Qiming> maybe the server has run out of resources
13:29:04 <Qiming> keep on trying creating a new node is only a waste of time
13:29:46 <Qiming> your other point, as I read from etherpad, is to ensure cluster recover to its desired capacity
13:29:49 <Qiming> that makes sense to me
13:30:01 <Qiming> if only we make the behavior configurable
13:30:09 <Ruijie__> sorry just dropped...
13:30:17 <Qiming> <Qiming> your other point, as I read from etherpad, is to ensure cluster recover to its desired capacity
13:30:17 <Qiming> <Qiming> that makes sense to me
13:30:17 <Qiming> <Qiming> if only we make the behavior configurable
13:31:02 <Qiming> I'd suggest we make the service robust and predictable first
13:31:15 <Ruijie__> yes Qiming
13:31:16 <Qiming> instead of trying to make it a smart robot
13:31:29 <Ruijie__> to correct the failure scaling when do scaling action again
13:31:42 <Qiming> especially be cautious when we teach senlin to guess what users meant
13:31:55 <Qiming> Ruijie__, that makes perfect sense to me
13:32:21 <Qiming> that is what the English word "recover" means, IMO
13:32:49 <Qiming> thx for bringing up these topics
13:32:52 <Ruijie__> another option is: we make scale as scale, and to do this process in recovery ..
13:33:05 <Qiming> yes
13:33:34 <Qiming> make the service dumb and stable
13:33:38 <Ruijie__> then all scaling based on current number of nodes,  cluster recover to correct all failures
13:33:59 <Qiming> yes, that is what I was suggesting
13:34:14 <Qiming> don't mix scaling with recovery instead
13:34:51 <Ruijie__> okay Qiming, that makes sense. And shell we do health check in scaling process, to make it configurable
13:35:08 <Qiming> yes, that sounds reasonable too
13:35:19 <Qiming> adding line 20 to etherpad just now
13:35:48 <Qiming> done?
13:35:50 <Ruijie__> okay, Qiming, I will modify the draft :)
13:35:53 <Ruijie__> yes Qiming
13:36:11 <Qiming> okay, you may want to create a BP for  this
13:36:22 <Qiming> or maybe two BPs?
13:36:29 <Qiming> moving on
13:36:35 <Qiming> next is about RDO packaging
13:36:48 <XueFeng> Rdo is in debug
13:36:54 <Qiming> okay
13:37:06 <Qiming> health mgmt
13:37:17 <Qiming> I'm not aware of any progress there
13:37:34 <Qiming> senlinclient functional test
13:37:48 <Qiming> no progress there either?
13:37:58 <XueFeng> Yes, will do it
13:38:13 <Qiming> alright
13:38:31 <Qiming> LB policy improvement
13:38:43 <Qiming> yet waiting to see a patch on that
13:38:50 <Ruijie__> let me see
13:39:02 <Qiming> em, that's all on the list
13:39:26 <Ruijie__> https://review.openstack.org/#/c/447267/
13:40:12 <Qiming> website is so slow
13:40:52 <XueFeng> Hi,ruijie
13:40:58 <Ruijie__> yes XueFeng
13:40:59 <Qiming> okay, Ruijie__ , will jump onto that
13:41:24 <XueFeng> it seems its the same with base.
13:41:26 <Qiming> cool, the link is in etherpad now
13:41:44 <Ruijie__> yes XueFeng, just removed one parameter.
13:41:47 <XueFeng> Don't get the point
13:41:57 <Ruijie__> I am still thinking how to process the data in a better way
13:42:18 <XueFeng> So will update the patch?
13:42:31 <Qiming> okay
13:42:39 <Qiming> take your time then
13:43:00 <Ruijie__> yes XueFeng, will update it latter. :)
13:43:12 <Qiming> anything else on pike work items
13:43:13 <Qiming> ?
13:43:22 <XueFeng> ok
13:43:25 <Qiming> we can move on now
13:43:34 <Qiming> #topic boston summit prep
13:43:56 <Qiming> I haven't got time to touch base with xinhui on the talk preps
13:44:04 <Qiming> will do that asap
13:44:22 <Qiming> elynn, any news you can share?
13:44:37 <elynn> not yet now
13:44:42 <Qiming> okay
13:44:46 <elynn> You could touch with xinhui
13:44:52 <Qiming> #topic open discussion
13:44:55 <Qiming> elynn, will do
13:45:05 <Qiming> XueFeng, your turn
13:45:13 <XueFeng> Ok
13:45:20 <elynn> xinhui and I are working on open-o staff recently.
13:45:29 <XueFeng> In 2017.3.18 there is a openstack meetup in NanJing China.
13:45:53 <XueFeng> And there will be a atricle about the meetup in weixin "yunkaiyuan".
13:45:55 <Qiming> elynn, take my knees
13:45:57 <yanyanhu> 18th, April?
13:46:11 <XueFeng> March
13:46:20 <yanyanhu> oh, you mean the meetup has finished
13:46:27 <XueFeng> Have finished:)
13:46:36 <XueFeng> The first topic is about senlin project.
13:46:39 <elynn> Just some trivial things which trap xinhui too.
13:46:46 <yanyanhu> :)
13:47:10 <yanyanhu> XueFeng, that is great
13:47:12 <XueFeng> And I do a introduce for senlin:)
13:47:15 <elynn> Good to know more people in Nanjing get to know senlin!
13:47:54 <XueFeng> Yes
13:48:00 <XueFeng> That will be
13:48:17 <XueFeng> Four parts about this topic.
13:48:46 <XueFeng> 1. Cluster requirements in openstack
13:49:15 <Qiming> XueFeng, I think most of us have read the article you wrote
13:49:18 <Qiming> it is great
13:49:23 <XueFeng> 2.What is senlin and what is senlin can do
13:49:32 <yanyanhu> yep :)
13:49:33 <Qiming> what we are curious about is the questions
13:49:40 <Qiming> expectations
13:49:43 <Qiming> complaints
13:49:55 <Qiming> or problems we can help address
13:49:56 <Ruijie__> also shared it to my colleagues
13:50:26 <XueFeng> 3.How to slove as+ha+lb all in one.Senlin can do this
13:50:45 <XueFeng> 4.Senlin Boston submit
13:50:57 <XueFeng> Senlin in Boston Submit
13:51:49 <XueFeng> And in the meetup
13:52:16 <XueFeng> Anohter people intordue Sahara
13:52:23 <XueFeng> person
13:53:00 <XueFeng> And I think we need to do some explaination about senlin and sahara
13:53:43 <XueFeng> What is the different. Many peoples don't know
13:55:07 <Qiming> any other feedback?
13:55:46 <XueFeng> Yes
13:57:19 <Qiming> okay, if you have a summary
13:57:29 <Qiming> you can send it out later to the team
13:57:37 <XueFeng> OK
13:57:40 <XueFeng> :)
13:57:44 <Qiming> if there are no other topics for discussion
13:57:54 <Qiming> we can release the channel now
13:58:11 <XueFeng> ok
13:58:19 <XueFeng> good night,all
13:58:24 <Qiming> thanks for joining, guys
13:58:31 <Qiming> #endmeeting