20:59:58 #startmeeting Ceilometer 20:59:59 Meeting started Wed Dec 5 20:59:58 2012 UTC. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:02 The meeting name has been set to 'ceilometer' 21:00:12 #chair dhellmann 21:00:13 Current chairs: dhellmann 21:00:25 #link http://lists.openstack.org/pipermail/openstack-dev/2012-December/003685.html 21:00:34 #link http://wiki.openstack.org/Meetings/MeteringAgenda 21:00:35 if you are here for the ceilometer meeting, please raise your hand 21:00:35 o/ 21:00:39 o/ 21:00:39 o/ 21:00:43 o/ 21:01:04 o/ 21:01:23 nijaba is traveling, so may be in and out depending on connectivity 21:01:26 first up, actions from previous meetings 21:01:27 #topic yjiang5 to send patches for transformer 21:01:28 #link https://review.openstack.org/#/c/17440/ 21:01:41 dhellmann: yes, sent out 21:01:43 this is under review, with good discussion 21:02:00 o/ (from flaky 3G in the high speed train) 21:02:03 do we need to do anything else with it, aside from continue discussing, for next week? 21:02:17 you live in the future, nijaba 21:02:26 dhellmann: I will rebase according to feedback. 21:02:33 yjiang5: but no action for the meeting? 21:02:40 dhellmann: no 21:02:47 #info patch under review, task complete 21:02:55 #topic eglynn kick off Synaps discussion on upstream ML 21:02:56 #link http://lists.openstack.org/pipermail/openstack-dev/2012-December/003731.html 21:03:25 eglynn: we have an agenda item about this for later in the meeting 21:03:26 d 21:03:26 yep ... so the discussion is underway 21:03:26 o you 21:03:27 have 21:03:36 do you have anything else to add now? 21:03:48 I'll prod the Synaps guys to try to get them more vocal on the list 21:04:09 yeah, I'd like to know that we'll hear from them more than once a week or so if we're going to bring them into the team 21:04:10 I 21:04:11 a 21:04:22 yes, agreed 21:04:26 ok, we can discuss more in a bit 21:04:32 #topic nijaba to update the bp to specify complex request in a future version 21:04:33 #link http://wiki.openstack.org/Ceilometer/blueprints/multi-dimensions 21:04:33 eglynn: so can they access IRC? 21:04:46 yjiang5: I need to confirm that 21:05:09 this appears to be done, right nijaba ? 21:05:18 right 21:05:36 #info done, see second example under number 2 in the "Design" section 21:05:53 #topic dhellmann to prepare example of dimension query syntax that will work with WSME 21:05:54 #link http://wiki.openstack.org/Ceilometer/blueprints/multi-dimensions 21:06:12 #info done, see the WSME example under number 2 in the "Design" section 21:06:13 questions? 21:06:40 ok 21:06:42 #topic jd move asalkeld's client into openstack incubation/core 21:06:51 jd__: any updates? 21:07:05 yes, started this afternoon with https://review.openstack.org/#/c/17537/ 21:07:19 #link https://review.openstack.org/#/c/17537/ 21:07:23 wait'n see :) 21:07:41 cool, is that a new repo, then? 21:07:51 obviously! 21:08:01 * dhellmann didn't click through 21:08:05 hehe 21:08:07 any actions on this for next week? 21:08:07 hi, sorry bit late 21:08:14 like every other python-client 21:08:23 jd__: ok, good 21:08:26 dhellmann: I don't think so, I'll follow my review request 21:08:32 ok 21:08:47 #topic yjiang5 talk with doc team to link to ceilometer docs 21:08:48 #link https://review.openstack.org/#/c/17444/ 21:08:48 that's merged, so is this work done? 21:08:53 yes 21:08:57 #info done 21:09:06 on a related note, the references on launchpad have been updated to point to the new location 21:09:07 should I delete ceilometer.readthedocs.org? replace it with a page pointing to the new location? 21:09:26 dhellmann: yeah, replace it and then delete 21:09:52 #action dhellmann replace ceilometer.readthedocs.org with a page directing readers to the new site 21:09:53 +1 21:10:06 here's the nijaba 21:10:10 dhellmann: so we will update the new doc site 21:10:25 dhellmann: to improve it , right? 21:10:28 yjiang5: yes, the jenkins job updates the new site automatically after every merge 21:10:53 so we can expand the documentation through our normal review process, without waiting for me to remember to push to my repo to get rtd.org updated :-) 21:11:00 dhellmann: great. 21:11:09 dhellmann: we may want to keep readthedoc for0.1 doc? 21:11:18 nijaba: ah, good point 21:11:35 I will see if I can figure out a way to do that 21:11:46 nijaba: why do we want to keep 0.1 doc, if we have v1 api back compatibility? 21:12:04 yjiang5: because we have people deloying it 21:12:12 yjiang5: there are some developer details in the docs that have changed, too 21:12:31 nijaba: dhellmann: got it. 21:12:59 I think I can make that work by using a branch in my private github repo 21:13:11 I think that's it for past actions, on to new business 21:13:11 #topic Discuss v2 API proposal 21:13:47 I think this is a combination of the pecan/wsme stuff and asalkeld's desire to tighten up the api urls 21:13:50 (and mine) 21:13:54 yeah, I've added this to the agenda because I didn't see much trace of what v2 API should look like 21:14:19 I assume you mimic-ed the v1 URL scheme, but I didn't have the chance to review your work :p 21:14:31 anyway I had the feeling we could improve and change a lot of thing in v2 21:14:33 * nijaba concurs to the need of a bp 21:14:42 I've been working on documentation for the v2 api, and I do have to say it's a bit odd to have a bunch of urls that return the same thing with different filters 21:14:55 jd__, I was hoping we could flatten the api 21:14:56 does anyone think we should *not* make any api changes? 21:15:03 assuming we get a blueprint together quickly 21:15:04 asalkeld: I was thinking the same actually 21:15:23 dhellmann: it's v2, we can do anything! :) 21:15:24 so like: /meters /resources /samples 21:15:31 although I would be inclined to give this blueprint an extension on our approval deadline if we needed to. I think it's important enought. 21:15:34 something like that 21:16:01 dhellmann: +1 for an extension, as long as we start it sooner than later 21:16:02 dhellmann: makes sense, especially now that the code is merged :) 21:16:28 asalkeld: do you have enough info to put together a concrete proposal? 21:16:41 or do you need more details about how wsme parses queries 21:16:43 oo 21:16:43 ps 21:17:07 sorry 21:17:09 disconnect 21:17:10 * dhellmann hopes it wasn't something he said 21:17:11 grr 21:17:13 yes 21:17:19 asalkeld: trying to avoid embarrassing questions? ;) 21:17:29 I can put something together 21:17:42 ctrl-r 21:17:48 == disconnect 21:17:54 hehe 21:18:07 asalkeld: action? 21:18:11 yip 21:18:27 #action asalkeld prepare a blueprint for v2 api "tightening" changes 21:18:40 faster typer 21:18:48 let me know if I can help with wsme questions 21:18:57 his docs are a little thin, I need to help him expand on those 21:18:58 sure, probably the query 21:19:15 and your usecases 21:19:16 dhellmann: yeah, can we get rif of the [] in the query ? 21:19:34 nijaba: I'll have to see. I think that's how wsme makes arrays of objects 21:19:46 I haven't had a chance to experiment, yet 21:19:52 dhellmann: k 21:20:02 #action dhellmann experiment with passing arrays of parameters to wsme for queries 21:20:16 ok, anything else on this topic? 21:20:24 good for me 21:20:31 i'll wait for asalkeld bp :) 21:20:42 I'll do it today 21:20:56 sounds good 21:20:59 ok, next up 21:21:00 #topic Mechanics of getting synaps on-board 21:21:05 so the approach I suggested on the ML ... 21:21:12 (big-bang import of the code prior to clean-up tasks, manual migration of launchpad issues) 21:21:18 too simplistic, or? 21:21:23 ... or just simplistic enough ;) 21:21:32 I don't know enough about git submodules/subtrees 21:21:34 hm at first glance I'm not in favor of importing a lot of code that way 21:21:39 but I'm hoping it can be done in a straight-forward history preserving way 21:21:45 eglynn: I haven't checked for a reply to my question about doing cleanup before vs. after importing 21:21:47 I'd rather have a cherry-picking-surgeon approach 21:22:13 jd__: OK, I'll assess the code to see if that's feasible 21:22:18 eglynn: I rememner they have even java code? 21:22:22 * eglynn was just eager to get it in there ... 21:22:30 it would be nice to have a meeting with them present to discuss this, no? 21:22:37 eglynn: would be great to pick code we'd need and put it into our various ceilometer components (or create new ones) 21:22:43 yjiang5: yep, there's a small amount of Java code to define the strom topology 21:22:48 else it is just a code dump 21:22:57 yjiang5: (as opposed to functional code) 21:23:14 eglynn: ok, just curios how to import that code :) 21:23:19 how about: 21:23:27 nijaba: I'll prod them to get on the ML to discuss at least 21:23:32 we commit the post/get 21:23:36 then the alarm 21:23:58 so we get _some_ seperation 21:24:07 post/get? 21:24:16 asalkeld: what's the post/get? their impl of PutMetricData/GetMetricStats 21:24:18 ? 21:24:21 post_meter_data 21:24:34 basically the monitoring 21:24:39 then the alarms 21:25:00 I am keen to have an option to have a different alarm system 21:25:06 asalkeld: by the alarms, do you mean the alarm evaluation logic in Synaps? 21:25:07 commiting inside ceilometer itself or as a side-project inside ceilometer repo? because that sounds 2 different options to me 21:25:14 eglynn, ya 21:25:19 and not sure what we're talking about here 21:25:25 asalkeld: that order and separation makes sense to me 21:25:29 O, haven't read ml 21:25:37 but yeah, where is it going in our repo? 21:25:41 assume in code base 21:26:05 under ceilo/monitoring or something of that ilk 21:26:05 so where else we putting it 21:26:15 or ceilo/synaps even ... 21:26:15 jd__: as a side-project possibly tricky to manage? 21:26:29 ok, that sounds fine to me, I'd dislike having a side project I think 21:26:30 * eglynn is not sure what a side project is ... 21:26:35 so put the api under api/ 21:26:42 eglynn: another project in another subdirectory… :) 21:26:57 and the alarming under alarm 21:27:04 seems simple to me 21:27:09 that makes sense 21:27:23 this seems like something we need a blueprint for, to map out all of these details in an easy to review form 21:27:27 jd__: like a git submodule/subtree? or just a seperate dir? 21:27:32 dir? 21:27:38 yeah, no submodules 21:27:44 k 21:27:48 more complexity 21:28:10 ceilometer/api/{v1,v2,cw} 21:28:14 asalkeld: dir, just in the sense of a plain ol' directory 21:28:16 eglynn: what's the target schedule for this merge? In G? H? 21:28:26 I recon 21:28:39 asalkeld: the cw api should be part of v2, no? 21:28:44 we'll have to version it as it changes 21:28:49 no it's aws 21:28:53 ah 21:28:54 yjiang5: late G 21:29:01 it has it's own versioning 21:29:10 date based 21:29:12 what tool did they use to build it? 21:29:18 but we'll have a native API eventually too right 21:29:37 v2? 21:29:38 the native api will go under our versioned tree? 21:29:46 why not? 21:29:52 dhellmann: yes I'd expect so 21:29:56 ok 21:30:06 dhellmann: but user will assume aws version still, so a map from our version to aws version? 21:30:12 so, who is going to pull all of this together into a blueprint? 21:30:19 we don't want to get in the nova API extensions versioning fragmentation 21:30:26 I can do that 21:30:35 but would appreciate input on the ML thread 21:30:39 #action eglynn prepare a blueprint for synaps integration 21:30:41 agreed 21:30:51 cool 21:30:59 I presume part of this will be giving some of the synaps team +2 rights for reviewing our changes to their code? 21:31:27 yes I think so 21:31:32 dhellmann: agree. 21:31:48 if that is the case, we need a commitment of responsiveness, I think? 21:31:51 (but not structured as a veto on everything) 21:32:08 yes: " commitment of responsiveness" 21:32:08 yes, I'm going to prod them again to get some clarity on that 21:32:15 ok 21:32:32 ok 21:32:38 well other approach 21:32:39 I think we should hold off on any code work until we have the team aspects of the integration worked out 21:32:46 makes sense 21:33:01 is to let them get involved as they want to 21:33:02 although design discussions should proceed, to avoid holding us up later? 21:33:26 and we make changes as we see fit 21:33:26 yes 21:33:33 asalkeld: if they say they don't want +2, that's ok, but I don't think we should take the code without offering 21:33:47 seems, I don't know, rude 21:33:59 rudeness is not our style ;) 21:34:07 yet 21:34:11 LOL 21:34:13 well maybe a suggestion of expections 21:34:19 so the commitment is just if they say yes to wanting +2, just like for any other team -- you have to contribute to keep it 21:34:31 asalkeld: right 21:34:56 like come to irc meetings? 21:35:07 that would be good, if we can work out the timing 21:35:13 they're in asia somewhere, right? 21:35:13 would make sense 21:35:20 Korea I imagine 21:35:33 yep 21:35:41 ok 21:35:42 yep, this slot is better than the alternate Euro-friendly one 21:35:58 so maye every other week would be acceptable 21:36:14 sure, and not necessarily all of them if they want to appoint a representative or something 21:36:15 * jd__ is sleeping on his keyboard and don't get what eglynn is talking about 21:36:39 haha 21:36:40 just meant that they may not be able to make the Thurdsday afternoon GMT slot 21:36:43 I'm not trying to stress the participation, but it feels like stealing to bring their code in without involving them. 21:36:58 agreed 21:37:01 ok 21:37:04 eglynn: I was kidding :) 21:37:13 it's opensource, no such thing as stealing 21:37:16 ;) 21:37:20 so, mordred also brought up healthnmon moving to stackforge on the mailing list 21:37:25 * eglynn is slow on the up-take at this hour ;) 21:37:25 dhellmann: why can't firstly work with two project, and comunicate with RPC? 21:37:50 ola 21:37:54 yjiang5: that would be another approach, but I think we felt there would be a lot of benefits to sharing actual code 21:38:07 hi, mordred 21:38:07 yjiang5: RPC or REST API? 21:38:29 yjiang5: REST makes more sense to me, as opposed to AMQP ... 21:38:37 eglynn: either way is ok, synaps support AMQP IIRC. 21:38:51 either, but let's finish exploring the code merge path before we give up and go back to two projects 21:38:59 yep 21:39:02 dhellmann: sure 21:39:17 ok, so healthnmon -- we looked at this a couple of weeks ago, didn't we? 21:39:23 yea 21:39:30 but they are super quite 21:39:46 maybe we can email them directly 21:39:52 apparently they are working with mordred to get stackforge access 21:39:59 yea 21:40:05 yeah - I believe they want to work on this in the open and stuff 21:40:06 they were vocal at the summit, but haven't heard anything much since 21:40:20 just gotta get them bootstrapped I think 21:40:48 cool enough 21:40:56 I can't find my notes from that meeting. 21:40:57 di 21:40:57 d 21:41:21 did we agree that monitoring at that level was going to wait for another release? 21:41:38 dhellmann, they are at a bunch of levels 21:41:51 trace + inventory 21:42:03 and some alarms 21:42:31 so seems like somewhat of an overlap 21:43:07 I have go and take kids to school 21:43:14 later ... 21:43:23 later 21:43:48 so one think that wasn't fully clear to me at the summit was how much they'd actually built-out 21:43:49 ok, so I'm trying to remember why we approached synaps instead of healthnmon. was it just activity on the mailing list? 21:44:07 heathnmon wasn't opensourced at the time 21:44:14 aha 21:44:17 (they just released RPMs initially) 21:44:22 ok 21:44:39 then later pushed the code up tot github (whithout any fan-fare) 21:44:57 so, is it worth approaching them now? 21:45:10 sure 21:45:20 * nijaba has to get off the train before it goes back to london... 21:45:27 eglynn: is that an action for you again? 21:45:34 you have the most practice… ;-) 21:45:38 sure ;) 21:45:38 dhellmann: I can also have a look on it 21:45:55 #action eglynn reach out to healthnmon project 21:46:02 dhellmann: our team is quite intrersting in host monitor, which is a bit overlap with healmon 21:46:12 yjiang5: cool 21:46:29 about the build-out completeness, IIRC their architecture included all manner of integration points with other monitoring frameworks 21:46:35 nagios, ganglia etc 21:46:37 yjiang5: good, you and eglynn can take that together 21:46:43 dhellmann: sure. 21:46:48 eglynn: yeah, I remember a very complex diagram 21:46:55 wasn't clear though wether that was aspirational as yet ... 21:47:04 #link http://wiki.openstack.org/CloudInventoryManager 21:47:54 anything else on this? 21:48:13 #topic Open discussion 21:48:40 yep, that's a big ol' diagram all right ;) 21:49:01 I will update the wiki, but I wanted to mention that I'll be out for the next 2 meetings due to travel 21:49:19 I heard about that 21:49:23 and I'll be offline entirely from 12/8-12/19 21:49:28 well, almost entirely 21:49:48 I may have a conflict next week as well 21:49:50 Jenkins has submitted this change and it was merged. 21:49:51 21:49:51 Change subject: Add python-ceilometerclient 21:49:52 FYI 21:50:07 nice! 21:50:19 https://github.com/openstack/python-ceilometerclient 21:51:13 oh, I've been given permission to open source the DUDE, so after my break I'll start working on adding that to the client library as an example app 21:51:38 great 21:52:01 cool 21:52:13 ok, we're close to the end of our time slot. any other announcements or topics? 21:52:18 so the DUDE is the dreamhost billing engine, right? 21:52:32 DUDE is the tool that exports data from ceilometer into our billing system 21:52:37 Dreamhost Usage Data Exporter 21:52:55 a-ha, nice acronym ;) 21:53:10 * dhellmann was feeling inspired that day 21:53:50 if there's nothing else, we can close up a couple of minutes early... 21:54:31 ok, thanks everyone! 21:54:31 sounds good, 'night folks ... 21:54:57 #endmeeting