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