21:00:55 <jd__> #startmeeting ceilometer
21:00:55 <jd__> #link https://wiki.openstack.org/wiki/Meetings/MeteringAgenda
21:00:55 <openstack> Meeting started Wed Mar 27 21:00:55 2013 UTC.  The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:59 <openstack> The meeting name has been set to 'ceilometer'
21:01:02 <jd__> oyé oyé
21:01:14 <eglynn_> o/
21:01:21 <dhellmann> o/
21:01:22 <llu-laptop> o/
21:01:32 <shengjie_home> o/
21:01:36 <DanD> o/
21:02:06 <esdaniel> o/
21:02:15 <epende> o/
21:02:16 <jd__> hi everyone, nice to see you
21:02:33 <nealph> \o (right-handed)
21:02:48 <jd__> let's start
21:02:49 <jd__> #topic eglynn amalgemate summit alarming proposals from 5 sessions to 3
21:02:53 <asalkeld> o/
21:02:58 <jd__> this is already done
21:03:12 <jd__> thanks to eglynn_ I've a better understanding on how I can fit sessions together
21:03:18 <eglynn_> yep we discussed a potential session amalgamation on IRC
21:03:18 <jd__> btw this is the last days for submitting sessions
21:03:28 <eglynn_> ... this will fall out of the mix when the session scheduling happens
21:03:29 <jd__> hi yjiang5_
21:03:37 <eglynn_> (sessions can't be edited by the proposer once preapproved)
21:03:38 <yjiang5_> jd__: hi
21:04:12 <jd__> eglynn_: you'd like to edit?
21:04:21 <jd__> I can un-preapproved if you need
21:04:33 <eglynn_> jd__: yep, that sounds sensible
21:04:35 <jd__> but I can merge anyway later sessions with one click
21:04:46 <eglynn_> fair enough, which ever is most conveneient
21:05:07 <shengjie_home> jd__: does that mean we can't associate bps to the topics anymore?
21:05:08 <jd__> well I think it's better for me to merge to emphasize we didn't get enough slots
21:05:10 <jd__> :-)
21:05:27 <eglynn_> jd__: cool
21:05:29 <jd__> shengjie_home: if your session is preapproved, you can't, but I can un-preapprove if you ened
21:05:51 <jd__> s/ened/need/
21:06:13 <shengjie_home> just two bps want to associate to eglynn's topic, they are going through our internal review process now
21:06:36 <jd__> #info eglynn gave hints to jd__ about how to merge alarming sessions
21:07:07 <jd__> shengjie_home: ok, then let's synchronize the three of us if you want to do that by the end of the week
21:07:17 <shengjie_home> i guess we can take it off line when I have them ready
21:07:22 <shengjie_home> jd__: cool
21:07:24 <jd__> affirmative
21:07:30 <eglynn_> shengjie_home: once your BPs are internally reviewed, feel free to pass them around for review within this group
21:07:49 <yjiang5_> shengjie_home: what's the BP about?
21:07:59 <shengjie_home> eglynn_:thanks
21:08:24 <shengjie_home> yjiang5_:it's alarming, monitoring related, i will have them ready soon, keep u guys updated
21:08:27 <dhellmann> yes, please, let's make sure we all have plenty of time to read the blueprints before the summit
21:08:43 <yjiang5_> shengjie_home: thanks.
21:09:28 <jd__> going on with action from last week if that's ok
21:09:43 <jd__> #topic eglynn get ceilo:stable/grizzly branch set up
21:09:45 <eglynn_> so as far as I can make out, the stable branch is only cut once the final release tag is laid down
21:09:48 <shengjie_home> yjiang5_:np, we just happen to have a heavy process :( internally, sorry about the delay
21:10:17 <eglynn_> so I'll re-action, assuming that's still a couple od days away ...
21:10:29 <eglynn_> #action eglynn get ceilo:stable/grizzly branch set up
21:10:38 <dhellmann> eglynn_: won't that happen automatically as part of the release process?
21:10:56 <asalkeld> I was about to say the same
21:10:58 <jd__> eglynn_: yeah I think we can only do that once we have released 2013.1
21:11:09 <jd__> we just need to ping ttx to do that at some point I guess
21:11:16 <jd__> he already cut milestone-proposed for us
21:11:28 <eglynn_> dhellmann: not sure for ceilo, as our stable branch won't be managed by the stable-maint team for the H cycle
21:11:40 <eglynn_> but I'll check with ttx in any case ...
21:11:42 <dhellmann> ok
21:11:54 <jd__> eglynn_: yeah but I'd think that branch is cut by ttx -- but doesn't cost to check with him anyway
21:11:59 <eglynn_> cool
21:12:14 <jd__> the guy is nice (AND HE IS READING THIS CHANNEL)
21:12:21 <eglynn_> :)
21:12:42 <jd__> #topic jd__ Ask Nova team is a session talking about Ceilometer/Cell is worth it
21:12:53 <jd__> jd__: go ahead
21:12:56 <jd__> jd__: thanks!
21:13:12 <jd__> so I sent a mail to the main implementer of nova cell
21:13:18 <jd__> and I didn't get any answer
21:13:38 <nealph> So do we reach out to other core devs on that team?
21:13:41 <dhellmann> I know this was something sandywalsh asked about, maybe he can help get the right person's attention
21:14:02 <eglynn_> both being RAX-ers and all ...
21:14:36 <jd__> I don't know, in the end I may just ask on openstack-devel but not sure we'll get more attention
21:14:54 <jd__> but I'll try anyway!
21:15:15 <jd__> #action jd__ Send a mail on openstack-devel to get more insight about nova cell and ceilometer support to know if it's worth a session
21:15:35 <jd__> #topic Release information
21:15:45 <jd__> so we released Grizzly RC1
21:15:49 <asalkeld> (nova session at summit?)
21:16:06 <jd__> asalkeld: it has been proposed inside ceilometer, but I'd love to reassign to nova :-)
21:16:06 <eglynn_> yep on the nova track if poss
21:16:23 <eglynn_> (save us one session from our quota ....)
21:16:36 <asalkeld> just to get some feedback
21:17:03 <dhellmann> plus, if it's on our track, we can't be sure that anyone from nova will be there to help.
21:17:11 <dhellmann> they might have a conflicting session
21:17:29 <dhellmann> so, woo! for Grizzly RC1!
21:17:36 <jd__> #action jd__ reassign nova-cell/ceilometer session to nova
21:17:48 <llu-laptop> what about python-ceilometerclient, any information about the process of releasing a client library?
21:17:54 <jd__> llu-laptop: good question
21:18:01 <jd__> I *think* we can release it whenever we want
21:18:05 <jd__> and that we have the power to do so
21:18:08 <dhellmann> llu-laptop: I believe the release happens automatically when we push a tag up to the repository.
21:18:16 <jd__> as dhellmann says
21:18:18 <dhellmann> the tag becomes the version number
21:18:51 <jd__> I think we should do a first release, for the sake of releasing
21:18:55 <jd__> who's up for that?
21:18:56 <dhellmann> +1
21:18:59 <asalkeld> +1
21:19:04 <llu-laptop> and that tag will automatically trigger a new version on pypi?
21:19:08 <jd__> and who's for doing it?
21:19:10 <dhellmann> llu-laptop: yes
21:19:21 <jd__> llu-laptop: yes, everything is automagic in openstack!
21:19:32 <asalkeld> I can, what's the version
21:19:34 <dhellmann> s/openstack/magicstack/
21:19:36 <asalkeld> 1.0.0
21:19:39 <asalkeld> ?
21:20:03 <eglynn_> whoever ends up doing the release, it would be good to capture the recipe on the wiki
21:20:10 <dhellmann> that seems reasonable
21:20:28 <eglynn_> (so that anyone else can easily run the incantations next time ... )
21:20:37 <asalkeld> sure
21:20:45 <esdaniel> i was going to say, i'd like to be around to follow the steps, could document for the releaser (asalkeld)
21:20:48 <jd__> 1.0.0 sounds fine indeed
21:21:08 <asalkeld> cool, I'll do it today
21:21:16 <asalkeld> and document
21:21:16 <eglynn_> great!
21:21:31 <asalkeld> sounds like "git tag & git push"
21:21:38 <jd__> #action asalkeld to release python-ceilometerclient 1.0.0 and document the release process
21:22:10 <asalkeld> (I have a review in client)
21:22:13 <jd__> asalkeld: that's exactly what Bilbo said with the ring thing etc, and see what happened then!
21:22:28 <asalkeld> har
21:22:34 <jd__> be prepared buddy
21:23:03 <asalkeld> any reviewers https://review.openstack.org/#/c/25503/
21:23:12 <asalkeld> (before releasing)
21:23:28 <jd__> asalkeld: I'll take a look
21:23:32 <eglynn_> asalkeld: I'll take a look after meeting
21:23:42 <asalkeld> thx
21:23:45 <jd__> #topic Open discussion
21:24:15 <asalkeld> I have some questions
21:24:30 <asalkeld> why do we not record the resource type
21:24:53 <dhellmann> I think we assumed it was implicit with the meter type
21:24:59 <asalkeld> so you can query on resource_type=Instance|whatever
21:25:12 <dhellmann> I'm starting to think we may want it now, though
21:25:19 <asalkeld> ok
21:25:22 <asalkeld> also:
21:25:25 <jd__> because we didn't see the need back then, and because it's not standardize, a bit the same problem we had with units
21:25:45 <asalkeld> can we record the create/destroy timestamps?
21:25:47 <jd__> but I agree that wouldn't be something stupid
21:25:49 <yjiang5_> will different resource type have same meter type?
21:26:05 <jd__> yjiang5_: probably?
21:26:11 <jd__> asalkeld: how, why?
21:26:34 <asalkeld> so I can see what instances we created in the last X mins/hours
21:26:51 <asalkeld> is that useful to others?
21:27:14 <asalkeld> I wanted to make a "dashboard" for ceilo cliet
21:27:28 <dhellmann> that does seem like it would be useful
21:27:31 <asalkeld> so you can see what is happening on your cloud
21:27:32 <eglynn_> +1
21:27:44 <asalkeld> what has been created/destroyed
21:27:48 <dhellmann> what we did for billing was just find the resources that had been updated in the last X minutes
21:27:53 <asalkeld> what are the busy instances
21:28:02 <dhellmann> but that doesn't tell the same thing
21:28:10 <asalkeld> yea
21:28:20 <eglynn_> how much change would be involved to set the resource_type across the board?
21:28:20 <dhellmann> I believe the stacktach guys are saving the create/delete timestamps separately, too
21:28:22 <jd__> asalkeld: I think it's a good idea, but I don't think we can store this as it is right now
21:28:36 <jd__> I mean, it does require a certain amount of change in the storage drivers
21:28:42 * eglynn_ wonder if too invasive to sneak into an RC2
21:28:43 <jd__> we can't store that as 'meters'
21:28:59 <asalkeld> so in the db we could see if it exists
21:29:03 <dhellmann> eglynn_: yeah, this would definitely be a havana change
21:29:07 <eglynn_> k
21:29:08 <shengjie_home> it does, also counter obj needs to be changed to have resource type
21:29:13 <asalkeld> (and have a create date)
21:29:28 <asalkeld> so there is no rush for this
21:29:33 <asalkeld> just an idea
21:29:40 <dhellmann> part of the trouble is the event being given to the storage driver has the details stripped
21:29:44 <asalkeld> nice selling point for ceilo
21:29:47 <jd__> asalkeld: sounds like a good one, you should start by creating a bp I guess
21:29:48 <dhellmann> so we don't know that it was a create or a delete, just an update
21:30:07 <jd__> dhellmann: we can build a new interface to the storage driver for that?
21:30:14 <asalkeld> cool, I'll make a bp
21:30:32 <jd__> dhellmann: I mean just changing the/adding a record function
21:30:44 <asalkeld> I think it's not a bad idea to be explicit about resource management
21:30:56 <dhellmann> jd__: I think, based on some things sandywalsh has said, we'll want a storage API that receives the notifications themselves
21:30:56 <shengjie_home> so all the storage drivers need to have a small bp for that?
21:31:18 <asalkeld> I'll make one to start with
21:31:43 <asalkeld> that's all from me
21:31:44 <dhellmann> asalkeld: look through the summit session blueprints, I think one may already include some details like this
21:31:53 <asalkeld> cool
21:32:23 <jd__> dhellmann: concerning the collector as it designed currentl that remains to be seen -- for other tools, I wouldn't say
21:32:40 <shengjie_home> dhellmann: i have a bp coming up related to that too
21:32:44 <jd__> shengjie_home: no, I don't think so
21:33:43 <dhellmann> jd__: we'll have to see what we want to actually do, but I think the idea was to save the raw notification for auditing
21:35:53 <jd__> dhellmann: I know, it remains to be seens if auditing is part of the "openstack metering project"
21:36:25 <dhellmann> gotcha
21:37:05 <shengjie_home> jd__: I meant like the record_metering_data() etc etc needs to be updated to store resource_type in each driver
21:37:20 <dhellmann> shengjie_home: yes, but I don't think we need a separate blueprint for each driver, do we?
21:37:41 <shengjie_home> aha , u were talking about bp. no , probably not
21:37:53 <jd__> shengjie_home: indeed, but we already do that work in order to add the 'unit' field, it's not really a challenge now
21:38:07 <shengjie_home> jd__:agree
21:38:22 <asalkeld> can't we just record the first part of "event_type"
21:38:31 <asalkeld> ~= resource type
21:39:22 <asalkeld> compute/volume etc
21:39:23 <dhellmann> asalkeld: that seems like a good approximation
21:39:57 <asalkeld> maybe then this could be done in one place too
21:40:22 <asalkeld> (sorry guys - I need to go take kids to school)
21:40:53 <jd__> cya asalkeld
21:42:33 <dhellmann> oh, I gave a presentation at pycon us about a week ago talking a bit about ceilometer's design
21:42:36 <dhellmann> #link http://pyvideo.org/video/1789/dynamic-code-patterns-extending-your-application
21:42:55 <eglynn_> cool
21:42:59 <shengjie_home> cool
21:43:07 <jd__> great
21:43:09 <zzs> nice!
21:43:26 <llu-laptop> cool
21:44:40 <dhellmann> that's all I have for today
21:45:03 <dhellmann> If there isn't anything else, are there any objections to wrapping up a few minutes early?
21:45:04 <eglynn_> ich auch
21:45:14 <yjiang5_> I'm taken away to another urgent task recently, so will not work on ceilometer
21:45:21 <yjiang5_> at least for one month
21:45:21 <dhellmann> :-(
21:45:30 <dhellmann> ah, ok, a time limit, that's ok then :-)
21:45:44 <eglynn_> yjiang5_: hurry back! :)
21:45:50 <dhellmann> definitely!
21:45:56 <shengjie_home> yjiang5_: :)
21:45:59 <jd__> +1
21:45:59 <yjiang5_> Sure :)
21:46:50 <llu-laptop> +1
21:47:51 <jd__> anything else or should I close this meeting?
21:48:00 <zzs> how about the healthnmon?
21:48:31 <eglynn_> they were going to propose something for summit IIRC
21:48:42 <dhellmann> I think I saw a conference presentation from them
21:48:55 <eglynn_> a-ha, ok ...
21:49:05 <nealph> sandywalsh has a bp out there on a new ceilometer client...any precedence for suggesting some else's bp for discussion? He's not here to defend himself...
21:49:21 <nealph> s/some/someone
21:49:55 <zzs> eglynn_ dhellmann: I see, thank you.
21:50:05 <ttx> jd__: yes, stable/grizzly is cut at release time
21:50:12 <jd__> ttx: thanks for the answer
21:50:14 <eglynn_> ttx: cool, thanks!
21:51:23 <nealph> summit discussion, that is.
21:51:44 <dhellmann> nealph: I think our summit sessions are full already, aren't they?
21:51:48 <llu-laptop> is there any scheduled summit  to talk with healthnmon guys ?
21:52:41 <nealph> that may be...I'll see if I can take it up offline with him.
21:53:37 <jd__> I'd be happy to plan a session with healthnmon but I don't feel like running after them
21:54:05 <eglynn_> +1
21:55:18 <jd__> anything else, we still have 5 minutes
21:55:43 <esdaniel> hai ;-)
21:56:27 <jd__> ok, thanks guys
21:56:30 <jd__> #endmeeting