13:00:38 #startmeeting senlin 13:00:40 Meeting started Tue Jul 28 13:00:38 2015 UTC and is due to finish in 60 minutes. The chair is Qiming. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:43 The meeting name has been set to 'senlin' 13:00:50 hello 13:00:57 hi 13:00:59 hi 13:01:07 hello 13:01:22 hi 13:01:29 #topic add agenda items 13:01:47 #link https://wiki.openstack.org/wiki/Meetings/SenlinAgenda 13:02:04 please add topics if you have things for discussion 13:03:06 let's get started 13:03:17 #topic liberty-2 milestone targets 13:03:39 please review the work items and see if there are things missing 13:03:49 #link https://etherpad.openstack.org/p/senlin-liberty-workitems 13:04:02 I have just removed those items we have finished 13:04:55 I have a couple I am still working on. will have them in for review today 13:05:12 sounds great, jruano 13:05:22 I think we have all there 13:05:59 although some of them could be deferred to liberty-3 13:06:12 I newly assigned to heat_v1 driver, but not started yet 13:06:16 okay, we may have to 13:06:43 maybe it's time to work out a plan for liberty-3 13:06:57 were we going to try and have a release or wait for lib 3? 13:07:09 yep 13:07:21 jruano, we may need to wait for liberty 3 13:07:47 there are quite some known defects to be ironed out 13:08:02 that makes sense. stable is best :) 13:08:03 yes 13:08:26 besides that, we have some high priority todos here: http://git.openstack.org/cgit/stackforge/senlin/tree/TODO.rst 13:09:07 some of the issues have been solved 13:09:38 need an update on that to find out what are left 13:10:23 ah yes, looking it over now 13:10:28 basically, for lib-3, we will need to have the engine/action/event modules stable 13:10:58 the nova server and heat stack profile completely debugged 13:11:01 Qiming, I think maybe we should also implement a basic placement policy which provides cross-region node creation 13:11:25 yes, please add that to the TODO.rst file 13:11:26 maybe also cross-az/cloud 13:11:28 ok 13:11:39 also we will need some funtional tests 13:12:24 we will aslo need to promote some middle-priority ones to high-priority 13:12:48 yes, and I think the work item of workflow cleasing should be replaced by adding functional test 13:13:05 ok 13:13:07 sounds reasonable 13:13:27 I'm reading the FEATURES.rst file: http://git.openstack.org/cgit/stackforge/senlin/tree/FEATURES.rst 13:14:16 a lot of work :) 13:14:35 most of the items in FEATURES.rst are nice-to-have kind of features 13:15:02 each of them would need some time for design, some more time for implement and testing 13:15:19 yip, jruano 13:15:30 it would be a long journey to make things realy useful 13:15:32 :) 13:15:46 maybe if we can just identify any that need to be a part of lib 3, that would be helpful 13:15:58 agreed 13:16:09 I think the functional test and placement policy is the most important 13:16:35 may help some if time permits 13:17:15 exception handling 13:17:21 in the Tokyo summit, will be a demo in our presentation? 13:17:24 right 13:17:29 let's get it done right, once for all 13:17:49 I think we may want to complete the basic framework of exception handling 13:18:04 haiwei, jruano and some university students are working on that 13:18:16 cool 13:18:26 hopefully we can give a live demo of something really useful 13:18:40 that will be very nice :) 13:18:42 yes 13:19:26 let's spend some time prioritizing the TODO items for liberty-3 13:20:01 #action Qiming to create a etherpad for everyone to prioritize L3 items 13:20:24 let's move on 13:20:37 #topic update on complex (scaling) policy and triggers 13:20:59 well, I didn't expect it to be such a painful process 13:21:19 I have spent almost 2 weeks on this 13:21:43 the original idea was to compile all information into a single scaling policy 13:21:46 :) more complicated than we imagined before 13:22:30 in that policy, you will specify the properties for the triggers (alarm, queue notification), schedule (when to enable/disable) and handlers (different actions) 13:23:39 when writing the spec, I found it too (unnecessarily) complicated to squeeze everything into a single YAML 13:24:23 the second issue is that it makes the policy inflexible: any single property change necessitates a new policy spec 13:25:18 the third issue is that it is does not conform to our original design of "policy", which was meant to be some rules that will be checked when actions are about to take place 13:25:50 after some brainstorming with Yanyan, I have now switched to a different approach 13:26:15 we abstract external signals using a concept "Trigger" 13:26:36 we create/update/delete it as a separate resource in Senlin 13:27:15 we link Triggers to webhooks or other "endpoints" to build an auto-scaling solution 13:27:37 we can also link Triggers to webhooks or other receiving points to build HA solution 13:28:22 so ... basically, we are again developing some primitives, leaving more complicated use cases to users 13:28:33 I'd like to hear your comments on this 13:29:05 sounds almost like you are building a workflow using triggers? 13:29:28 users will build them or we can help build such kind of a workflow 13:29:56 some sample triggers are here for review/comments: https://review.openstack.org/#/c/206526/ 13:30:29 A patch for modeling various ceilometer alarm types is here: https://review.openstack.org/#/c/206527/ 13:31:46 take ceilometer alarms as an example, there are too many variants to be incorporated into a single policy 13:32:12 these alarms can be used for whatever use cases 13:34:10 comments? 13:34:15 questions? 13:34:33 or you would like to review the patchs, ;) 13:34:35 so we hope to keep the flexibility by just providing primitives 13:34:36 I will try this in next few days for demo purpose 13:34:51 of course this will also reduce the complication 13:34:53 lixinhui, it is not working yet 13:35:04 ... 13:35:11 it is just a design by code 13:35:42 i think its a good approach. let the user design the workflow using these base alarms 13:35:52 will give feedback about the patch ASAP 13:36:23 jruano, if needed, we can provide some sample "workflows" to get autoscaling up 13:36:36 yep, some "templates" 13:36:50 right 13:37:01 #topic clusters of containers 13:37:33 jruano, how are things going on there? 13:37:39 i spent some time working on this. i have coreos running within openstack 13:37:44 pretty straightforward 13:38:11 docker is natively supported within coreos, so that should be relatively easy 13:38:20 with VM clusters created? 13:38:33 kubernetes is more challenging under coreos 13:38:43 yep 13:38:46 not yet... i am still debugging a little within magnum 13:39:07 cool, pls keep the team posted 13:39:20 running into some issues creating docker bays within magnum, so this is what i am working on now 13:39:43 I traveled to Shanghai last weekend to meet some students from Tongji University 13:39:53 we have a SUR project with them 13:39:59 i will have more information on this shortly 13:40:16 they are working on this container cluster topic as well 13:40:43 they are moving pretty slow 13:40:55 just get themselves familiarized with Magnum and Senlin 13:41:36 jruano, if you have some ideas for experimentation, they are your interns 13:41:37 :) 13:41:43 lol, np 13:41:54 i will write up some notes to share 13:42:05 that would be cool 13:42:44 some of the students are already trying to modify Magnum to call Senlin APIs 13:43:19 hope we can get some POCs soon 13:43:43 ah ok... that is a little putting the cart before the horse, but thats fine 13:44:21 anyway, they will need to understand Senlin APIs first 13:45:06 #topic open discussions 13:45:47 I wanna check if cluster-polict-list problems fixed or not 13:45:59 lixinhui, it is fixed 13:46:25 please point me to the patch, thanks 13:46:30 it is an issue related to environment configuration 13:47:21 seems we should change this line to "project:%(project)s": http://git.openstack.org/cgit/stackforge/senlin/tree/etc/senlin/policy.json#n3 13:47:45 we don't have project_id in the context structure 13:48:10 need to dig more on the impact on other code 13:48:21 yes 13:48:35 otherwise, that rule will not take effect 13:49:12 right, you can do almost nothing if the project doesn't match 13:49:20 yes 13:49:41 any outstanding issues met? 13:50:46 jruano, we may need to work out a draft design for container clusters 13:50:53 i think so 13:51:15 a design that will be applicable to both docker and k8s 13:51:24 let me compile some notes as a starting point 13:51:49 it is perfectly okay if we only have docker clusters implemented by l3 13:51:57 cool, I think that will help all of us to understand it more clearly 13:52:30 anything else? 13:52:38 yes... the metadata for k8s is significant 13:52:47 nope from me 13:53:04 nothing for me 13:53:22 lixinhui, still around? 13:53:47 yes 13:54:02 nothing except the policy list 13:54:03 since you are more interested into placement policy, could you help take a look at the cross-region implementation in heat? 13:54:26 yes, I am looking at it 13:54:41 we need to move that to Senlin -- a concensus from heat team back in Vancouver 13:54:51 cool 13:54:53 and I just proposed a patch to add this work item, you can add you name behind it if it's ok for you :) 13:55:05 shout out if you need help 13:55:30 definitly, I will 13:55:38 last call 13:55:47 nothing else from me 13:55:50 4 13:55:55 3 13:56:01 #endmeeting