21:00:01 <nijaba> #startmeeting Ceilometer 21:00:01 <nijaba> #meetingtopic Ceilometer 21:00:01 <nijaba> #chair nijaba 21:00:01 <nijaba> #link http://wiki.openstack.org/Meetings/MeteringAgenda 21:00:01 <nijaba> ATTENTION: lease keep discussion focussed on topic until we reach open discussion topic 21:00:02 <openstack> Meeting started Wed Nov 21 21:00:01 2012 UTC. The chair is nijaba. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:04 <openstack> The meeting name has been set to 'ceilometer' 21:00:07 <openstack> Current chairs: nijaba 21:00:20 <dhellmann> o/ 21:00:21 <jd__> o/ 21:00:25 <eglynn> o/ 21:00:27 <yjiang5> o/ 21:00:34 <nijaba> o/ 21:00:54 <nijaba> #topic actions from previous meeting 21:01:01 <nijaba> #topic jd and nijaba to start preparing a video demo of ceilometer 21:01:06 <nijaba> no real progress there this week. We clearly do not have much time to work on this at the moment. I guess we'll have to postpone this a bit... 21:01:18 <jd__> #agreed 21:01:22 <jd__> :) 21:01:27 <nijaba> unless anyone else wants to work on it 21:01:43 <nijaba> no volunteer? 21:01:51 <nijaba> ok moving on... 21:01:53 <nijaba> #topic eglynn propose agent item on ceilo interaction for nova IRC meeting 21:02:14 <eglynn> so I proposed it to them, but they didn't bite 21:02:24 <eglynn> sorry wrong topic! 21:02:35 <jd__> #rewind 21:02:48 <eglynn> we discussed the cilo/nova interaction at the nova weekly meeting 21:03:12 <eglynn> and option 5 (a versioned stable lib wrapping th enova virt bit we need) was the preference of the nova folks 21:03:31 <eglynn> provisionally at least, pending the details being fleshed out 21:03:46 <nijaba> who would own the lib? Ceilo? 21:04:01 <eglynn> nova primarily 21:04:07 <nijaba> k 21:04:08 <eglynn> with ceilo contributions to it 21:04:18 <nijaba> and who has the action to flesh out the details? 21:04:27 <eglynn> so I've been trying to smoke out the versioning and releas emgmt implications 21:04:34 <eglynn> #link http://lists.openstack.org/pipermail/openstack-dev/2012-November/003123.html 21:04:49 <eglynn> I still have the action to flesh out 21:05:12 <eglynn> ... and yjiang5 has some ideas also 21:05:26 <nijaba> should you guys action yourselves on that? 21:05:36 <yjiang5> yes, I did some investigate on the API 21:05:37 <asalkeld> hi, bit late ... 21:05:49 <eglynn> #action eglynn drive fleshing out of nova-virt API to completion 21:05:57 <nijaba> thanks eglynn 21:06:11 <asalkeld> ooo, eglynn is driving 21:06:11 <nijaba> #topic nijaba to close survey and publish result prior to next meeting 21:06:22 <nijaba> I did this via an email to the mailing list: 21:06:22 <nijaba> #link http://lists.openstack.org/pipermail/openstack-dev/2012-November/003124.html 21:06:22 <nijaba> We'll have time to discuss this in a bit 21:06:33 <nijaba> #topic asalkeld investigate diamond for use to generate stats 21:06:43 <asalkeld> so I had a look 21:07:05 <asalkeld> but not really good fit for ceilometer 21:07:16 <asalkeld> but good fit for diagnostic 21:07:24 <asalkeld> or tracing 21:07:32 <nijaba> interesting 21:07:34 <asalkeld> it's kinda like tach 21:07:35 <dhellmann> any ideas we can steal for the multi-publishing changes? 21:07:59 <asalkeld> well it doen't have a concept of different rates 21:08:09 <asalkeld> which would be neat 21:08:16 <nijaba> it would :) 21:08:19 <dhellmann> wait, it does 21:08:21 <asalkeld> so not really 21:08:39 <asalkeld> really 21:08:44 <dhellmann> I had a system set up here polling ceph at one rate and everything else at another rate 21:08:50 <dhellmann> yeah, you can control that in the config file 21:09:01 <dhellmann> I'll have to dig up the settings again, I deleted that vm 21:09:22 <asalkeld> o, I meant more caching, aggregation 21:09:25 <dhellmann> it controlls the polling rate, which is then the same as the publishing rate for those meters 21:09:38 <dhellmann> oh, yeah, I think it assumes upstream does that 21:10:03 <nijaba> I think what we want to find is the best way to minimize polling and intreations, rig 21:10:04 <asalkeld> we might want to sample often but publish less often 21:10:22 <eglynn> yep, say for CPU util 21:10:26 <jd__> that's a point for transformer 21:10:27 <asalkeld> (for monitoring) 21:10:30 <yjiang5> that can be achieved through transfomer 21:10:36 <asalkeld> ya 21:10:46 * jd__ high five yjiang5 21:11:11 <eglynn> the transformer drops some samples on the floor, or? 21:11:22 <eglynn> (to dial down the publishing rate) 21:11:23 <jd__> eglynn: or use them to build a % value 21:11:28 <eglynn> (or aggregates) 21:11:43 <jd__> dropping shouldn't be a transformer feature itself 21:11:43 <eglynn> a-ha, OK 21:12:22 <eglynn> thought yjiang5 menat using a transformer to step down the sample rate for fewer publishes ... 21:12:24 <yjiang5> possibly we can have transfomer pipeline? some drop, some aggeragete ? possibly 21:12:34 <nijaba> ok, so should we have a topic on transformer design next week? 21:12:34 <eglynn> s/menat/meant/ 21:12:44 <eglynn> yep, long thread in gerrit 21:13:00 <jd__> not sure a meeting topic will fit 21:13:03 <nijaba> maybe yjiang5 can prep soemthing? 21:13:09 <yjiang5> sure 21:13:12 <dhellmann> yeah, we need something written up to talk about 21:13:12 <eglynn> (gerrit highly unsuited to long discussions ...) 21:13:12 <nijaba> thanks 21:13:20 <yjiang5> I would discuss on the ML firstly 21:13:25 <jd__> +1 21:13:27 <eglynn> yep 21:13:32 <dhellmann> +1 21:13:38 <jd__> the subject is so complex, async communication will work better as a first step 21:13:42 <nijaba> #action yjiang5 to drive a topic on transformer next week meeting 21:13:54 <nijaba> arghhh 21:14:01 <nijaba> trike t 21:14:06 <nijaba> astrike that then 21:14:10 <jd__> #unaction ! 21:14:16 <jd__> ;) 21:14:25 <asalkeld> undo? 21:14:28 <nijaba> #rewind too 21:14:45 <yjiang5> ? 21:14:52 <nijaba> #action yjiang5 to start a thread on transformer 21:15:05 <yjiang5> sure 21:15:13 <nijaba> #topic eglynn propose IRC meetup with Synaps folks to discuss collaboration model 21:15:13 * nijaba guess they did not bite :) 21:15:23 <eglynn> so I proposed it to them, but they didn't bite 21:15:33 <eglynn> however they assure me they're continueing to discuss internally 21:15:35 <jd__> bummer 21:15:42 <eglynn> and will have a conclusion by week's end 21:15:57 <eglynn> (apparently busy with a bunch of other stuff ...) 21:16:00 <jd__> re-#action then? 21:16:00 <nijaba> so, let's wait for their decision 21:16:04 <eglynn> cool 21:16:04 <nijaba> yep 21:16:06 <dhellmann> so they didn't say no, but haven't said yes? 21:16:13 <eglynn> exactly 21:16:40 <nijaba> #action eglynn to report on synaps' decision 21:16:42 <eglynn> will be wrapped up one way or the other this week 21:16:53 <nijaba> #topic dhellmann to confirm with ttx that tarball job is correct 21:17:06 <dhellmann> it was not, but has been fixed so it is now 21:17:16 <jd__> \o/ thx 21:17:17 <nijaba> cool! thanks dhellmann 21:17:27 <nijaba> #topic nijaba to transform bp-less features into bp 21:17:27 <nijaba> So I spent quite a bit of time on this, you can see the results at 21:17:27 <nijaba> #link https://blueprints.launchpad.net/ceilometer/grizzly 21:17:27 <nijaba> I also updated the roadmap page, but I think this is now truely redudant info and we should get rid of it, wdyt? 21:17:35 <dhellmann> the infra team also added a gating job to ensure all of our contributors have signed the CLA 21:17:48 <nijaba> nice! 21:17:51 <eglynn> yep, get rid, duplication is badness for this sort of stuff 21:17:54 <jd__> nijaba: I hate duplicate 21:18:00 * nijaba too 21:18:11 <dhellmann> nijaba: maybe just erase the contents and point to launchpad? saves history... 21:18:15 <jd__> let's kill the grizzly then! 21:18:24 <nijaba> #action nijaba to get rid of roadmap page content to point to lp 21:18:30 <jd__> otherwise good work nijaba :) 21:18:36 <nijaba> thanks 21:18:46 <eglynn> yep, much neater! 21:18:53 <nijaba> I guess that's it for last week's actions 21:19:03 <nijaba> #topic Folsom stable update release? 21:19:11 <nijaba> So far, it seems that we have made some good progress that should not break the compatibility with Folsom and some of the bug fixes are somehow critical for production environments. What would you guys think if we were producing a Folsom stable update at the same time of the g2 milestone? 21:19:38 <dhellmann> we might even be able to say that g2 is compatible with folsom 21:19:43 <nijaba> this may mean that we should wait until we commit breaking changes after that milestone, though 21:19:54 <eglynn> interesting, do we have a stable/folsom branch? 21:20:02 <dhellmann> jd__ has a patch under way to update the CI system to test changes against folsom 21:20:07 <jd__> I agree with dhellmann on that 21:20:10 <nijaba> eglynn: we don't but can have one 21:20:23 <dhellmann> nijaba: yes, we do have a stable/folsom branch 21:20:28 <jd__> stable/folsom should be a 2012.2.1 release with fix only, but I don't think this is what we want 21:20:28 <eglynn> couldn't we create one, backport selected fixes to that and keep master trucking ahead? 21:20:40 <dhellmann> we made a branch right before ODS 21:20:42 <nijaba> dhellmann: ah... the 0.1 branch? 21:20:52 <dhellmann> yeah, I thought we called it stable/folsom 21:20:56 * dhellmann goes to git 21:20:58 <jd__> selecting fix is going to be big grunt work :( 21:21:09 <jd__> *fixes 21:21:20 <asalkeld> cp ceilometer-2012.g2 ceilometer-folsom 21:21:28 <dhellmann> remotes/origin/stable/folsom 21:21:51 <jd__> asalkeld: that would break the rule I think 21:21:56 <dhellmann> the main issue with compatibility has been nova 21:22:09 <eglynn> so the stable-maint criteria for backport selection are ... user-visible fix, low impact, low risk 21:22:09 <jd__> it's saner to keep Folsom compatibility until g2 21:22:14 <dhellmann> so far we're compatible, so we could just merge master into the stable branch 21:22:30 <jd__> dhellmann: I don't think it's policy compliant /o\ 21:22:36 <eglynn> exactly 21:22:40 <nijaba> so, anyone against this? It should be simple IIUC and don't break compat until g3 21:22:45 <dhellmann> oh, we have to pick individual patches? 21:22:53 <jd__> dhellmann: oh yes we have to. 21:23:00 <eglynn> so users expect stable releases to be minimal and contain carefully selected fixes 21:23:02 <dhellmann> :-( 21:23:04 <jd__> stable/folsom is meant to fix bugs like eglynn said 21:23:12 <nijaba> jd__: does this apply to inbation? 21:23:13 <dhellmann> ah, ok, that makes sense 21:23:14 <eglynn> not trunk chasing 21:23:25 <dhellmann> well, we could just say our g2 release is also compatible and not touch stable/folsom then 21:23:27 <jd__> nijaba: the point of incubation is to act like others players, right? ;) 21:23:28 <nijaba> incubation even? 21:23:38 <jd__> dhellmann: I think it's the best option here 21:23:42 <nijaba> jd__: hmmmpfff... 21:23:44 <eglynn> agreed 21:23:48 <dhellmann> ok 21:24:08 <jd__> I've already updated tox.ini to run unit tests against folsom and the -infra team is about to merge my change forcing gate checks againt Folsom 21:24:18 <jd__> just say yes to this and it'll happen! ;) 21:24:20 <nijaba> #agreed g2 should be declared folsom compatible 21:24:26 <dhellmann> one other thing I have found is that our version of anyjson is not compatible with folsom, so I had to make a change for our internal packaging 21:24:36 <dhellmann> it conflicts with the version folsom nova wants, IIRC 21:24:40 <jd__> dhellmann: feel free to send a patch then :) 21:24:54 <eglynn> yeah anyjson dependency caused issues before 21:24:55 <dhellmann> unfortunately, changing it will break grizzly compatibility 21:25:05 <eglynn> (nova, quantum etc. have a much older dep IIRC) 21:25:09 <jd__> dhellmann: we can create a second pip-requires? 21:25:18 <dhellmann> so we may actually need a branch at g2 for compatibility with just that change 21:25:25 <jd__> let's update nova and quantum? ;) 21:25:41 <dhellmann> they're updated in grizzly already, I think 21:25:47 <eglynn> yep they are 21:25:55 <eglynn> #link http://wiki.openstack.org/StableBranch#Appropriate_Fixes 21:25:57 <jd__> ah, ok 21:25:57 <dhellmann> so grizzly is consistent, but newer than folsom 21:26:11 <dhellmann> maybe we need an unstable/folsom branch ;-() 21:26:16 <eglynn> LOL 21:26:19 <jd__> lol 21:26:42 <jd__> dhellmann: what's the problem with supporting several anyjson on our side? 21:27:15 <dhellmann> hmm, that might work 21:27:55 <dhellmann> #action dhellmann test more lenient anyjson support for folsom and grizzly compatibility 21:28:08 <jd__> dhellmann: if you need some help about that, ping me 21:28:16 <jd__> not sure you'll need, but I care about Folsom too 21:28:24 <nijaba> #link http://wiki.openstack.org/GrizzlyReleaseSchedule as a reminder 21:28:35 <nijaba> g2 is jan 10 21:28:45 <dhellmann> jd__: thanks, I'll let you know! 21:29:10 <nijaba> #topic Discuss results of Poll 21:29:24 <nijaba> so, did you have time to look at the results 21:29:27 <nijaba> ? 21:29:41 <nijaba> any action we need to take? 21:30:04 <jd__> I look at the result, and I don't have any comment 21:30:08 <dhellmann> the first few high priority items were interesting 21:30:10 <jd__> I think you set this in the blueprints priorities? 21:30:21 <dhellmann> I promise I didn't stuff extra ballots! 21:30:38 <nijaba> I set the priorities according to our internal vote, not the poll so far 21:31:10 <jd__> nijaba: ok, not sure there's a big difference? 21:31:10 <dhellmann> does anything in the results change our priorities? I think those internal changes would be great, but I agree with their current priority. 21:31:15 <eglynn> #link http://lists.openstack.org/pipermail/openstack-dev/2012-November/003124.html 21:31:52 <asalkeld> * I want to have monitoring information in a central place 21:31:53 <asalkeld> 82,8% 24 21:31:55 <asalkeld> ooo 21:32:27 <shardy> +1 ;) 21:32:52 <nijaba> I think the horizon plugin suggestion showed that we forgot to input items that were already on the roadmap on which we did not vote 21:33:09 <dhellmann> nijaba: good point 21:33:10 <nijaba> so I added https://blueprints.launchpad.net/ceilometer/+spec/horizon-plugin 21:33:11 <nijaba> and 21:33:20 <dhellmann> jd__: how's that prototype you were working on coming along? 21:33:24 <nijaba> https://blueprints.launchpad.net/ceilometer/+spec/user-api 21:33:41 <zykes-> are you guys in on horizon integration atm ? 21:33:46 <nijaba> should we set some medium prio on those? 21:33:55 <jd__> dhellmann: prototype? on horizon? not me 21:34:06 <nijaba> zykes-: what do you mean? 21:34:09 <dhellmann> jd__: you had some graphs, I thought that's what they were for 21:34:28 <nijaba> dhellmann: debug graphs, not plugin stuff yet 21:34:32 <jd__> dhellmann: ah, nop, it's just a debug interface sending you html rather json when talking to ceilometer-api 21:34:40 <jd__> s/rather/rather than/ 21:34:52 <dhellmann> jd__: ah 21:34:53 <nijaba> and the horizxon plugin needs a user api first, I think 21:35:01 <jd__> nijaba: yeah, probably 21:35:15 <nijaba> security wise, I think it is a must 21:35:20 <jd__> we could extend the API to user-API pretty easily now that we have Keystone 21:35:22 <zykes-> nijaba: i'll save it for open-disc 21:35:40 <eglynn> a user API, as opposed to the existing REST API? 21:35:43 <nijaba> ok, so, set taht for medium prio? 21:35:52 <dhellmann> eglynn: so a user can't see resource usage for someone else's stuff 21:36:07 <nijaba> eglynn: yes, same api, but contrained to current tenant 21:36:13 <eglynn> a-ha OK, a non-admin-see-the-world API, got it 21:36:14 <dhellmann> my idea for that was just to update the api implementation to always add the tenant_id parameter to a query unless the user has admin 21:36:23 <dhellmann> so the user api is the same as the admin api 21:36:38 <nijaba> dhellmann: on a differrent port or baed on admin status? 21:36:50 <dhellmann> based on the credentials we get from the keystone middleware 21:36:59 <nijaba> dhellmann: ok 21:37:01 <dhellmann> I assume those are tucked into the request in a way that we can get to them 21:37:06 <jd__> dhellmann: you mean only allow URI with <tenant id> in it? 21:37:23 <nijaba> dhellmann: feel free to fill in some details in https://blueprints.launchpad.net/ceilometer/+spec/user-api 21:37:26 <dhellmann> jd__: no, allow any url, but internally always restrict by the current tenant_id even if the URL doesn't do that 21:37:39 <dhellmann> #action dhellmann update user-api blueprint 21:37:46 <nijaba> dhellmann: thanks! 21:37:47 <jd__> dhellmann: ah yes, good idea 21:38:00 <eglynn> exactly, as nova does for non-admin queries 21:38:12 <yjiang5> We are rebuilding the API server, will user-api depends on that/ 21:38:20 <nijaba> Integrate with monitoring standards such as SNMP, CIM and SMI-S seems to big for this release, right? 21:38:34 <eglynn> I would say so 21:38:45 <dhellmann> nijaba: yes, way too big 21:38:46 <nijaba> k 21:38:54 <nijaba> what about https://blueprints.launchpad.net/ceilometer/+spec/meter-post-api ? 21:38:58 <jd__> I didn't understand 2 of 3 of your stuff, so yes. 21:39:22 <dhellmann> nijaba: that should be a small change to the api 21:39:28 <asalkeld> say this seems alot like a cw api 21:39:28 * nijaba likes the jd__ test, similar to litmus, 21:39:34 <nijaba> but better 21:40:19 <eglynn> how to auth? 21:40:29 <jd__> asalkeld: probably 21:40:29 <eglynn> admin only? 21:40:31 <asalkeld> post + user stuff 21:40:42 <jd__> eglynn: at least admin only as a first step would be great 21:40:51 <eglynn> jd__: cool 21:40:53 <jd__> admin or special role 21:40:55 <asalkeld> I am working on monitoring api 21:40:57 <eglynn> yep 21:41:15 <eglynn> asalkeld: native version of CW API? 21:41:18 <jd__> as stated on the mailing list, this is something PaaS platforms are requesting 21:41:18 <asalkeld> at some point we could work towards one api if it made sense 21:41:23 <asalkeld> eglynn, ya 21:41:27 <eglynn> cool 21:42:08 <asalkeld> this a nice api too http://dev.librato.com/v1/metrics 21:42:19 <nijaba> so, should I mark this as approved/medium, low? 21:43:12 <nijaba> #vote on prio for post meter? high, medium, low 21:43:25 <nijaba> #startvote on prio for post meter? high, medium, low 21:43:26 <openstack> Begin voting on: on prio for post meter? Valid vote options are high, medium, low. 21:43:28 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 21:43:31 <dhellmann> #vote low 21:43:35 <eglynn> asalkeld: measure_time resolution seems a little coarse 21:43:39 <nijaba> #vote low 21:43:42 <asalkeld> #vote low 21:43:45 <eglynn> #vote low 21:43:55 <jd__> #vote medium 21:44:13 <nijaba> anyone else? 21:44:23 <nijaba> ok, done 21:44:26 <nijaba> #endvote 21:44:26 <openstack> Voted on "on prio for post meter?" Results are 21:44:27 <openstack> medium (1): jd__ 21:44:28 <openstack> low (4): nijaba, dhellmann, eglynn, asalkeld 21:44:33 <asalkeld> eglynn, sure - I just meant the rest api 21:44:33 <eglynn> asalkeld: but otherwise looks nice on a first read ... 21:44:46 <nijaba> #startvote on prio for horizon and user api? high, medium, low 21:44:47 <openstack> Begin voting on: on prio for horizon and user api? Valid vote options are high, medium, low. 21:44:48 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 21:44:56 <nijaba> #vote medium 21:44:58 <asalkeld> #vote low 21:45:01 <jd__> #vote medium 21:45:10 <yjiang5> #vote medium 21:45:16 <dhellmann> low 21:45:24 <jd__> syntax error 21:45:29 <asalkeld> I will be off for 10-15min (kids to school) 21:45:34 <eglynn> #vote low 21:45:49 <dhellmann> #vote low 21:46:03 <dhellmann> (thanks, jd__) 21:46:06 <nijaba> countdown to 10... 21:46:19 <nijaba> #endvote 21:46:20 <openstack> Voted on "on prio for horizon and user api?" Results are 21:46:21 <openstack> medium (3): jd__, nijaba, yjiang5 21:46:21 <jd__> then fireworks? 21:46:22 <openstack> low (3): dhellmann, eglynn, asalkeld 21:46:39 <nijaba> argh.. we have parity 21:46:41 <jd__> ok let's say the PTL wins :-> 21:46:54 * nijaba feels empowered! 21:47:05 <nijaba> medium it is then 21:47:26 <nijaba> anything else on the poll? 21:48:00 <nijaba> #topic Review blueprints and progress 21:48:27 <nijaba> so for g2 we currently have 21:48:29 <nijaba> #link https://launchpad.net/ceilometer/+milestone/grizzly-2 21:48:29 <dhellmann> it looks like we only have one g2 blueprint not done, if I'm reading the list right 21:48:45 <dhellmann> ah, 2 21:48:50 <nijaba> dhellmann: 2 actually 21:49:07 <nijaba> we still have more than a month 21:49:07 <yjiang5> anything left for db access? 21:49:16 <jd__> let me check about db access 21:49:19 <nijaba> should we be a bit more agressive? 21:49:43 <jd__> yeah, db access is removed EXCEPT from nova_notifier, but that doesn't matter since it's run INSIDE nova 21:49:46 <yjiang5> I remember only the nova notifier 21:49:52 <jd__> I think we should close this one 21:50:09 <nijaba> enayone disagrees? 21:50:14 <dhellmann> what is the status of removing db access from the nova compute agent? 21:50:22 <dhellmann> when that lands, our notifier will break 21:50:45 <eglynn> yep, good about the no-db-compute work 21:51:01 <eglynn> that's got a pretty long time horizon tho' AFAIK 21:51:19 <jd__> dhellmann: done 21:51:36 <jd__> no, the notifier is run by nova itself 21:51:43 <jd__> not by ceilometer-something 21:51:44 <nijaba> ok, so I am marking it as implemented then 21:51:55 <eglynn> #link https://etherpad.openstack.org/grizzly-nova-no-db-compute 21:52:00 <nijaba> anyone cares to commit on another blueprint for g2? 21:52:25 <dhellmann> jd__: I think some time during grizzly there won't be a database handle or settings available to the notifier plugin, either. 21:52:33 <dhellmann> I think we should be conservative about adding things 21:52:50 <jd__> dhellmann: ok, maybe, but I'd say that's another problem :) 21:52:50 <dhellmann> we have a lot of cleanup work to do, and figuring out the monitoring stuff is going to take a while, too 21:53:02 <dhellmann> jd__: ok :-) 21:53:21 <eglynn> yep, we can always add stuff opportunistically late in the cycle if by any chance we end up with loads of spare bandwidth 21:53:26 <nijaba> eglynn, asalkeld: what about qpid testing? 21:53:42 <nijaba> that should not be too risky 21:53:45 <dhellmann> #link https://blueprints.launchpad.net/nova/+spec/no-db-compute 21:53:58 <eglynn> nijaba: good question, I'll see if I can take that or hand it off 21:54:27 <nijaba> change the target when you have a feel for it 21:54:38 <eglynn> nijaba: cool, will do 21:54:42 <nijaba> thanks 21:55:18 <nijaba> so the only thing left is swift, and I thnk we should see progress soon 21:55:32 <dhellmann> cool 21:55:44 <jd__> fingers crossed 21:55:49 <nijaba> dhellmann: you must be impatient on this one ;) 21:55:54 <jd__> haha 21:56:04 <dhellmann> :-) 21:56:17 <nijaba> ok, anything else on this? 21:56:34 <nijaba> #topic Open discussion 21:57:04 <dhellmann> I'm making good progress on the pecan & wsme work. I should have something to share next week, I think. 21:57:17 <nijaba> zykes-: you wanted to propose something? 21:57:22 <yjiang5> dhellmann: cool 21:57:40 <nijaba> dhellmann: oh, cool. same as for eglynn for updating the bp 21:57:54 <dhellmann> #action dhellmann update pecan port blueprint 21:58:04 <zykes-> nijaba: fyi for people that care, StackSherpa is releasing a Java implementation of billing towards openstack, I'll be working with them on porting to Python 21:58:30 <zykes-> meaning porting it over to Bufunfa that uses Ceilometer as source for one 21:58:31 <nijaba> zykes-: link? 21:58:37 <asalkeld> back 21:58:45 <dhellmann> nice 21:58:50 <zykes-> nijaba: Just talked to them a few mins ago 21:59:02 <zykes-> they'll release a video tonight for it and java code opens next week 21:59:05 <nijaba> zykes-: is it open source? 21:59:10 <zykes-> they sounded very keen on collaborating 21:59:18 <zykes-> nijaba: it will be after what they said 21:59:22 <asalkeld> dhellmann, looked at the ceilometerclient yet? 21:59:23 <nijaba> k 21:59:33 <dhellmann> asalkeld: not in depth :-( 21:59:43 <asalkeld> we need a ceiolmeterclient in openstack/ 21:59:55 <asalkeld> with cli 21:59:57 <dhellmann> it looked like yours was similar to the other libraries, right? 22:00:00 <zykes-> nijaba: I can report next week :) 22:00:03 <yjiang5> dhellmann: where is the tree of the client? 22:00:06 <asalkeld> I tried to 22:00:06 <dhellmann> oh, yeah, we should think about a blueprint for a cli 22:00:14 <jd__> + 22:00:15 <zykes-> they where supposed to opensource today but because of thanks giving they post poned 22:00:15 <nijaba> zykes-: please do and feel free to action youself 22:00:16 <jd__> 1 22:00:28 <asalkeld> so happy to convert to a different format 22:00:33 <dhellmann> yjiang5: asalkeld has one, and we have a little prototype at https://github.com/dreamhost/ceilometerclient 22:00:38 <dhellmann> I think asalkeld's is more complete 22:00:43 <yjiang5> dhellmann: thanks 22:00:48 <zykes-> #action report status on Bufunfa / BillingStack port 22:00:55 <dhellmann> asalkeld: have a link to yours handy? 22:00:58 <zykes-> hmmms, :p 22:01:16 <nijaba> thanks zykes- 22:01:16 <asalkeld> https://github.com/asalkeld/python-ceilometerclient 22:01:56 <asalkeld> dhellmann, do you have any examples of wsme+pecan 22:02:08 <dhellmann> I got permission to release the dude open source, so we'll be working on that soon, too 22:02:12 <nijaba> asalkeld: I think you just won an opp to write a matching bp :) 22:02:13 <dhellmann> asalkeld: that's what I'm working on 22:02:26 <nijaba> dhellmann: \o/ 22:02:27 <asalkeld> so If I make a monitoring api I can start with wsme 22:02:29 <dhellmann> I have our existing API working with pecan by itself, but the wsme parts are taking a little more time 22:02:39 <asalkeld> I have started with flask 22:02:47 <asalkeld> ok 22:03:01 <dhellmann> https://github.com/dhellmann/ceilometer/tree/experimental/pecan 22:03:02 <asalkeld> if you have anything can you email it to me ? 22:03:08 <asalkeld> o, cool 22:03:29 <dhellmann> everything is in the ceilometer_api dir for now (moving it into ceilometer package is on my list) 22:03:36 <dhellmann> there's no wsme there, yet 22:03:49 <dhellmann> give me a couple of days, I have a support request in :-) 22:04:01 <asalkeld> ha 22:04:13 <asalkeld> seems like lots of directory clutter 22:04:14 <zykes-> does it differ from flask much dhellmann ? 22:04:29 <dhellmann> asalkeld: yeah, code generator, but it can be cleaned up a good bit 22:04:38 <dhellmann> zykes-: it uses object dispatch 22:04:55 <dhellmann> the interesting file is https://github.com/dhellmann/ceilometer/blob/experimental/pecan/ceilometer_api/ceilometer_api/controllers/v2.py 22:04:56 <zykes-> dhellmann: meaning ? 22:05:01 <nijaba> dhellmann: I think this should depend on having the user-api, though 22:05:35 <dhellmann> nijaba: it will be fairly easy to add that feature to this when I'm done with the port 22:05:44 <nijaba> cool 22:05:51 <dhellmann> I am using v2 because of some changes to the API, so that can just be another change :-( 22:05:53 <nijaba> so, who writes the bp? 22:05:56 <dhellmann> oop, :-) 22:06:03 <dhellmann> for the user api? 22:06:13 <nijaba> dhellmann: for the cli 22:06:18 <dhellmann> oh 22:06:30 <zykes-> adios peeps, will report back to you next week or later this week in #openstack-metering 22:06:39 <zykes-> might have some updates before the weekend 22:06:41 <asalkeld> I can make one if that helps 22:06:45 * jd__ thinks it's getting late 22:06:51 <nijaba> asalkeld: thanks 22:06:53 <dhellmann> that would be great, asalkeld, I'm running out of hours 22:06:56 <nijaba> jd__: me too 22:07:04 <yjiang5> dhellmann: this pecan changes will not impact API format right? 22:07:15 <jd__> yjiang5: I hope so for dhellmann's sake 22:07:32 <dhellmann> yjiang5: some small changes, I think, but nothing major yet 22:07:37 <asalkeld> what do you mean by format? 22:07:42 <dhellmann> I'm trying to keep it the same 22:07:47 <dhellmann> asalkeld: inputs and return values 22:07:55 <yjiang5> I mean the API compatibility 22:08:02 <asalkeld> I see 22:08:06 <asalkeld> well it's v2 22:08:07 <dhellmann> yjiang5: well, that's why I went with "v2" :-) 22:08:12 <asalkeld> can have big changes 22:08:19 <yjiang5> dhellmann: great 22:08:29 <yjiang5> asalkeld: big changes? ok. 22:08:44 <asalkeld> I am just saying it could 22:08:55 <asalkeld> as in it's version 2 22:08:58 <yjiang5> asalkeld: because of v2 :) 22:09:27 <nijaba> ok, so I think we are running over time and discussion can continue in our chan 22:09:35 <nijaba> what do you say we end the meeting? 22:09:42 <dhellmann> one more thing 22:09:45 <nijaba> k 22:09:52 <eglynn> #link http://wiki.openstack.org/APIChangeGuidelines 22:09:59 <dhellmann> earlier today jd__ and I were talking in the main room and the idea of a bug day came up 22:10:06 <dhellmann> do we have enough bugs to make that worth-while? 22:10:20 <eglynn> (^^^ general principals on what requires an API version bump) 22:10:24 <jd__> for a day, probably 22:10:35 <dhellmann> eglynn: thanks, I'll review that 22:10:35 * eglynn likes bug squashing days 22:11:01 <dhellmann> oh, we're way over time, sorry, I'm not looking at the clock 22:11:02 <eglynn> good for team coherence as well as the obvious goal 22:11:02 <dhellmann> so 22:11:03 <dhellmann> me 22:11:03 <dhellmann> thing 22:11:06 <dhellmann> something to discuss next week? 22:11:10 <jd__> yep 22:11:11 <eglynn> cool 22:11:14 <nijaba> Should that be a week before the g2 misltone? 22:11:47 <nijaba> #action nijaba to set topic for bug day at next meeting 22:11:50 * dhellmann will have to look at a calendar to answer that 22:12:12 <nijaba> anything else? 22:12:20 <dhellmann> nope 22:12:22 <nijaba> 30 sec countdown 22:12:23 <eglynn> nowt from me ... 22:12:23 <asalkeld> all good 22:12:24 <jd__> all clear 22:12:32 <yjiang5> no 22:12:37 <nijaba> thanks everyone 22:12:43 <nijaba> #endmeeting