13:02:35 <Qiming> #startmeeting senlin 13:02:36 <openstack> Meeting started Tue Nov 24 13:02: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:02:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:02:40 <openstack> The meeting name has been set to 'senlin' 13:02:51 <alex_xu> Liuqing: no, we have, but end early.... 13:03:09 <Qiming> okay, seems the topic remained unchanged, :) 13:03:11 <yanyanhu> alex_xu, :) 13:03:21 <elynn> o/ 13:03:26 <Qiming> #link https://wiki.openstack.org/wiki/Meetings/SenlinAgenda 13:03:41 <Qiming> pls review agenda and see if you have topics for discussion 13:04:49 <Qiming> #topic Mitaka work items 13:05:00 <Qiming> #link https://etherpad.openstack.org/p/senlin-mitaka-workitems 13:05:31 <Qiming> with recent changes, we are enforcing an implicit rule for claiming todo items 13:06:14 <Qiming> whenever someone claims a work item, pls make sure an item is recorded in the etherpad so that we can review it on weekly meetings 13:06:17 <yanyanhu> yes, a description of it can be found in the first paragraph of TODO.rst 13:06:38 <Qiming> heat resource type support 13:06:51 <elynn> yes, I'm working on it. 13:06:57 <Qiming> elynn, any help needed? 13:07:05 <elynn> about profile attrs 13:07:24 <elynn> I saw your comment, do you mean we should remove them all? 13:07:35 <Qiming> okay, I don't see those are useful attributes 13:08:05 <Qiming> if the profile has a 'name' property, usually we don't need a 'name' attribute for it 13:08:07 <elynn> yes, it's not useful for now... 13:08:49 <elynn> ok, I will remove them all in next patch. 13:08:51 <Qiming> my suggestion would be keep the attributes set a minimum, add them later when needed 13:09:12 <Qiming> once things are there, you will never get a chance to remove it 13:09:25 <Qiming> but if it is missing, we can always fix it, ;) 13:09:45 <elynn> got it, seem 'name' & 'metadata' attrs in cluster should be removed too. 13:09:46 <Qiming> senlinclient tests 13:10:07 <Qiming> elynn, yep, just follow heat's convention there 13:10:39 <elynn> ok 13:10:58 <Qiming> haiwei has submitted some patches for client test cases 13:11:20 <haiwei_> yes, will continue to do it 13:11:28 <Qiming> great 13:11:32 <haiwei_> the pace is a little slow 13:13:04 <Liuqing> i could help improve the unit test of senlinclient 13:13:41 <haiwei_> thanks, Liuqing 13:14:18 <Liuqing> my pleasure, 13:14:34 <Liuqing> Qiming seems offline 13:15:04 <yanyan> yes, I also dropped 13:15:09 <yanyan> network issue I think 13:15:23 <elynn> what's the problem... 13:16:19 <yanyan> not sure, let me ping him 13:16:19 <elynn> seems Qiming haven't back 13:17:03 <haiwei_> should we continue? 13:17:19 <Qiming_> sigh 13:17:42 <elynn> welcome back :) 13:17:51 <Qiming_> network very unstable these days 13:18:04 <Qiming_> anywhere in China 13:18:16 <Qiming_> f* the gvmt 13:18:28 <zhipeng> haha 13:18:37 <zhipeng> vpn is not stable any more 13:18:58 <Qiming_> nothing is stable 13:18:59 <Liuqing> i use shadow socket 13:19:07 <Qiming_> okay, back to agenda 13:19:26 <Qiming_> I am working on fixing the 400/404 status code issues 13:19:49 <Qiming_> it turned out to be a huge task 13:19:57 <Qiming_> will continue to work on that 13:20:10 <Qiming_> health policy 13:20:29 <Qiming_> still not sure wether we should do polling by ourselves 13:20:52 <Qiming_> talked with xinhui (still at San Francisco this week) 13:20:56 <elynn> If we don't, what project can? 13:21:13 <Liuqing> one question, how we define failure of node? 13:21:16 <Qiming_> elynn: no answer 13:21:27 <Qiming_> Liuqing: good question 13:21:52 <Qiming_> even if we provide some polling operations, it will be the last resort 13:22:13 <Qiming_> I'd really prefer some external monitoring software/service to do that 13:22:26 <yanyan> hi, Qiming_, as liuqing's question, maybe we should let the implementer of profile to decide it I think 13:22:34 <Qiming_> if we are to do it, we need to have all profile types support a do_check() method 13:23:02 <Qiming_> yep, it would be a per-profile-type thing 13:23:20 <Qiming_> even with that, it may and may not be useful 13:23:37 <yanyan> that is true 13:23:59 <Qiming_> even nova tells you a server is still there, does it mean anything at all? 13:24:30 <Qiming_> your service inside that server may have already crashed 13:24:31 <elynn> if we do monitoring, that would be too big for this project... 13:24:56 <Qiming_> elynn: that is true 13:24:56 <yanyan> elynn, we won't touch monitoring itself I think 13:25:05 <Qiming_> we are very very cautious on this 13:25:32 <yanyan> we just try to find a way to help user leverage existing monitoring service to decide the health status of a node 13:25:32 <Qiming_> need to discuss with julio on the receiver design 13:25:37 <Liuqing> but if we implement that , it will be very very cool for OpenStack ecosystem 13:25:52 <Qiming_> hopefully we can hook senlin to any external monitoring 13:26:01 <elynn> I think there's also two levels of health monitor here, vm level and software level. 13:26:26 <Qiming_> that is where I have been struggling 13:27:09 <Qiming_> maybe we still need to provide some very basic health management, but for advanced features, you will have to turn to other monitoring services/software 13:27:26 <yanyan> Qiming_, sure 13:27:43 <Qiming_> before we have a clear vision/design 13:27:47 <Liuqing> agree 13:27:54 <Qiming_> you won't see any code, :) 13:28:18 <Qiming_> triggers, emm 13:28:33 <Qiming_> do we want to keep them ? 13:28:50 <Qiming_> or we delete them completely from senlin? 13:28:53 <haiwei_> why not 13:29:11 <Qiming_> "why not" means? 13:29:19 <haiwei_> I mean why not keep them 13:29:49 <Qiming_> senlin trigger-create -t os.aodh.alarm -s some_spec alarm1 13:30:12 <Qiming_> why are we doing this? 13:30:17 <yanyan> hmm, IMHO, it is not necessary to keep it in senlin 13:30:30 <elynn> What's the benefit if we keep them? 13:30:40 <Qiming_> why don't we tell the user to use ceilometer/aodh alarm-create directly? 13:31:05 <yanyan> since there are many ways user can define an alarm, e.g. using ceilometer/aodh/monasca API, or using heat 13:31:09 <yanyan> yea 13:31:15 <Liuqing_> is that the reason for deleting triggers? 13:31:22 <Qiming_> the original thought is that we will support complex policies 13:31:28 <elynn> agree to remove them before anyone aware of them 13:32:08 <elynn> or hide the apis for triggers. 13:32:13 <Qiming_> by 'complex policies', I mean a policy that contains the trigger source, trigger condition and the handler 13:32:42 <Liuqing_> yep, i got it 13:32:44 <Qiming_> there is no real meat even if we support such a concept in senlin 13:33:10 <Qiming_> it looks sexy, but it also looks very inflexible 13:33:37 <Qiming_> you won't be able to support monitoring solutions other than the one you started with 13:33:54 <Qiming_> so ... remove it? 13:34:02 <yanyan> +1 from me 13:34:11 <Liuqing_> +1 13:34:29 <elynn> no doubt +1 13:34:45 <haiwei_> honestly I have no idea, removing is OK i think 13:34:48 <Qiming_> okay, I'll copy them to some secret place before removing them 13:35:17 <Qiming_> I spent a lot time trying to figure out the commonalities among the so many different flavors of 'ceilometer alarms' 13:35:52 <Qiming_> then we don't have todos about monasca, :) 13:35:59 <yanyan> yes 13:36:08 <Qiming_> what a relief! 13:36:18 <elynn> less is more 13:36:19 <Qiming_> update operation for profiles 13:36:27 <Qiming_> elynn: +100 13:36:43 <yanyan> ok, this is in good progress I think 13:36:44 <Qiming_> we can always add them back when there are justifications 13:37:11 <Qiming_> cool 13:37:21 <yanyan> but we need to add some support to sdk before we start some work in senlin side 13:37:25 <Qiming_> but I'm still seeing a long way to go 13:37:30 <yanyan> yep 13:37:47 <Qiming_> update to flavor is a 'resize' ? 13:37:52 <yanyan> network and image update support is just a start 13:37:58 <yanyan> I guess so 13:38:04 <Qiming_> sigh... 13:38:11 <haiwei_> what is the flavor? 13:38:12 <yanyan> but that really depends on Nova's support on it 13:38:31 <haiwei_> instance flavor? 13:38:32 <yanyan> need do more investigation on related Nova API 13:38:38 <yanyan> haiwei_, yes 13:38:43 <Qiming_> nova client say one thing, nova server says another, nova api doc says several other things 13:39:32 <Qiming_> no idea where we are regarding the 'receiver' design, will catch up with julio later 13:39:40 <yanyan> umm, this is a thing we need to be careful about... 13:39:43 <haiwei_> updating is really difficult 13:39:56 <yanyan> to ensure the implementation is correct 13:40:07 <Qiming_> lock breaker 13:40:12 <yanyan> haiwei_, yes 13:40:44 <elynn> since last meeting 13:40:55 <elynn> haven't got time to update the patches. 13:41:06 <Qiming_> need some careful reviews, it is related to the stability of the core engine 13:41:29 <elynn> I will add a function to set actions to fail if they attach to dead engine. 13:41:30 <Qiming_> don't want to push this 13:41:40 <Qiming_> okay 13:41:57 <yanyan> elynn, I just updated the etherpad to add some in-progress patches about lock breaker 13:42:06 <elynn> Maybe need a functional tests for them 13:42:17 <yanyan> elynn, sure 13:42:20 <Qiming_> okay, moving on 13:42:21 <elynn> yanyan: Thanks! 13:42:31 <Qiming_> #topic api and docs 13:42:46 <yanyan> since the patch about pre_test_hook just got merged, I will refactor the functional test to make it work in one or two days 13:43:25 <haiwei_> cool 13:43:32 <Qiming_> I have spent some time going through the so many sources of info about documenting apis, api guidelines 13:43:56 <Qiming_> won't be able to go through every detail in this meeting 13:44:24 <Qiming_> there are things still under discussion 13:44:35 <haiwei_> I have confirmed the 'location header' from the api-wg guy, he said it mean 'response header' 13:44:47 <Qiming_> for example, the format of 'links' to be returned to client 13:45:03 <Qiming_> 'with_count' query string 13:45:11 <Qiming_> 'POST' for actions 13:45:18 <Qiming_> 'Cache-Control' 13:45:34 <Qiming_> constraints: max/min values 13:45:40 <yanyanhu> many issues need to fix 13:45:43 <elynn> do you know where I can see the docs for senlin in openstack website? is there any? 13:45:55 <Qiming_> there are new specs about rewriting api docs using Swagger 13:46:23 <Qiming_> there are many destinations for publish/gating 13:46:37 <Qiming_> docs.o.o, developer.o.o, specs.o.o ... 13:46:53 <Qiming_> still working on that 13:47:02 <elynn> all I know is the wiki page for senlin. 13:47:16 <Qiming_> there is still release notes thing 13:47:29 <yanyanhu> just as ethan said, can we find a way to let user read senlin doc in an easier way? 13:47:40 <yanyanhu> some colleagues also asked us this question 13:47:50 <Qiming_> so, after the initial learning phase, we would need some liaisons for jobs 13:48:00 <Qiming_> https://wiki.openstack.org/wiki/CrossProjectLiaisons 13:48:39 <Qiming_> yanyanhu: we have docs for users, docs for developers, just need to figure out how to publish them 13:48:49 <Qiming_> which site, how to set up gate to do this 13:48:50 <yanyanhu> Qiming_, yes 13:49:11 <yanyanhu> we have them there actually, just need to figure out a way to let user check it easily 13:49:25 <Qiming_> if any of you have interests on any of these cross-project topics 13:49:26 <yanyanhu> yea 13:49:29 <Qiming_> please let me know 13:49:30 <elynn> ok, I got what you mean. 13:50:01 <haiwei_> for senlin, it mainly means SDK? 13:50:09 <yanyanhu> will check this page 13:50:10 <haiwei_> the cross-project 13:50:37 <haiwei_> and oslo? 13:50:41 <yanyanhu> haiwei_, also some other services who want to talk with us or we want to talk with 13:50:45 <Qiming_> haiwei_: no, it means release management, api workgroup, product working group ... 13:51:09 <Qiming_> and hopefully, a liaison for magnum 13:52:01 <Qiming> #topic blueprints and bugs 13:52:18 <Qiming> any high priority items? 13:52:44 <yanyanhu> I think we need to recheck all of them and set them to proper status 13:53:11 <haiwei_> yanyan's bug? 13:53:29 <Qiming> seems we have already covered bluepints on the etherpad page 13:53:35 <haiwei_> can we decide the priority by ourselves? 13:53:52 <yanyanhu> I mean all of those existing bugs and bps, especially some ones have been done 13:54:16 <Qiming> 29 bugs 13:54:34 <haiwei_> i know, I mean your bug reported today is a high priority? 13:54:35 <Qiming> 10 medium importance 13:55:04 <elynn> I think it's good to set priority for this bugs and BPs, at least let others outside knows that what we are working on. 13:55:09 <yanyanhu> oh, haiwei_ I guess so 13:55:12 <Qiming> some are outdated 13:55:18 <yanyanhu> yes 13:55:30 <yanyanhu> we should cleanse them 13:55:30 <haiwei_> I think the bugs related to node creation should be high priority 13:55:43 <elynn> since they may not know where the etherpad is. 13:55:47 <yanyanhu> and mark those ones have been done to Fix released? 13:55:57 <Qiming_> yes, that is something we need to do, review them all 13:56:21 <Qiming_> fix-released won't be manual 13:56:47 <yanyanhu> oh 13:56:58 <Qiming_> it will be taken care of by some ci scripts 13:57:03 <yanyanhu> since I found no any bug is closed in Senlin bug list 13:57:22 <Qiming_> that is because we haven't create a formal release 13:57:47 <yanyanhu> ok, understand 13:58:02 <Qiming_> #action review bug list and reset status 13:58:13 <yanyanhu> thanks 13:58:20 <haiwei_> and again, any bug fix should contain a bug report, will be strict about that in the coming review 13:58:59 <yanyanhu> haiwei_, agree 13:59:19 <yanyanhu> and also set the priority as elynn suggested 13:59:19 <elynn> yea, let's be formal ;) 13:59:36 <Qiming_> need to work hard 13:59:50 <Qiming_> we are not making a lot of progress recently, to be honest 13:59:57 <haiwei_> the benefit is when we make a release, we can say we have fixed how many bugs in this cycle 14:00:12 <Qiming_> haiwei_: that can be solved using releasenotes 14:00:23 <Qiming_> okay, time is up, thx for joining 14:00:26 <Qiming_> #endmeeting 14:00:28 <haiwei_> yes, if we have reported it 14:01:03 <Qiming> #endmeeting