13:00:03 <yanyanhu> #startmeeting senlin
13:00:04 <openstack> Meeting started Tue Dec 13 13:00:03 2016 UTC and is due to finish in 60 minutes.  The chair is yanyanhu. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:07 <openstack> The meeting name has been set to 'senlin'
13:00:12 <yanyanhu> hello, everyone
13:00:20 <elynn> hi yanyanhu
13:00:23 <yanyanhu> hi, elynn
13:00:37 <Qiming> o/
13:00:44 <yanyanhu> hello
13:01:08 <yanyanhu> hi, Ruijie_
13:01:16 <Ruijie_> evening, yanyanhu
13:01:23 <yanyanhu> evening
13:01:38 <yanyanhu> lets wait for a while for other attenders
13:01:53 <yanyanhu> here is the agenda, please feel free to add topics
13:01:54 <yanyanhu> https://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Agenda_.282016-12-13_1300_UTC.29
13:02:02 <lvdongbing> hello, everyone
13:02:14 <yanyanhu> hi, lvdongbing
13:02:46 <yanyanhu> ok, lets start
13:02:58 <yanyanhu> #topic ocata workitem
13:03:02 <yanyanhu> https://etherpad.openstack.org/p/senlin-ocata-workitems
13:03:10 <yanyanhu> ocata workitem
13:03:16 <yanyanhu> Testing
13:03:42 <yanyanhu> will start to work on tempest API improvement after versioend request support is done
13:04:09 <yanyanhu> and Ruijie_ has spent some time on rally test recently
13:04:26 <Ruijie_> asked that question in rally channel
13:04:37 <yanyanhu> try to support more scenarios
13:04:41 <yanyanhu> yes
13:05:23 <Ruijie_> but didn't get answered
13:05:33 <yanyanhu> ok
13:06:09 <yanyanhu> so maybe we can use 'public' rather than 'private' network in nova server profile as a workaround temporarily
13:06:13 <Ruijie_> will try to update the network to "shared:true"
13:06:32 <yanyanhu> then we need to find a better way to address this issue, e.g. creating specific network for test
13:06:45 <yanyanhu> Ruijie_, that is also feasible I think
13:07:00 <Ruijie_> if that can pass the test, then it's a netwrok problem
13:07:11 <yanyanhu> I think you can refer to the "server" scenario in Rally
13:07:34 <yanyanhu> I recalled there are some network related operations included
13:07:42 <yanyanhu> Ruijie_, yes
13:08:03 <Ruijie_> yes, yanyanhu, will check it
13:08:10 <yanyanhu> great, thanks a lot :)
13:08:25 <yanyanhu> ok, next one, health management
13:08:26 <Ruijie_> my pleasure :)
13:08:39 <yanyanhu> I think xinhui is in business travel this week
13:09:14 <yanyanhu> just sent a mail to Michael to seek oppotunity for more discussion on the following bp
13:09:25 <yanyanhu> https://blueprints.launchpad.net/octavia/+spec/octavia-event-notifier
13:09:52 <yanyanhu> will wait for their feedback
13:10:24 <Qiming> also, xinhui mentioned that she will work on integrating mistral into senlin when she is back
13:10:36 <yanyanhu> great
13:11:08 <yanyanhu> maybe she can give us a quick introduction about mistral
13:11:21 <yanyanhu> especially how it works with Senlin for HA scenario
13:11:28 <Qiming> another thing I have been thinking of is about health detection
13:11:37 <yanyanhu> yes?
13:11:48 <Qiming> suppose I have a monitoring service deployed
13:12:03 <Qiming> from HA's perspective, it is equivalent to LBaaS
13:12:14 <Qiming> I mean, it can help monitor the service availability from nodes
13:12:14 <yanyanhu> ok
13:12:49 <Qiming> we should enable this service to tell us that a specific node is unhealthy
13:13:12 <yanyanhu> you mean we enable it (on behalf of user)?
13:13:37 <Qiming> the question is, how that service is supposed to notify senlin?
13:14:02 <yanyanhu> ummm, good question. Currently, we have listener
13:14:18 <yanyanhu> but it is created within health policy I think
13:14:21 <Qiming> several options: 1 send a message into zaqar, we listen to that
13:14:48 <Qiming> 2. send a message to the control plane message queue, just like nove-compute does
13:15:04 <yanyanhu> looks like option1 is more reasonable
13:15:15 <Qiming> however, the monitoring service is doing failure detection from business plane
13:15:42 <Qiming> 3. send a webhook API, invoking an operation in senlin
13:15:51 <Qiming> or directly invoke a senlin API
13:16:03 <Qiming> but we don't have such an API yet
13:16:10 <yanyanhu> option3 is almost euqal to calling senlin API directly
13:16:21 <Qiming> em, yep
13:16:44 <XueFengLiu> want to add?
13:16:49 <yanyanhu> imho, option1 is the most flexible and safe one :)
13:17:10 <Qiming> the only concern about option 1 is about zaqar's stability
13:17:17 <elynn> I would prefer option 2....
13:17:19 <Qiming> its API is so .... weird to me, :D
13:17:24 <yanyanhu> yes, that could be a issue
13:17:29 <elynn> Since not every env deploy zaqar...
13:17:30 <yanyanhu> :P
13:17:49 <yanyanhu> honestly, Zaqar is really important is many cases
13:17:59 <Qiming> okay, option 3 is left to me for vote?
13:18:05 <Qiming> I agree
13:18:06 <elynn> Yes, agree with you yanyanhu
13:18:15 <Qiming> so we should support that scenario
13:18:18 <yanyanhu> yes
13:19:01 <yanyanhu> and it also provides enough flexibility for user to control the workflow, including building the queue, let monitoring service to send message
13:19:18 <Qiming> PATCH /v1/nodes/<node_id>  {'node': {'status': 'DEAD'}} ?
13:19:47 <Qiming> not sure yet, but we can keep thinking about it
13:19:57 <yanyanhu> mark a node to failed status manually :)
13:20:00 <yanyanhu> yep
13:20:30 <Qiming> this is still a notification based failure detectin
13:20:37 <yanyanhu> I believe all those options have their own use cases
13:20:45 <yanyanhu> yes
13:20:56 <Qiming> in the other direction, there will be HTTP GET, ICMP ping operations to detect node failures
13:21:19 <yanyanhu> the polling way
13:21:30 <Qiming> in other words, we kinda "replicate" the health monitor function locally
13:21:44 <Qiming> no matter we do LB or not
13:21:50 <yanyanhu> yes
13:22:11 <yanyanhu> like a simple health monitor implemented inside senlin
13:22:34 <Qiming> if we have that capability, we stop bugging the octavia team for fixing their bugs
13:23:09 <Qiming> we don't duplicate things unless we HAVE TO
13:23:16 <yanyanhu> agree
13:24:01 <yanyanhu> maybe we can add those items we discussed to TODO list
13:24:10 <Qiming> okay, just some random thoughts on buidling a comprehensive HA solution
13:24:20 <yanyanhu> that is very helpful
13:24:21 <Tracks16> http://ilredentore.dynv6.net regards...
13:24:43 <Qiming> okay, will do that
13:24:44 <yanyanhu> especially the message based notification
13:24:49 <yanyanhu> great, thanks a lot
13:25:24 <yanyanhu> later, we can pick them up and file bp/spec for them
13:25:40 <XueFengLiu> greate
13:25:45 <Qiming> sure
13:25:50 <XueFengLiu> great
13:26:02 <yanyanhu> please feel free to claim it :)
13:26:08 <yanyanhu> ok, next one
13:26:19 <yanyanhu> document
13:26:24 <yanyanhu> no progress I guess
13:26:31 <yanyanhu> versioned request support
13:26:37 <yanyanhu> it is done now?
13:26:51 <yanyanhu> receiver notify support has been added I think
13:27:03 <yanyanhu> any other unfinished parts?
13:27:05 * Qiming is looking
13:27:20 <yanyanhu> thanks :)
13:27:30 <Qiming> credential_create, credential_get
13:27:36 <yanyanhu> ah
13:27:45 <Qiming> credential_update
13:27:45 <yanyanhu> those two are user invisible ones
13:28:01 <Qiming> but they live on RPC interfaces
13:28:05 <yanyanhu> yep
13:28:11 <Qiming> get_revision
13:28:25 <Qiming> action_delete
13:28:35 <Qiming> under review already? ^
13:28:41 <yanyanhu> guess so
13:28:43 <yanyanhu> let me check
13:28:46 <Qiming> that's all
13:28:51 <XueFengLiu> action_delete need delete
13:29:17 <yanyanhu> https://review.openstack.org/409409
13:29:24 <yanyanhu> has been there
13:29:48 <Qiming> it is only about the object
13:29:50 <XueFengLiu> the old need delete
13:30:00 <Qiming> engine service is not yet changed
13:30:03 <yanyanhu> oh, here is the eng support
13:30:04 <yanyanhu> https://review.openstack.org/409411
13:30:19 <yanyanhu> there is no action_delete API I think
13:30:23 <yanyanhu> XueFengLiu, yes
13:30:27 <yanyanhu> need to remove dead code
13:30:37 <Qiming> ah, ... finally I understand what you said, XueFengLiu
13:30:40 <XueFengLiu> yes ,api no need to do
13:30:45 <yanyanhu> :)
13:30:57 <yanyanhu> ok, will work on left ones
13:31:07 <yanyanhu> and hope to catch the ocata-2 release
13:31:09 <XueFengLiu> ok
13:31:37 <XueFengLiu> also checked ploicy/profile update
13:31:43 <yanyanhu> then we can rename those "**2" service calls :)
13:31:52 <Qiming> yes, please, :D
13:32:03 <XueFengLiu> two problems meraged
13:32:21 <yanyanhu> XueFengLiu, yes, saw your bug report
13:32:33 <yanyanhu> so those fixes have been merged
13:32:51 <Qiming> you mean two patches merged?
13:33:00 <yanyanhu> Qiming, yes
13:33:15 <yanyanhu> https://review.openstack.org/409426
13:33:23 <yanyanhu> and this one?
13:33:24 <yanyanhu> https://review.openstack.org/409427
13:33:45 <yanyanhu> XueFengLiu, did I miss anything?
13:34:20 <yanyanhu> ok, lets move on
13:34:28 <yanyanhu> container profile
13:34:33 <yanyanhu> haiwei is not here?
13:34:58 <yanyanhu> ok, lets skip it
13:35:03 <Qiming> wait
13:35:06 <yanyanhu> yes?
13:35:15 <Qiming> #368539 has been abandoned
13:35:27 <XueFengLiu> Sorroy, offline just now
13:35:35 <XueFengLiu> move on
13:35:55 <Qiming> and I have reworked that profile thing
13:36:03 <yanyanhu> Qiming, ah, right
13:36:11 <Qiming> now we have a 'create' classmethod of Profile
13:36:13 <yanyanhu> those two patches have been merged
13:36:38 <yanyanhu> that logic should stay in container profile rather than engine service call
13:36:45 <Qiming> it is enabling us to do extra work in subclasses when a profile is created or deleted
13:36:52 <yanyanhu> yep
13:37:00 <Qiming> As I have left a TODO in the profile
13:37:18 <Qiming> it is only capable of removing dependency from clusters today
13:37:32 <Qiming> still needs to handle dependency on nodes
13:37:35 <yanyanhu> yes
13:38:20 <Qiming> I'm adding an item and assigning it to myself
13:38:33 <Qiming> feel free to rob it from me, guys
13:38:42 <yanyanhu> thanks :)
13:38:59 <XueFengLiu> hh
13:39:03 <yanyanhu> ok, next one, Events/Notifications
13:39:15 <yanyanhu> Qiming, configuration options have been added?
13:39:21 <Qiming> not yet
13:39:31 <Qiming> or else line 27 could be removed
13:39:37 <yanyanhu> I see :)
13:39:54 <yanyanhu> noticed you're working on reorg the code of versioned request support in API layer
13:40:03 <yanyanhu> to remove those duplicated code for request parsing
13:40:14 <Qiming> yes, adding that into etherpad now
13:40:16 <yanyanhu> by adding a util func
13:40:17 <Qiming> line 21
13:40:29 <yanyanhu> great, thanks
13:40:33 <Qiming> yes, I hate duplicated codes
13:40:38 <yanyanhu> me too :)
13:40:49 <yanyanhu> doesn't look good
13:40:58 <Qiming> the 'parse_request' function is very powerful
13:41:11 <Qiming> it can build formalized primitives
13:41:29 <Qiming> it can lookup class names for a request, instantiate it
13:41:42 <Qiming> it can validate request using jsonschema
13:42:02 <yanyanhu> yes, almost everything is done there
13:42:03 <Qiming> it can do version search based on the api_version in the context now
13:42:32 <yanyanhu> maybe we can wrap it to a decorator :)
13:42:45 <Qiming> thought about that
13:43:21 <Qiming> problem is that not all APIs have the same collection of positional arguments and/or keyword arguments
13:43:39 <yanyanhu> ah, right
13:43:51 <Qiming> the creatoin of request objects would need those arguments
13:44:04 <Qiming> it is not an easy job
13:44:04 <yanyanhu> yes
13:44:19 <yanyanhu> and it's not functional necessary
13:44:34 <Qiming> also, decorators are not easy to override
13:44:44 <yanyanhu> yep
13:44:52 <Qiming> if a handler has a slightly different logic, you will need a different decorator?
13:45:12 <Qiming> those are two reasons I refrained from decorators
13:45:18 <yanyanhu> right, that will be a problem
13:45:36 <yanyanhu> I see.
13:45:53 <yanyanhu> ok, so those are all items in the list
13:46:00 <yanyanhu> anything missing
13:46:20 <yanyanhu> ok, lets move on
13:46:24 <yanyanhu> #topic Join Tacker IRC meeting to discuss Senlin based VDU support
13:46:50 <yanyanhu> just remind, Tacker IRC meeting will be at 0530UTC
13:46:52 <yanyanhu> tomorrow
13:46:56 <yanyanhu> Dec.14th
13:47:07 <yanyanhu> anyone who is interested in it, please join it
13:47:13 * Qiming marking it in calendar now
13:47:15 <elynn> hmm, it is an important thing
13:47:19 <yanyanhu> yep
13:47:24 <yanyanhu> will join it as well
13:47:36 <elynn> would be 13:30 china time
13:47:39 <yanyanhu> I believe haiwei and xinhui will join it as well
13:47:42 <elynn> How to join it?
13:47:44 <yanyanhu> yes, good time for us, haha
13:47:49 <elynn> at openstack-meeting?
13:47:55 <yanyanhu> just join the meeting channel
13:47:57 <yanyanhu> yep
13:48:00 <yanyanhu> I guess so :)
13:48:12 <yanyanhu> will double confirm with haiwei tomorrow morning
13:48:30 <yanyanhu> to see whether he needs any help
13:48:33 <Qiming> cool, we will have a lot people making noises there I hope
13:48:38 <yanyanhu> haha
13:48:53 <yanyanhu> or a smooth discussion if we have concensus :)
13:49:11 <Qiming> maybe bring sahdev in ?
13:49:18 <yanyanhu> Qiming, oh, right
13:49:20 <yanyanhu> that will be great
13:49:45 <yanyanhu> maybe you can send him a mail to ask him
13:49:47 <elynn> too late for him I guess
13:49:54 <Qiming> ah, yes
13:49:58 <yanyanhu> yes, a little bit late
13:50:07 <Qiming> 10pm?
13:50:23 <yanyanhu> I guess 12:30?
13:50:26 <yanyanhu> he is in Austin?
13:50:34 <Qiming> yes, Austin I think
13:51:01 <yanyanhu> if so, should be around 10:30pm?
13:51:21 <yanyanhu> can't recall the time difference between us
13:51:41 <yanyanhu> anyway, hope he can join it
13:51:51 <yanyanhu> ok, next topic?
13:52:02 <yanyanhu> #topic Ocata-2 release
13:52:04 <Qiming> or we can sync with him at least, after the meeting
13:52:10 <yanyanhu> Qiming, sure
13:52:28 <yanyanhu> he is also the key of this work I think
13:53:02 <yanyanhu> so everyone, ocata-2 release will be cut this week
13:53:23 <Qiming> any high priority bugs ?
13:53:54 <yanyanhu> Qiming, just the one ethan is working on I guess?
13:53:58 <Qiming> this one: https://bugs.launchpad.net/senlin/+bug/1648681
13:53:59 <openstack> Launchpad bug 1648681 in senlin "Don't set action to failed if acquire lock failed." [Critical,In progress] - Assigned to Ethan Lynn (ethanlynn)
13:54:03 <yanyanhu> about the action lock acquiring
13:54:06 <yanyanhu> yes
13:54:07 <yanyanhu> this one
13:54:16 <yanyanhu> other ones are not critical
13:54:23 <elynn> patches are all submitted at least
13:54:37 <elynn> need to modify the first patch a little bit.
13:54:40 <Qiming> will look into them tomorrow
13:54:43 <yanyanhu> elynn, great
13:54:59 <Qiming> thx, elynn, acquire_1st_ready is useless now
13:55:02 <yanyanhu> will check it as well. I think Qiming's comment on the first patch makes sense to me as well
13:55:18 <yanyanhu> we can just remove ***_1st_ready api
13:55:31 <yanyanhu> it will not be used after the new db api is added
13:55:49 <elynn> The main purpose of these patches are remove acquire_lock  retries, and let scheduler pick them up later.
13:56:02 <yanyanhu> elynn, yep
13:56:04 <Qiming> that makes sense
13:56:31 <elynn> So that actions would get failed because of acquire lock failed.
13:56:32 <yanyanhu> ok, I plan to cut the release on Thursday
13:56:41 <Qiming> we will need to ensure that scheduler will try find some jobs periodically
13:56:46 <yanyanhu> by the end of Thursday evening or Friday morning
13:57:12 <Qiming> alright, will check if there are other things urgent
13:57:20 <yanyanhu> great, thanks a lot
13:57:36 <yanyanhu> ok, open discussion now
13:57:41 <yanyanhu> 2 minutes left...
13:57:47 <yanyanhu> #topic open discussion
13:57:48 <Qiming> still some patches open for review: https://review.openstack.org/#/q/project:openstack/senlin+status:open
13:58:06 <yanyanhu> yes, maybe need to close some ones
13:58:14 <yanyanhu> which are not active for a long while
13:58:31 <Qiming> most of them are not critical I think
13:58:33 <yanyanhu> and they can be restored if needed
13:58:38 <yanyanhu> Qiming, I see
13:58:43 <yanyanhu> will check the list
13:58:44 <Qiming> except for elynn's
13:58:55 <yanyanhu> yep
13:59:07 <yanyanhu> ok, great
13:59:14 <yanyanhu> only one minutes left
13:59:25 <Qiming> I'll complete the node dependency patch
13:59:31 <yanyanhu> Qiming, great
13:59:38 <yanyanhu> will help to review
13:59:44 <yanyanhu> ok, time is almost over
13:59:48 <Qiming> cool
13:59:50 <yanyanhu> lets release the channel
13:59:56 <yanyanhu> thanks all you guys for joinging
14:00:00 <yanyanhu> have a good night
14:00:04 <yanyanhu> #endmeeting