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