15:00:24 <jd__> #startmeeting ceilometer
15:00:25 <openstack> Meeting started Thu Aug  8 15:00:24 2013 UTC and is due to finish in 60 minutes.  The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:28 <openstack> The meeting name has been set to 'ceilometer'
15:01:07 <sandywalsh> o/
15:01:11 <herndon> o/
15:01:12 <danspraggins> o/
15:01:13 <jd__> #link https://wiki.openstack.org/wiki/Meetings/MeteringAgenda
15:01:15 <thomasm> o/
15:01:18 <apmelton> o/
15:01:20 <llu-laptop> o/
15:01:45 <eglynn> o/
15:01:49 <sileht> o/
15:01:49 <gordc> o/
15:01:51 <nealph> 0/
15:01:56 <jd__> hello everyone
15:02:38 <dragondm> o/
15:02:42 <jd__> I realize I have forgotten to send the agenda to the list
15:02:55 <jd__> sorry about that
15:03:05 <jd__> #topic Review Havana-3 milestone
15:03:13 <jd__> #link https://launchpad.net/ceilometer/+milestone/havana-3
15:03:28 <jd__> so we are really getting late
15:03:38 <eglynn> Alarm history API patches coming soon
15:03:43 <jd__> to the point that ttx will remove blueprints next Tuesday if we don't start merging things
15:03:53 <eglynn> (making good progress on this)
15:03:56 <terriyu> o/
15:04:15 <jd__> you know that guy is scary and not kidding, so we should hurry up
15:04:21 <eglynn> yep, understood
15:04:36 <gordc> jd__, removing 'not started'  blueprints?
15:04:38 <sandywalsh> https://blueprints.launchpad.net/ceilometer/+spec/double-entry-accounting was moved to the stacktach-integration-pt2 BP, which is targeted for icehouse
15:05:00 <jd__> gordc: yeah, and likely only high/medium things since we don't care about low ones
15:05:08 <jd__> sandywalsh: ack
15:05:21 <sandywalsh> I think I have all our other stuff moved
15:05:32 <nealph> jd__: we have one that's been superseded, I think....perhaps others do too. Should everyone be cleaning house?
15:05:45 <jd__> nealph: which one?
15:05:58 <jd__> always a good idea to clean anyway
15:06:17 <sandywalsh> herndon, is going to do a double somersault from the high dive to get https://blueprints.launchpad.net/ceilometer/+spec/extended-client-operations in H3 :)
15:06:29 <terriyu> what happens if I don't get my blueprint done?  (worried)
15:06:41 <nealph> API extensions...I need to look at it a little closer before taking it off. perhaps it's just postpone to Icehouse (it's low anyways)
15:06:43 <gordc> jd__, i think there's some overlap on this bp: https://blueprints.launchpad.net/ceilometer/+spec/count-api-requests
15:06:53 <gordc> maybe you want to sync up on that.
15:06:55 * terriyu 's blueprint: https://blueprints.launchpad.net/ceilometer/+spec/api-group-by
15:07:33 <jd__> terriyu: well, that shouldn't happen because we need it so I'll step in I think on this one
15:07:47 <jd__> nealph: ack
15:08:07 <jd__> gordc: yes, there's overlap with what you're doing we shall discuss this at some point
15:08:20 <gordc> jd__, cool cool
15:08:23 <jd__> gordc: I have a plan, didn't have time to expose yet
15:08:49 <llu-laptop> jd__, Toni said he didn't have much time to merge https://blueprints.launchpad.net/ceilometer/+spec/monitoring-physical-devices, and asked me to do it.
15:09:03 <jd__> llu-laptop: what will you do?
15:09:06 <llu-laptop> jd__: I'll try to start merge it next week.
15:09:24 <sandywalsh> my big concern is oslo-common reviews taking a really long time
15:09:25 <llu-laptop> jd__: got stuck by other things in 2 weeks. :-(
15:09:54 <jd__> sandywalsh: feel free to add me as reviewer on that, I do it once in a while but I can hurry on some
15:10:02 <jd__> llu-laptop: ack
15:10:08 <sandywalsh> jd__, will do
15:10:16 <nsaje> o/ (didn't notice meeting was on a different channel)
15:10:50 <jd__> anything else on that topic?
15:11:15 <jd__> #topic Release python-ceilometerclient?
15:11:41 <jd__> we need to release it after https://review.openstack.org/#/c/40450/ lands to please mordred
15:11:54 <mordred> yes! please!
15:12:01 <mordred> it will make bunny rabbits smile
15:12:03 <eglynn> also just proposed https://review.openstack.org/#/c/40888
15:12:14 <jd__> mordred: btw did you notice my comment about the huge amount of Change-Id in that?
15:12:20 <eglynn> (add support for new alarm repeat_actions attribute)
15:12:30 <jd__> eglynn: ah so cool
15:12:37 <mordred> jd__: I will fix - (there was a bug in my script)
15:12:53 <jd__> mordred: ack
15:12:57 <eglynn> but other than that, defo should release soon to pick up fix to the auth_token logic
15:13:23 <jd__> I seem to remember only me or eglynn can release
15:13:36 <mordred> jd__: fixed and uploaded
15:13:38 <eglynn> jd__: yep, I think that's correct
15:13:44 <gordc> eglynn, that auth_token fix is already merged?
15:13:47 <jd__> so I think I'll take the action for this time?
15:13:58 <eglynn> gordc: yep https://bugs.launchpad.net/python-ceilometerclient/+bug/1207441
15:14:00 <uvirtbot> Launchpad bug 1207441 in python-ceilometerclient "keystoneclient.auth_token property is prematurely evaluated, misses refresh on token expiry" [High,Fix committed]
15:14:08 <jd__> #action jd__ Release python-ceilometerclient
15:14:28 <eglynn> gordc: sorry, wrong link ... https://review.openstack.org/39754
15:14:34 <gordc> eglynn, cool cool. just checking to see if i needed to review
15:14:47 <eglynn> gordc: cool
15:15:07 <jd__> #topic Event API Blueprint Modification
15:15:29 <jd__> #link https://blueprints.launchpad.net/ceilometer/+spec/specify-event-api
15:15:29 <herndon> https://wiki.openstack.org/wiki/Ceilometer/blueprints/Ceilometer-specify-event-api
15:16:37 <herndon> In a code review yesterday, jd_ suggested a modification to the event api. As this was reviewed by a number of people, I wanted to get some feedback. I think sandywalsh and dhellman were involved substantially?
15:17:08 <jd__> dhellmann_ is away today
15:17:10 <dragondm> me as well
15:17:16 <herndon> basically, should the traits api be moved under /event_types?
15:18:01 <sandywalsh> hmm
15:18:10 <herndon> this call was confusing: /v2/events/(event_type)/traits/ - should we change it to /v2/event_types/(event_type)traits
15:18:43 <jd__> if 'traits' is about listing the traits for an event type, yes
15:18:46 <sandywalsh> yeah, I think that's a good suggestion
15:18:54 <jd__> unless I misunderstood the /traits meaning :)
15:19:19 <sandywalsh> event_types is generic and /events is specific (like a class vs an instance)
15:19:40 <jd__> yeah that makes sense to me
15:19:53 <herndon> allright. I think /v2/events/(event_type)/traits/(trait)/ makes sense still. agree?
15:19:53 <jd__> you could have /v2/events/(event_id)/traits/ too
15:20:07 <jd__> herndon: no
15:20:18 <jd__> you can't have an event_type a key in /events/
15:20:22 <jd__> you can't have an event_type as key in /events/
15:20:31 <sandywalsh> I tend to lean towards /event_types/<event_name>/traits I think
15:20:51 <jd__> herndon: don't mix keys under a path
15:21:00 <herndon> ok :)
15:21:24 <herndon> I will update the BP and submitted a new patch with this change.
15:21:25 <sandywalsh> jd__, so how would you suggest "give me all events of this type"?
15:21:51 <sandywalsh> oh, I see your point
15:21:53 <jd__> sandywalsh: /v2/events?filter=
15:21:59 <sandywalsh> yes, absolutely
15:22:17 <jd__> the meter API is crap in this regard btw, I hope we'll fix this in v3 :(
15:22:36 <jd__> (and in a lot of other things anyway)
15:22:56 <herndon> If we added /v2/events/(event_type), it could return all events of a type without having to use query filters.
15:23:15 <herndon> then traits may make more sense as /v2/events/(event_type)/traits and /v2/events/(event_type)/traits/(trait_name)
15:23:17 <thomasm> herndon: Why do we not want to use query filters?
15:23:41 <jd__> herndon: but if I have an event id of 'foobar' and a message type of 'foobar' you /events/foobar is going to fail; don't mix keys!
15:24:05 <herndon> ok. so ignore my suggestion :p
15:24:49 <sandywalsh> yeah, sorry herndon I should have picked up on that before. I think jd__'s suggestion makes sense. The filter approach is cleaner.
15:24:50 <jd__> and earlier discussion with sandywalsh seems to indicate having message_id as primary key is really good idea :)
15:25:02 <jd__> so everything's going to connect
15:25:13 <herndon> okey dokey, I'm satisfied.
15:25:17 <apmelton> is there a reason we can't use path params?
15:25:35 <apmelton> /v2/events/;event_type=x/traits?
15:25:39 <jd__> apmelton: doesn't make sense because things aren't hiearchical
15:25:45 <sandywalsh> the path param should be related to the parent resource
15:26:01 <sandywalsh> so /events/<message_id>
15:26:13 <sandywalsh> but other things should be filter params
15:26:33 <jd__> agreed
15:27:06 <jd__> #topic Open discussion
15:28:04 <sandywalsh> lovely day
15:28:08 <jd__> :-)
15:28:19 <gordc> sandywalsh, agreed :)
15:28:35 <terriyu> it's finally not sweltering
15:28:50 <nsaje> 40 degrees C here :(
15:29:17 <llu-laptop> me too :(
15:29:21 <sandywalsh> ouch
15:29:24 * gordc wonders how long weather talk can continue for.lol
15:29:41 <jd__> I just wish they didn't spread manure in the field near the garden
15:29:42 <dragondm> high is 104F here.
15:29:42 <eglynn> gordc: indefinitely if necessary ;)
15:29:50 <thomasm> So, I was digging into the resource metadata bug.
15:29:55 <jd__> we still have this place for 31 minutes, enjoy
15:29:55 <gordc> eglynn, we got 30mins.
15:30:13 <thomasm> Why do we use the Meter table instead of the Resource table when querying for resources?
15:30:29 <jd__> thomasm: in which driver?
15:30:50 <jd__> well actually my question doesn't really matters
15:31:02 <jd__> the resource table is pretty useless
15:31:17 <jd__> when you want to know which resources where sampled during a certain time
15:31:23 <jd__> you HAVE to check the meter table
15:31:28 <thomasm> Well I was looking in SQLAlchemy, but the resource table is just a rollup of the current resource state.
15:31:36 <thomasm> YEah, that's what I figured
15:31:43 <thomasm> anyway, the reason we're getting old metadata is because of the group_by
15:31:44 <jd__> it's a bad rollup
15:31:46 <thomasm> in get_resources
15:32:00 <jd__> I'm pretty sure these tables should go away… I'm going in that direction in the MongoDB driver
15:32:06 <epende_> So any objection to adding resource_metadata to Meter?
15:32:10 <thomasm> IT's already there
15:32:16 <thomasm> Each meter has resource metadata associated
15:32:24 <jd__> thomasm: feel free to rewrite without using the resource table yeah
15:32:43 <jd__> thomasm: I just have a patch that went in for that in MongoDB using aggregate()
15:33:05 <jd__> s/in MongoDB/in our MongoDB driver/
15:33:28 <jd__> same applies to user and projects, which are not even connected to the v2 api I *think*
15:33:38 <epende_> thomasm:  Is the doc not up to date on Meter, because I don't see it there
15:33:56 <jd__> epende_: we're talking about storage, not what the API exposes
15:34:29 <epende_> Ok to add an implementation to allow metadata to be exposed and used for filtering?
15:34:35 <epende_> on Meter
15:35:02 <epende_> along with an update to the API
15:35:58 <thomasm> jd__: I'm not as familiar with Mongo. What're you aggregating there? The group_by is used to return a list of resources, but when you want the latest on a single resource, you have to just query on that and get the last one - that's where the Resource table would come in handy, but yes we lose the timestamp functionality - which isn't really useful unless we're trying to get resource latest state within a specific time peri
15:35:58 <thomasm> od; seems odd.
15:36:02 <jd__> we already have that, I don't think we're talking about the same thing epende_
15:36:42 <jd__> thomas: well aggregate in MongoDB is what you would call group by I guess in SQL :)
15:36:45 <gordc> epende_, metadata is exposed through Sample
15:37:08 <thomasm> jd__: ah, okay. The current SQLAlchemy driver uses the meter table, but that group_by screws it up when it's looking for the latest resource state.
15:37:11 <jd__> thomasm: I consider the general case as having a timestamp range, and that just is useless in the end
15:37:25 <jd__> s/that/the resource table/
15:37:38 <epende_> gordc: Yes, but that requires getting sample(s) in order to select meters based on metadata
15:37:41 <epende_> possibly many samples
15:38:09 <epende_> It would be nice to have a way to get certain Meters without getting all the Samples
15:38:09 <thomasm> jd__: Fair. The API spec shows that it returns last updated timestamp (I think) with the resource_id query.
15:38:29 <thomasm> jd__ I'll patch it up and see what we get :)
15:38:33 <jd__> thomasm: that's just went in a few hours ago
15:38:43 <epende_> Getting a sample requires the client to know what the meter id is
15:38:57 <epende_> Which means the client must have foreknowledge of the meter id list
15:39:12 <epende_> Which prevents an ignorant client from traversing the API
15:39:26 <thomasm> jd__: What went in a few hours ago?
15:39:40 <gordc> epende_, i believe it's because metadata isn't necessarily the same everytime a meter is captured... the same reason meter dpesm
15:39:41 <jd__> thomasm: the change that returns first and last timestamp of a resource
15:39:49 <thomasm> jd__: Ohhhhh
15:39:59 <thomasm> jd__: I'll have to pull
15:39:59 <gordc> s/meter dpesm/meter doesn't have a volume/
15:40:02 <thomasm> Thanks
15:40:07 <jd__> thomasm: sure thing! :-)
15:40:12 <epende_> gordc, does it have to be the same each time?
15:41:04 <gordc> epende_, the way i see it, Meters are just a roundup/overview of Samples.
15:41:07 <epende_> A similar discussion was had here:  https://bugs.launchpad.net/ceilometer/+bug/1194593
15:41:09 <uvirtbot> Launchpad bug 1194593 in ceilometer "Meter object in reporting API does not allow resource_metadata attribute" [Wishlist,Triaged]
15:42:08 <gordc> epende_, whoa, a lot of discussion there. i'll need to read up on that. ignore my comments :)
15:42:19 <epende_> NP, should have thrown that out there first :)
15:42:47 <epende_> Thanks for the feedback
15:43:52 <jd__> #endmeeting