13:00:05 #startmeeting senlin 13:00:06 Meeting started Tue Apr 12 13:00:05 2016 UTC and is due to finish in 60 minutes. The chair is Qiming. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:09 The meeting name has been set to 'senlin' 13:00:18 hello guys 13:00:41 Hi! 13:00:45 hi 13:00:49 hi 13:00:59 please review agenda and see if you have things to add: https://wiki.openstack.org/wiki/Meetings/SenlinAgenda 13:01:28 very slow to open this link... 13:01:34 hi 13:01:43 Hello. 13:01:48 haiwei, just on time 13:01:53 yes 13:01:55 ? 13:02:01 #topic container clustering progress 13:02:16 any new progress to share? 13:02:44 I implemented most the needed functions, and thinking about auto-scaling things 13:02:45 I have read your slides, but it would be better to share with everyone where we are in this thread 13:03:10 hi 13:03:10 also started to write the ppt, only some guidelines 13:03:47 about the picture you wanted, what about the one I sent it to you, Qiming 13:04:00 not sure your idea about it 13:04:01 they look good 13:04:17 need to articulate our points in the talk 13:04:24 I think we should finish all ppt materials within this week 13:04:50 it would be great if you (and everyone else who are interested in this) can check the latest discussion on dev mailinglist 13:04:56 #link http://lists.openstack.org/pipermail/openstack-dev/2016-April/091947.html 13:04:58 should we decide the division? 13:06:02 I'll start working on a storyline and share with you, we may need several conf call discussions 13:06:12 i will read it 13:06:19 interesting thread 13:06:23 ok 13:06:48 As always, the community is still split on the right direction to go, that is the reason for the discussion 13:06:53 there are proponents, there are strong opponents 13:07:15 it is a good discussion anyway 13:07:30 sure, this is a community not a company :) 13:08:00 even in a company, it happened sometimes... 13:08:18 right, that is why it is called open community and why we like it, :) 13:08:31 yep :P 13:09:24 autoscaling prototype would be nice, but we really need a story line, why are we doing this, how are we planning to do it ... so on and so forth 13:09:42 agree 13:09:44 anyway, will send you a draft tomorrow 13:09:51 thanks 13:10:06 #topic API schema check 13:10:47 after working on the API micro-versioning stuff, I was reviewing a api-wg spec about strictly checking REST API requests 13:10:50 this topic is interesting 13:11:20 not just the requested URI, but also the payload, e.g. the attributes you can specify when creating a resource 13:11:47 We do have some ad-hoc checkings in the API layer, and I have added a TODO items in the TODO.rst file 13:11:59 haiwei suggested we go API schema checking 13:12:20 so I went digging nova api and keystone api 13:12:31 I have some experiences with Nova API schema 13:12:33 this kind of a feature is not a new wheel to invent 13:13:01 ah, I remember the issue we met before: neutron will complain if an unrecoginized attr is provided in api request body 13:13:29 just need to check in some basic framework then gradually fill in the schemas for each API 13:13:29 yes, yanyanhu 13:13:31 finally caused the path_arg problem on sdk side 13:13:34 then finally turn it on 13:13:56 neutron is doing the right thing, according to the approved api-wg spec 13:14:03 yes 13:14:28 at API layer, a silent failure sometimes is poisonous 13:14:56 agree. Or there should be an explicit description in API doc 13:15:05 haiwei, do you have suggestions how we start this? 13:15:20 to say unroconized attr will not fail the API request 13:15:47 api schema check is much stricter than that 13:15:49 s/unroconized/unrecognized 13:15:51 we can refer to what is done in Nova, if we want to do this, we should list all the APIs, and do one by one 13:16:07 people are using it to check data types, field length .. 13:16:26 Qiming, it includes type verification? 13:16:31 oh 13:16:36 the nova one is pretty complex, because it is somehow intermingled with api extensions 13:16:37 for every API, every parameter, check the type/length and anything necessary 13:17:00 should this be a topic for Newton release? 13:17:01 add a decorator, say what you want to check, implement the checker 13:17:20 Sounds like a lot of work. 13:17:22 cschulz_, doesn't sound a controversial topic 13:17:32 it is .... just labor ... :) 13:17:38 we can write a small test case use the jsonschema to see what happens if something guilty is passed 13:17:42 sounds good 13:17:42 we have a lot of fields to catch up 13:18:09 yes, need much patience, Qiming 13:18:33 so far, we are doing pretty good, :) 13:18:51 there are many projects lacking this 13:18:59 yes 13:19:08 we just focus on doing the right thing and the get the thing done 13:19:42 if you are experienced on this, haiwei, can you help lay out a roadmap? 13:19:57 what are the initial frameworks we need? 13:20:14 many existing checks in the api layer will be needless, if we import this schema 13:20:27 then everyone can help fill in the gaps for individual api requests 13:20:28 ok, Qiming 13:20:33 great! 13:21:12 here is the keystone specs for reference: https://specs.openstack.org/openstack/keystone-specs/specs/juno/keystone-api-validation.html 13:22:08 thanks 13:22:09 I'll be away for a short time 13:22:29 okay, cschulz_ 13:22:58 I also checked different wsgi frameworks, trying to find a better alternative 13:23:11 this has been discussed in the community again and again 13:23:33 yes, from grizzly cycle 13:23:48 the hope is that there could be some framework having builtin support to validation, documentation, middleware, ... 13:24:14 that would be a huge reengineering 13:25:34 so .. let's keep the scope narrowed 13:25:38 moving on 13:25:44 I'm back 13:25:46 #topic newton work items 13:25:58 #link https://etherpad.openstack.org/p/senlin-newton-workitems 13:26:47 scalability experience sharing, haven't confirmed with suzhou guys on a conf call 13:27:04 will try again 13:27:11 tempest testing 13:27:16 will they go to summit as well? 13:27:30 yes, they have topics accepted as well 13:27:35 nice 13:27:46 nice 13:27:47 elynn ? 13:27:52 yes 13:28:09 can make further discussion with them in design session 13:28:13 Not much updated yet 13:28:22 okay 13:28:29 I think the basic framework looks good now 13:28:32 stress testing 13:28:36 waiting for the patch to rename tempest folder to get merged. 13:28:37 based on our discussion 13:28:51 stress test: now we are focusing on rally 13:29:00 agree, need some reviews 13:29:03 hope to leverage it to support senlin benchmarking 13:29:22 So it is not stress test, to be accurate? 13:29:22 I think it is a good choice for this purpose 13:29:31 yes, should be performance test 13:29:40 stress test should be covered by tempest? 13:29:49 per our discussion, elynn ? 13:29:54 yes 13:30:03 rally will do benchmark 13:30:17 ok, so we have a concensus about how to organize senlin's test cases 13:30:22 tempest for API, scenerio, stress tests. 13:30:35 okay 13:30:38 including api, scenario, benchmark, and maybe stress 13:31:24 when we have a basic framework landed, guys can start fill it with more test cases 13:31:26 We should discuss what stress tests we are going to support. 13:31:41 Qiming, yes 13:32:00 About rally support for senlin, the first patch to add basic support looks good now. Need to wait rally team's decision 13:32:25 link is in the etherpad, I still haven't open that page... 13:32:36 if we want to try that, we have to do a git review -d? 13:33:03 -d? 13:33:16 maybe we should reach out to that team and ask for opinions 13:33:34 git review -d is used for check out a specific patch for review locally 13:33:58 https://review.openstack.org/#/c/298109/11 13:33:59 Qiming, oh. I ususally used the link provided in gerrit web UI :) 13:34:13 This is the one for rally, I think. 13:34:19 thank, elynn 13:34:23 it is 13:35:21 maybe we should try ping the rally cores on IRC 13:35:23 we can start work on senlin plugins I think 13:35:34 although they depends on that patch 13:35:41 it has been hanging there for over a week now, no reviews 13:35:42 Qiming, yes 13:36:16 just not sure how is the test going 13:36:17 if that is the only blocker, remove it, and move on 13:36:29 I see 13:36:37 then find their IRC channel, ask questions, :) 13:36:57 yes, I have. But I guess the time difference blocks the msg :) 13:37:20 anyway, will try to reach them 13:37:25 cool 13:37:41 time zone is never a critical issue 13:37:45 oh, BTW, this patch works now 13:37:46 https://review.openstack.org/303923 13:37:52 it 13:38:06 health management, R_lixh ? 13:38:11 it's a plugin for senlin tempest test 13:38:31 I just start to looking at the fencing agent 13:38:39 okay, I was reviewing that, but distracted again today 13:38:41 and existing work done 13:38:50 on evacuation 13:39:06 trying to set up the project 13:39:24 still trying to put the story together 13:39:34 then see what we can do in this feild 13:39:42 okay, if you have some rough ideas, you can put them into the etherpad 13:39:58 ok 13:40:11 ping the team when you have new inputs there, :) 13:40:28 documentation 13:40:30 Yes, I am thinking to monitor their IRC 13:40:46 I have just started some work on this 13:41:06 a tutorial on wiki is not a good idea -- difficult to maintain 13:41:25 so I'm starting a new subdir in senlin doc tree 13:41:42 the existing user doc will be used as a reference 13:42:14 there will be many links from the tutorial saying: for full documentation on ..., see .... 13:42:15 is that necessary to put the tutorial into readthedocs? 13:42:31 readthedocs is not openstack 13:42:58 agree 13:43:11 I'm not sure we can publish docs directly to readthedocs 13:43:12 yes, just think maybe it's a public place to hold the tutorial 13:43:36 if the tutorial goes online in official openstack docs site 13:43:50 we can just add a link from the wiki 13:43:59 that will be the best 13:44:36 btw, xinhui's patch on auto-scaling tutorial will be merged into this tutorial as a sub-section 13:44:53 so I'm deleting line 29 on the etherpad 13:45:26 ok 13:45:33 the template used is also proposed to heat-templates project 13:45:33 so the next item is done also 13:46:25 event log generation bug has been fixed, finally 13:46:54 haiwei, do we have some place to check in your strawman code? 13:47:16 I mean the container support? 13:47:21 I did it locally 13:47:28 we can find some place on github 13:47:37 I can checkin my work there 13:47:38 shall I make a patch ? 13:47:47 or just push a patch to gerrit? 13:48:21 just mark it as WIP 13:48:27 not sure if the whole thing will be killed soon, yanyanhu 13:48:45 ok 13:48:50 anyway, we can abandon the patch 13:49:24 I was also checking the way to run containers using nova with libvirt-lxc, lxd ... 13:49:44 really not sure we will support them all 13:50:20 last item, semi-autoscaling and zaqar support 13:50:41 anything to share, cschulz_ ? 13:50:45 Not much progress to report. 13:50:50 okay 13:50:58 Got caught up on other things last week. 13:51:07 BTW are you in US now? 13:51:11 speaking of a scaling request that may and may not lead to real actions 13:51:31 not yet, cschulz_ 13:51:48 I'm thinking if we can add an option to the resize request 13:52:02 for? 13:52:08 saying that this request is a "soft" one 13:52:21 What does 'soft' mean? 13:52:35 How do you envision it would be handled? 13:52:48 it may get executed, it may be not 13:53:03 How is the decision made? 13:53:08 hmm, if not, why just rejecting the request 13:53:10 when receiving such a request, we can check if there are some approvals needed before translating that request to a real action 13:53:14 why not 13:53:52 yanyanhu, it involves some approval processs sometimes 13:53:57 I guess we can achieve that goal in scaling policy? 13:54:02 sounds like an approval policy. 13:54:11 senlin doesn't know what to do actually 13:54:14 One issue is that just the request may cause a request for approval 13:54:31 Yes elynn 13:55:11 it is a little bit too late if we handle it in scaling policy, because the cluster is locked, we cannot lock it for a infinite time 13:55:13 Did some work on this previous to Zaqar 13:55:32 a new policy is better way to support approval process IMHO :) 13:55:36 today, all policis are checked with clusters already locked, that is the issue 13:55:42 Am now looking into Zaqar as the messaging mechanism to handle request and response. 13:55:54 cool, cschulz_ 13:56:09 Zaqar PTL, Fei Long Wang was an ex-ibmer 13:56:13 Yes the locking is a real issue 13:56:28 Approval response could be a long time in coming 13:56:48 That would be a hook that we provide to handle request. 13:57:05 if so, all request should support it 13:57:06 unless we say... okay, we will break the policy checking logic 13:57:17 if it is really that generic 13:57:44 so it doesn't look like a REAL request to senlin 13:57:51 it is just a tentative one 13:57:57 yes 13:57:58 It all depends on how much you want to build into Senlin as opposed to having all the decision mechanism outside. 13:58:10 that is the reason why I was thinking of adding a parameter to the request 13:58:36 just don't want to break the design logic of scaling request 13:58:37 yes, cschulz_, it is a trade-off 13:58:54 Ah, I think I see 13:59:02 existing logic of action, policy 13:59:05 right, yanyanhu, but the request is a real one 13:59:19 we need to figure out a way to get it supported 13:59:21 yes 13:59:22 somehow 13:59:27 need some discussion here 13:59:28 If you have a autoscale solution, fully closed loop, then you might need a callout mechanism for approval in some cases. 13:59:42 time's up, let's keep brain storming on this 13:59:52 thank you all, guys, talk to you next week 13:59:56 thanks 13:59:57 Yes Thanks for the thoughts 13:59:57 * regXboi looks at the clock and finds a corner 14:00:03 bye 14:00:06 #endmeeting