15:00:02 #startmeeting Ceilometer 15:00:03 Meeting started Thu Dec 27 15:00:02 2012 UTC. The chair is nijaba. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:03 #meetingtopic Ceilometer 15:00:03 #chair nijaba 15:00:03 #link http://wiki.openstack.org/Meetings/MeteringAgenda 15:00:03 ATTENTION: please keep discussion focused on topic until we reach the open discussion topic 15:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:06 The meeting name has been set to 'ceilometer' 15:00:08 Current chairs: nijaba 15:00:12 Hello everyone! Show of hands, who is around for the ceilometer meeting? 15:00:12 o/ 15:00:13 o/ 15:00:16 o/ 15:00:17 0/ 15:00:33 o/ 15:01:01 nice. I see a few new nicks. welcome 15:01:09 #topic actions from previous meeting 15:01:19 #topic nijaba to schedule v2 review for next meeting 15:01:19 #info Done, see meeting agenda 15:01:30 #topic nijaba to link API v2 proposal to appropriate bp 15:01:30 #info done, I added the link to the whiteboard of https://blueprints.launchpad.net/ceilometer/+spec/api-server-pecan-wsme 15:01:43 #topic jd__ write a wiki page on how to participate to the bug squashing day 15:01:43 #info done, see http://wiki.openstack.org/Ceilometer/Contributing and http://wiki.openstack.org/Ceilometer/BugSquashingDay/20130104 15:01:50 jd__: around? 15:02:31 o/ 15:02:38 I guess he'll come by later... 15:02:48 #topic nijaba to organize new vote next week for meeting on Jan 2nd 15:02:48 #info Done, see meeting agenda topic 15:02:58 #topic nijaba to approve synaps's bp 15:02:58 #info done see https://blueprints.launchpad.net/ceilometer/+spec/synaps-integration which is the overarching bp 15:03:23 #topic nijaba to organixe next thu as bp cleanup day 15:03:23 #info lots of cleanup done, but see subsequent topic about remainder 15:03:35 #topic nijaba to reschedule topic about healthmon for next week when lianhao is around 15:03:35 #info Done, see meeting agenda topic 15:03:46 #topic dhellmann experiment with passing arrays of parameters to wsme for queries 15:03:46 dhellmann, have you made it back yet? 15:04:03 I've finally caught up with email, and have this task on my list for this week 15:04:25 should you reassign the task to yourself for next meeting? 15:04:52 I did talk to Christophe about it, and he agrees that if it doesn't work the way I think, without the [], then it would be a good enhancement 15:05:06 #action dhellmann experiment with passing arrays of parameters to WSME for queries 15:05:10 great 15:05:33 the few remaining actions are for jd__ whom does not seem to be around :( 15:05:56 #topic jd__ announce the bug squashing day on the ml 15:06:09 I have not seen the announce, have you? 15:06:16 I've seen it 15:06:16 at least not on the ml 15:06:18 I think I saw a blog post 15:06:31 I've seen it on the ml 15:06:40 ok, thanks #info done 15:06:46 #info done 15:06:49 oh, yeah, it was on Dec 24 15:06:58 #topic jd__ megatweet about the bug squashing day every hour 15:06:58 #info Done, please RT :) 15:07:25 I believe this was done, right? 15:07:34 err 15:07:35 #link https://lists.launchpad.net/openstack/msg19657.html 15:07:45 #topic jd__ rename api to api-v2 and api-v1 to api 15:07:45 I believe this was done, right? 15:07:49 yes 15:08:00 it's either done, or waiting for review, but I did see a changeset 15:08:07 #info done 15:08:10 done 15:08:21 yeah, jd__ is here!! 15:08:32 always :-) 15:08:41 but not my IRC client :) 15:08:48 That's it for last week action, I think 15:09:08 topic Meeting on Jan 2nd? 15:09:08 So, the question remaining is will there be enough people to have a meeting on Jan 2nd. 15:09:21 asalkeld has already indicated that he should be available, what about others 15:09:28 #startvote on january 2nd at 21UTC, I plan to be? present, absent 15:09:29 Begin voting on: on january 2nd at 21UTC, I plan to be? Valid vote options are present, absent. 15:09:30 Vote using '#vote OPTION'. Only your last vote counts. 15:09:36 #vote absent 15:09:40 #vote absent 15:09:45 #vote absent 15:09:56 #vote present 15:10:00 #vote absent 15:10:10 #vote absent 15:10:24 jd__: ? 15:11:20 #vote present 15:11:31 #endvote 15:11:32 Voted on "on january 2nd at 21UTC, I plan to be?" Results are 15:11:33 absent (5): yjiang5, nijaba, llu-laptop, graflu0, zehndton 15:11:34 present (2): jd__, dhellmann 15:12:00 so we'll have at least 3 core devs present I think it is enough to hold a meeting 15:12:04 who wants to chair? 15:12:15 I can do that 15:12:36 #agree meeting on jan 2nd will be chaired by jd__ 15:12:44 thanks jd__ 15:12:53 thanks, jd__ 15:12:57 #topic Discuss heathmon/ceilometer duplication and differences http://wiki.openstack.org/Ceilometer/CeilometerAndHealthnmon 15:13:13 llu-laptop: the floor is yours 15:14:01 reading your wiki page, it seemed to me that it is a good candidate to integration via multi-publisher 15:14:05 the question is how we want to integrate the effort of healthnmon/ceilometer, depends on the data models are quite different 15:14:12 as theire data model is very different 15:14:46 from what I understood, as nijaba said, this is a use case for multi-publisher 15:14:54 llu-laptop: consumer through multi-publisher would seem more appropriate indeed 15:15:25 is the data being used in a way that we could eventually reproduce using our API? 15:15:26 nijaba: agree, but possible for pyhsical device, we will need implement in ceilometer side, right? 15:15:43 so this means we should put healthnmon's agent work(getting raw data) into ceilometer agent? 15:15:53 yjiang5: for physical device, do you mean bare-metal servers or hypervisors? 15:15:58 llu-laptop: thatś what I would propose 15:16:08 dhellmann: hypervisor side. 15:16:16 yjiang5: ok 15:16:37 I think we should also consider the bare-metal servers 15:16:54 integrating by moving data collection into the ceilometer agent and then having healthnmon receive the data through our publisher seems like a good first step 15:17:17 so the proposal would be: a) implemented missing meters in ceilometer, b) integrate healthmon through multi-publisher ? 15:17:24 after that, I would like to explore options for eliminating the need for separate storage, too (it isn't clear whether that is realistic) 15:17:26 I'm glad the multiple publisher patch will have 3rd consumer :) 15:17:29 nijaba: likely 15:17:39 dhellmann: +1 15:17:42 nijaba: agreed 15:17:48 does anyone disagree? 15:18:25 #agree healthmon integration: a) implemented missing meters in ceilometer, b) integrate healthmon through multi-publisher 15:18:25 the alerting features seem to have some overlap with the requirements for Heat, so there may be room to combine efforts there, too, as a third phase 15:18:47 dhellmann: right 15:19:07 llu-laptop: do you mind reporting the result on your wiki page? 15:19:25 ok. I'll do it 15:19:37 llu-laptop: would we need to add any information to what we currently publish to make the integration easier (or possible)? 15:19:57 #action llu-laptop to report agreement result to wiki page http://wiki.openstack.org/Ceilometer/CeilometerAndHealthnmon 15:20:09 I mean metadata, not the meters we are not yet collecting 15:20:38 thanks llu-laptop, very nice analysis 15:20:44 dhellmann, sorry I didn't understand your questions. what kind of metadata are you talking about? 15:21:17 llu-laptop: well, I'm not really sure :-) Something like a property of an instance or event that we ignore or just don't publish now. 15:21:49 say we have an event that you're interested in, does it have all of the information about that event that you would need to populate your data model completely? 15:22:17 I guess that level of analysis may take more time, though, and be part of doing (b) 15:22:19 Well, I think there is many libvirt information missing in ceilometer, compared to healthnmon, 15:23:19 ok. we'll need to get a list of those items, eventually. maybe in the wiki page associated with the blueprint? 15:24:10 nijaba: I think llu-laptop himself is not healthnmon developer, so should we discuss the conclusion with healthnmon team? 15:24:24 yjiang5: yes, we now need some bp created and to identify someone to implent the plan 15:24:38 ok, I'll do a full detailed analysis of what needs to be got from underlying hypervisor to feed the 'greedy' healthnmon data sink. Of course, the healthnmon team's help would be greate 15:24:46 yjiang5: possibly someone from healthmon 15:25:09 I would say that there is no point of doing this work without them... 15:25:31 ah, I thought llu-laptop was on the healthnmon team. we definitely need them for full integration, but we could start on (a) without them, I think 15:26:03 I can take the action of reaching to them with the result... 15:26:13 and report what their plans are 15:26:23 unless someone else wants to do it 15:27:11 #action nijaba to get in touch with the healthmon team to see what their reaction is to our plan for integration 15:27:25 shall we move to the next topic? 15:27:31 ep 15:27:32 one more thing, about the physical monitoring 15:27:37 er, yep 15:27:52 llu-laptop: sure, go ahead 15:28:08 the healthnmon can only monitor the physical device where hypervisor runs, how about ohter physical device, 15:28:17 https://blueprints.launchpad.net/ceilometer/+spec/monitoring-physical-devices 15:28:38 I don see any reason why we could not monotor other nodes 15:29:11 Do we plan to have a unified way for the ceilometer agent to reporting such kind of data? or are we ok if we have duplications here 15:29:12 I'm not sure. 15:29:48 the issue is how can it be linked to something that can be of use. 15:29:58 monitoring that part of the infrastructure is already possible with so many other tools 15:30:06 physical server's data in healthnmon is got from underlying libvirt 15:30:13 I think we should stay focused on monitoring the cloud itself 15:30:49 we care about the hypervisor servers for that, because the data can be used by the scheduler eventually 15:30:50 dhellmann: agreed, but we could have nodes which are bare metal instances 15:31:01 nijaba: bare-metal instances are a different story 15:31:13 they are instances, and we should monitor them 15:31:16 I'm aware of work on power comsuption for cloud based on monitoring power usage of bare-metal hosting servers FWIW 15:31:37 but nova api nodes, or glance servers, seem like they are covered elsewhere 15:31:44 I mean work based on Ceilometer infrastructure 15:31:44 jd__: outside of ceilometer, right? 15:32:00 jd__: I think host power comsumption is helpful even in hypervisor situation. 15:32:09 jd__: ah, I have not seen any bp on the subject 15:32:12 nijaba: providing Ceilometer pollster 15:32:34 interesting 15:33:08 it's still at an early stage (prototype) but it's something that's planned to be done since Ceilometer is has a good infra for that 15:33:33 neat. we should invite those prototypers to join our meetings 15:33:34 that's a good use case for making it easy to push data into ceilometer. 15:33:41 +1 15:33:56 nijaba: yes, I'm trying hard to bring them into OpenStack :) 15:34:07 hehe, good! 15:34:10 it's working but it takes time :) 15:34:31 it does... 15:34:45 shall we move on 15:34:46 ? 15:34:52 I think so 15:35:00 #topic API bv2 proposal review http://wiki.openstack.org/Ceilometer/blueprints/APIv2 15:35:14 dhellmann: have you had time to review this? 15:35:26 I don't think I've looked at the most recent incarnation 15:35:32 I did look at an early draft 15:35:32 I have linked it to your pecan-wsme bp 15:35:49 I think the only concerns I had were with the variability of some of the output 15:36:29 WSME really wants types to be statically defined for consistency, so making fields optional may make the returned data structure a bit ugly 15:36:50 I like the general direction, though, and agree that we should move some of the path components to query parameters 15:37:17 dhellmann: should you work on improving the current proposal for next meeting 15:37:17 yeah last time discussing with asalkeld the conclusion was we just need /meters, and query parameters 15:37:19 ? 15:37:19 it will make using and documenting the API a good bit simpler 15:37:49 nijaba: I think the action I had about experimenting with query parameters was related to this, too 15:37:58 sounds good 15:38:57 I'll reschedule the topic for jan 2nd meeting then 15:39:05 sounds like a plan 15:39:10 agreed 15:39:22 #action API v2 topic to be continued on jan 2nd 15:39:28 #action nijaba API v2 topic to be continued on jan 2nd 15:39:53 #topic blueprints cleanup 15:40:01 #info So I have spent most of the morning cleanup our bps. You should have received notification if I changed a bp you are registered on. 15:40:01 Any questions about the changes I made? 15:40:46 Not from what I received :) 15:41:00 nope 15:41:08 no 15:41:22 #info The following bp are still needing more definition and an assignee or will otherwise be retargeted for H. 15:41:22 #link https://blueprints.launchpad.net/ceilometer/+spec/move-listener-framework-oslo 15:41:22 #link https://blueprints.launchpad.net/ceilometer/+spec/meter-post-api 15:41:22 #link https://blueprints.launchpad.net/ceilometer/+spec/non-libvirt-hw 15:41:22 #link https://blueprints.launchpad.net/ceilometer/+spec/rpc-zeromq 15:41:23 #link https://blueprints.launchpad.net/ceilometer/+spec/api-aggregate-average 15:41:24 #link https://blueprints.launchpad.net/ceilometer/+spec/remove-disabled-pollsters-option 15:41:27 Any takers? Feel free to email me, dhellmann or jd__ if you wish to be assigned to any of those 15:42:00 I'll take the last one 15:42:21 done. 15:42:37 jd__: thanks! 15:42:52 I took the first one 15:42:55 I thought I was already assigned there 15:43:04 great 15:43:26 Just notice that https://blueprints.launchpad.net/ceilometer/+spec/meter-post-api , will it be similar to CW's publish_metric_data? 15:43:59 yjiang5: good question. I was hoping to get some light on this from asalkeld 15:44:02 s/publish_metric_data/put_metric_data/ 15:44:11 but I xould not reach him this morning 15:44:37 nijaba: this is created by jd__, 15:44:51 yjiang5: yes that's the idea 15:45:09 The new v2 api would have the aggregate-average? right? 15:45:27 llu-laptop: if someone signs up to implement it :-) 15:45:32 llu-laptop: if someone implements it 15:45:38 dhellmann: hehe 15:45:40 :) 15:45:56 that was a bit scary 15:46:25 how does the synaps do that? 15:46:32 I think I may have someone at enovance that could eb interested in that one. I'll chase him 15:47:07 #action nijaba to find out if EmilienM wishes to commit on https://blueprints.launchpad.net/ceilometer/+spec/api-aggregate-average 15:49:13 Should I send an email to the ml about the 3 remaining bp to see if we catch any commiters? 15:49:27 it can't hurt 15:49:54 #action nijaba to send an email to openstack-dev listing the orphan bps 15:49:56 I'll bet eglynn is interested in non-libvirt-hw. 15:50:10 maybe... 15:50:31 #info Here is the list of bp that are going to be in Grizzly 2, only 2 are not yet completed. I hope they will be before the end of next week 15:50:31 #link https://launchpad.net/ceilometer/+milestone/grizzly-2 15:50:31 Any issues about those? 15:51:19 remember g2 milestone is Jan 10 15:51:44 I'm not sure we'll have an official release of wsme by then to fix the bug on that list 15:52:14 is that issue mitigated by the change to make the v1 api the default again? 15:52:24 dhellmann: yes, but I don think that would block the release. we could reassign the bug to g3 15:52:34 ok 15:53:02 reassigned to g3 15:53:23 jd__: I think the 2 remaining bp are in your hands, right? 15:53:40 jd__: confortable about them? 15:53:49 nijaba: yep 15:53:56 cool 15:54:19 I think we are done with that topic then 15:54:20 don't know if gpernot will fix meters' unit implementation by then, so I may jump in and take over if needed 15:54:33 jd__: please do 15:54:50 #topic Open discussion 15:54:53 didn't I see something about that already? was it just the bug/blueprint, or wasn't there a changeset? 15:55:09 dhellmann: a partial changeset 15:55:15 ah, ok 15:55:20 I have 2 items to bring up 15:55:38 first, it seems like we're seeing more interest in the sqlalchemy storage driver 15:55:49 dhellmann: https://review.openstack.org/18413 15:56:07 how comfortable are we that it's feature-complete? some people seem to want to make mysql the default... 15:56:25 IIRC, we've got some NotImplemented exceptions in a few places 15:56:34 do we need to prioritize working on those? 15:56:38 dhellmann: I think we're not comfortable because we don't have tests on the abstraction layer above IIRC 15:56:52 dhellmann: should we look for those and open bugs if they are not there already? 15:57:06 nijaba: yes, I think so 15:57:20 jd__: have you had any time to think about how to implement those? 15:57:21 jd__: good point. We should have tests for that 15:57:39 dhellmann: not at all, but I think it's something we should put on our priority list 15:57:47 jd__: I agree 15:57:52 for g3 I would think, right? 15:57:59 yes, I was just going to suggest g3 15:58:04 makes sense to me 15:58:36 #action nijaba to add bp skeleton to remind ourselves to implement higher level tests for db backends 15:58:59 there may already be a bug open, too 15:59:12 ok, second item: we have a couple of "questions" open on launchpad 15:59:15 Iĺl look for it and reference it in the bp then 15:59:20 #link https://answers.launchpad.net/ceilometer/+questions?field.sort=recently+updated+first&field.actions.search=Search&field.status=Open&field.search_text= 15:59:33 is everyone else subscribed to see those when they come in? 15:59:48 subscription isn't automatic, IIRC 16:00:04 dhellmann: hmmm, I need to set a contact for this. I guess it should point to the team, right? 16:00:15 if you can do that, that's a good idea 16:00:28 I subscribed myself individually 16:00:31 ceilometer-drivers? 16:00:48 and core-devs 16:01:03 yeah, I think those make sense 16:01:09 done 16:01:18 at least to ensure the questions get some attention 16:01:25 right!!! 16:01:33 I'm not sure there are answers to the ones we have open now about installation dependencies 16:02:21 which should then be turned into bugs? 16:02:53 well, the one about keystone client may be a bug somewhere, but it's hard to say 16:02:54 I'll ask for more details about what versions of things they are running on one server 16:03:08 the other one about how to install just the agent depends on the OS packagers, doesn't it? 16:03:25 it does 16:03:25 we're not currently packaging the agent separately, but we have instructions for starting it separately 16:03:33 yep 16:03:34 ok, I can answer that way then 16:03:39 thanks 16:03:58 dhellmann: yeah the keystonclient version problem is typically some old version of glanceclient or the like that requires old keystoneclient version… 16:04:44 jd__: ugh, yeah 16:04:54 * nijaba notes that we are now 4 min past meeting end time 16:05:40 that's all I had 16:06:02 ok, great 16:06:15 thank you all for another great meeting! 16:06:32 #endmeeting