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