13:00:12 #startmeeting senlin 13:00:13 Meeting started Tue Sep 12 13:00:12 2017 UTC and is due to finish in 60 minutes. The chair is ruijie_. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:17 The meeting name has been set to 'senlin' 13:00:35 here is the agenda: https://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Agenda_.282017-09-12_1300_UTC.29 13:00:46 feel free to add items if needed :) 13:01:25 hi, I have added two items 13:01:44 yes Qiming, noticed that :) 13:02:02 let's wait for a while ? 13:04:05 well :) let's get started from the work items 13:04:34 I just moved the work items to a new etherpad page, Qiming 13:05:48 hi Qiming, are there updates about the node adoption 13:06:39 so that 13:06:50 no 13:07:49 okay Qiming, I am going to finish the gc work this week. And will look back to the scaling improvement :) 13:08:12 ok 13:09:19 em, as I can see, there are no critical bugs left 13:11:40 next one is about the "api requests with extra field" 13:11:47 Qiming, your tern :) 13:12:12 alright, got request this morning 13:12:13 s/tern/turn 13:12:23 it was on #senlin channel 13:12:44 someone asked if there are ways to intercept a scaling operation 13:13:13 for example, before a cluster is scaled in, we invoke a hook 13:13:27 the user wanted to do something 13:13:47 then confirm the scale in operation if it is permitted 13:14:52 http://docs.aws.amazon.com/autoscaling/latest/userguide/lifecycle-hooks.html? 13:15:46 it's about we can intercepting the scaling actions and then roll back ? 13:16:08 it doesn't have to be roll back 13:16:31 just leave the users some options 13:16:40 I can imagine a simple policy to do that 13:17:31 the real challenge is about how can we differentiate the original request which needed to be intercepted and the resent one, which meant to be performed anyway 13:18:35 like threetee said, send a signal to the VM to ask the app on it to shutdown, and after that the VM will send an notification so that we can really destroy the VM 13:19:13 if it is only about a signal 13:19:22 it can be done easily using a policy 13:19:55 another similar request we go early is about scaling out 13:20:15 before scaling out, that user wants to be notified 13:20:39 they need a management approval before the scale-out operation is performed 13:21:05 yes Qiming, like a work order 13:21:14 that led me to the thought about extra API parameter 13:21:58 telling us where the request came from, or telling us whether it should skip a policy check 13:22:34 for example, a request comes with an 'extra' field. 13:23:01 if the scaling request comes from a metering/alarming service, that field would be empty, by default 13:23:39 the policy can then process the request and redirect it somewhere, calling a hook, trigger a business process service or a workflow ... whatever 13:24:35 yes Qiming, we can do that to ask for aprovement 13:24:36 when that request is approved (maybe with some modifications to its parameters), the 'extra' field now has a field {'approved': true} 13:25:25 the policy looks at the request again, and refrain from redirecting it, go ahead and execute it as usual 13:25:56 the point is the second request has to be somehow different from the initial one 13:26:38 did I make a point? 13:26:46 yes Qiming 13:27:04 I thought we can do that before we create any actions? 13:27:27 so that we don't need to care about how long this process will take or whether it will block out engine 13:27:27 em ... don't think so 13:28:03 policies are only checked when an action is about to be executed 13:28:23 unless we explicitly add a new concept, e.g. hook 13:28:49 yes, a watcher.. 13:28:50 then we have to decide to what scope a hook can cover 13:29:36 hi XueFengLiu 13:29:49 hi,ruijie_ 13:30:05 hi, all 13:31:04 we are just talking about adding extra fields to api request. http://docs.aws.amazon.com/autoscaling/latest/userguide/lifecycle-hooks.html? 13:33:05 looks good. Let me check the meeting history 13:35:46 alright, next thing is about event notification documentation 13:36:06 I have just realized that we don't have proper documentation for users 13:36:19 Looks to me we only have developer docs 13:36:47 yes Qiming :) 13:37:48 some of the text here are really targeting users rather than developers 13:37:50 http://git.openstack.org/cgit/openstack/senlin/tree/doc/source/contributor/event_dispatcher.rst 13:38:47 the overview section and the last section are both for users 13:39:24 we need a user reference and one for developer guidelines perpose ? 13:39:37 I think s 13:39:39 so 13:39:58 that is how the docs are organized today 13:40:20 Yes 13:41:01 see here: https://docs.openstack.org/senlin/latest/ 13:41:44 section 2-4 are for users, section 5 is for developers 13:41:56 the community may have some new guidelines 13:42:12 Qiming 13:42:27 I'm just too tired to follow all those guidelines 13:42:46 Some new user may can't know which is for user which is for developer 13:42:59 then they can read them all 13:43:24 section 5 has a title, right? 13:43:40 a user won't touch that section 13:44:12 all developers are supposed to read them all, because they are supposed to start as a user 13:44:24 Yes 13:44:44 okay, ruijie_ 13:44:53 From the guideline, some section title is the same 13:44:54 I have got 3 other topics 13:45:00 honestly, I didn't find the notification part on this page :) 13:45:04 can I quickly dump them here? 13:45:20 ruijie_, that is something we can improve 13:45:24 sure Qiming 13:46:10 1. pls help review https://review.openstack.org/#/c/500713/ 13:46:23 and https://review.openstack.org/#/c/501548/ 13:46:38 the developer pinged me asking why there are no reviews 13:46:55 revieded +1, but did't got new patch yet :) 13:47:27 2. as part of Queens community goal, we are about to separate tempest out 13:47:41 OK, will review 13:47:51 I have created a repo on github.com, hopefully maintained all commit history 13:47:53 https://review.openstack.org/#/c/501548/ 13:48:02 sorry, wrong link 13:48:07 https://github.com/tengqm/senlin-tempest-plugin 13:48:29 when it is ready, we are supposed to propose a new repo for senlin project to host the tests 13:48:48 OK 13:49:34 3. there are things insane in the community, as always, please pay attention if you get cycles 13:49:40 this one: https://review.openstack.org/#/c/502216/ 13:49:50 it is reinventing senlin inside tacker 13:50:07 funny ... but no one can stop people doing that 13:50:26 this one: https://review.openstack.org/#/c/465782/ 13:50:37 really pissed off 13:51:27 how could people be so arrogant? 13:51:52 that's all from my side, ruijie_ 13:52:01 back to you 13:52:07 so according to there understanding, we are manageing VMs and containers .. that is irresponsible 13:52:33 okay Qiming, next one 13:52:42 Queens Meetup :) 13:53:14 we can find a place to have a meetup to discuss our goals for Queens 13:53:27 sure 13:53:48 OK, got all. Will check all this points tomorrow.Qiming, ruijie_ 13:54:19 or, since it is almost 10.01, we can choose 1. have a virtual meeting first, and then hold meetup in middle Oct 2. f2f directly :) 13:54:43 +1 13:55:13 I'll be out of town during Oct holidays 13:55:44 mid Oct sounds good to me 13:56:13 I was reading that as " Oct 2." 13:56:29 my bad :) 13:57:04 okay Qiming, I am going to send a email to mailing list about the virtual meeting 13:57:13 it's your call 13:57:27 and we can discuss the detail about the meetup later 13:57:40 ok 13:57:57 any other topics to discuss :) 13:58:47 I'm looking at this: https://review.openstack.org/#/c/502757/ 13:59:04 hoefully can figure out what went wrong 13:59:43 https://review.openstack.org/#/c/502996/ 13:59:56 ya 14:00:22 timesout 14:00:26 #endmeeting