13:03:35 #startmeeting senlin 13:03:36 Meeting started Tue Sep 22 13:03:35 2015 UTC and is due to finish in 60 minutes. The chair is Qiming. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:03:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:03:39 The meeting name has been set to 'senlin' 13:04:03 morning/evening ... 13:04:24 hello 13:04:26 hi 13:04:28 evening 13:04:50 feel free to add/modify meeting agenda 13:04:52 https://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Weekly_Senlin_.28Clustering.29_meeting 13:06:24 okay, let's get started 13:06:29 #topic container clustering 13:07:15 just got an update from the SUR team 13:07:20 overall progress is good 13:07:54 some interns has built a client for senlin to talk to k8s, and they are testing it 13:08:40 some interns have tried creating k8s clusters by having magnum invoking senlin, using a heat profile 13:09:04 they are still working on improving the yaml files used in this context 13:09:29 this is what we want to show in the summit? 13:09:33 for the demo 13:09:58 some interns have tried collecting runtime metrics from docker using CAdvisor, triggering the scaling using alarms generated from these metrics 13:10:48 yes, haiwei_, this is the work we want to show case 13:11:07 the second one or the third one? 13:11:23 the autoscaling work 13:11:23 or all of these? 13:11:27 ok 13:12:01 we are evaluating different options to glue the two layers of entities together, in the magnum context 13:12:46 Qiming, you mean the scaling of both VMs and containers? 13:12:48 there will be open questions, but I think that is okay 13:12:52 yes 13:13:11 currently, triggering VM scaling using container-layer metrics is working 13:13:25 we are discussing whether the other path is worth to do 13:13:32 ok 13:13:36 we are also looking into load-balancing options 13:13:51 about the lb part, I think they met some issues 13:14:04 yanyan, please help with the team and see if the version conflicts problem is solved 13:14:11 I guess the neutron lb version in their env is still v1 13:14:12 sure 13:14:20 there seems to be some LB configuration problem 13:14:30 so they mentioned that they have version problem 13:14:35 ok 13:14:43 yes, need to engage at this stage 13:14:54 will re their mail and discuss with them 13:15:52 thanks. 13:16:11 any questions/comments on this work? 13:16:35 is there a deadline for this? 13:17:10 we want to see the whole thing up and running by the end of this month 13:17:47 anyone interested in this can leave a comment here: https://etherpad.openstack.org/p/magnum-senlin 13:18:05 #topic Trigger implementation 13:18:06 nice 13:18:29 cool 13:18:39 so ... we decided a few weeks ago to provide an abstraction called 'Trigger' 13:19:15 yep 13:19:28 basically, it would be a wrapper of ceilometer/aodh alarms, monasca alarms, zaqar queues ... things that can trigger an action on senlin entities: clusters, nodes ... 13:20:06 A user will decide what tools they want to use 13:20:25 the basic CRUD logic is already committed 13:20:46 however, this work is blocked somehow by two things 13:21:13 1. ceilometer alarming service is offcially separated from ceilometer into aodh 13:21:37 since senlin is not talking to any xyz service using xyzclient, we are using openstacksdk 13:22:09 so we need to add aodh support into openstacksdk first, then we can experiment with "ceilometer/aodh" alarms first 13:22:41 the problem is that openstacksdk is blocking any resource types at the moment 13:23:58 so ... we need a workaround, we will host these bits temporarily in senlin codebase and migrate them to openstacksdk later 13:23:58 or else we will be blocked for a long time .. 13:24:17 I'm working on that 13:24:46 questions? 13:25:09 so the first step is support trigger based on aodh alarm 13:25:20 yes 13:25:41 aodh is using ceilometer-client, so it is almost the same to support ceilometer-client? 13:25:42 ok, after the framework of trigger is done, we add more trigger tyep 13:25:45 type 13:25:47 I'm not sure about monasca's status, or the usability of zaqar so far 13:26:08 haiwei_, if you using ceilometerclient, everything remains the same 13:26:40 there will be an redirection from ceilometer to aodh concerning alarm operations 13:26:42 zaqar is a little different I think, maybe we need a new handler type to support it 13:27:09 yep, it is not longer a webhook 13:27:26 it will be totally about message queue 13:27:54 yes 13:27:57 #topic heat resource type support 13:27:58 aodhclient== ceilometer-client? 13:28:20 haiwei_, aodhclient? 13:28:28 hi, haiwei_ , I think there is just ceilometer client 13:28:36 don't know if there is such thing, we won't use it even there is a new client 13:29:10 ok, I need to learn adoh first 13:29:26 so ethan has kindly offered to take senlin back to heat 13:29:26 https://review.openstack.org/#/c/226180/ 13:29:30 aodh 13:30:03 yea, I'm working on this 13:30:15 still need to discuss how to implement it. 13:30:31 we have quite a few things to work out 13:30:41 I don't quite get Kanagaraj Manickam's point. 13:31:13 He said senlin is part of requirements.txt 13:31:19 But I don't see it. 13:31:31 above all design considerations, we'd strive to maintain compatibility with heat ResourceGroup ... 13:31:43 elynn, it is a typo 13:31:57 senlin is not listed there yet 13:32:20 in big tent, will it be? 13:32:54 among the concepts (objects) senlin exposed, the top priority, in my view, is cluster and node 13:33:02 it doesn't matter I think 13:33:12 yea 13:33:19 Yes we need to compatible with heat RG, question is when. 13:33:38 we need to put 'UNSUPPORTED' as support status once the code is in 13:33:53 yes, maybe cluster is enough for compatible with heat Rg 13:33:55 elynn, from the very beginning 13:34:21 cluster is meant to be a superset in terms of features from RG 13:34:48 if not, we need to improve cluster design/implementation 13:35:24 however, we may don't need to model senlin profile in Heat 13:35:45 from Heat's perspective, it is just an implementation detail 13:36:28 the big issue as I see it is about the 'update' operation 13:36:38 So the resources for senlin would be like OS::Senlin::Cluster OS::Senlin::Node OS::Senlin::ResourceGroup ? 13:36:39 which is the only operation for you to change things in Heat 13:36:56 no OS::Senlin::ResourceGroup 13:37:17 so OS::Senlin::Cluster replace Heat RG resource? 13:37:31 we can add an entry in the default environment file to map OS::Heat::ResourceGroup to OS::Senlin::Cluster 13:38:08 even that mapping would be a mid-term work 13:38:30 ok, I got it. 13:38:39 so both properties and attrs of OS::Senlin::Cluster should be completely compatible with RSG 13:38:45 so what's the problem for stack-update? 13:38:46 the near-term is to make OS::Senlin::Cluster work, cover all ResourceGroup features by invoking senlin APIs 13:39:06 or maybe superset of the one of RSG 13:39:06 stack-update -> resource update 13:39:16 resource update -> cluster ? 13:39:28 it could be cluster resize, cluster update 13:39:50 and nested stack update 13:40:16 heat doesn't have to see the nested stacks 13:40:54 RG <=> cluster of heat stacks 13:41:04 heat stacks here is already the nested stack 13:41:14 and we implement it using profile 13:41:28 en 13:41:34 when template used for the inner stack changes, we change the profile 13:41:55 when template is not changed, we may still need to do resize operations 13:42:10 ok 13:42:18 we got to be very careful at every step 13:42:48 I've see apis in senlin for cluster resize, is it enough ? 13:42:57 when doing this, we should think in Heat's philosophy, not the other way 13:43:23 yep, I'm pretty sure it is a superset of RG's capability 13:43:53 elynn, we need to sit down and work out the details 13:44:04 yes... 13:44:49 yet another blocker is that we need to release senlinclient first 13:45:06 make it into the global requirements so that other projects can invoke us 13:45:25 I'll ask around how to do this 13:45:40 and I think the way invoking senlinclient is a little different from the client of other services ? 13:46:21 sadly I won't be avail 9am-13pm tomorrow 13:46:41 9am? 13:46:53 not 9:30 13:46:55 but we can discuss this via email if f2f discussion is not possible 13:47:00 senlinclient now didn't provider api to call directly, isn't it? we can only use shell commands to call it . 13:47:04 sigh, the meeting was rescheduled 13:47:14 ... 13:47:40 9-11, meet, 11-12, all-hands, 12-13 lunch meet 13:47:44 elynn, yes, I think so. But we can build sdk session first and use it to creation senlinclient instance I think 13:48:03 right, there is an allhands tomorrow... 13:48:17 we can work out some pseudo code first 13:48:37 #topic open discussions 13:48:58 11 mins 13:49:15 then I have another meeting, no meat 13:49:44 did you have dinner? 13:49:55 so other than the topics we touched so far 13:50:19 I'd encourage everyone to start signing up to mitaka work items 13:50:20 https://etherpad.openstack.org/p/senlin-mitaka-workitems 13:50:56 yanyan, I did, without being far from keyboard 13:51:14 sigh... 13:51:57 anything else, before we release this channel? 13:52:03 oh... 13:52:08 no from me 13:52:13 no 13:52:37 I've sign my name on some item ;) 13:52:53 Don't know if anyone are working on zaqar or not... 13:53:05 okay, thanks for joining, and your hard work, :) 13:53:15 until next time 13:53:19 #endmeeting