16:01:26 <nijaba> #startmeeting
16:01:26 <nijaba> #chair nijaba
16:01:26 <nijaba> #meetingname ceilometer
16:01:26 <nijaba> #info agenda http://wiki.openstack.org/Meetings/MeteringAgenda
16:01:27 <openstack> Meeting started Thu May 17 16:01:26 2012 UTC.  The chair is nijaba. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:29 <openstack> Current chairs: nijaba
16:01:30 <openstack> The meeting name has been set to 'ceilometer'
16:01:37 <nijaba> #topic meeting organisation
16:01:37 <nijaba> #info This is 3/6 meetings to decide the details of the architecture of the Metering project https://launchpad.net/ceilometer
16:01:37 <nijaba> #info Today's focus is on the definition of external REST API
16:01:37 <nijaba> #info There has not been enough discussions on the list to cover all aspects and the focus of this meeting was modified to cope with it.#info The meeting is time boxed and there will not be enough time to introduce inovative ideas and research for solutions.
16:01:37 <nijaba> #info The debate will be about the pro and cons of the options already discussed on the mailing list.
16:01:50 <nijaba> any remarks regarding the organozation of the meeting?
16:02:09 <nijaba> I guess that's a no :)
16:02:14 <nijaba> #topic actions from previous meetings
16:02:26 <nijaba> #info dachary add info to the wiki on the topic of poll versus push
16:02:44 <nijaba> dachary is not able to join us today, but I can confirm that this was done
16:02:53 <nijaba> any remarks about it?
16:03:19 <nijaba> ok, moving on
16:03:25 <nijaba> #info dhellmann: reformulate the API proposal as a start point for the dicussion on the ML
16:03:26 <dhellmann> which section of the wiki page was that in?
16:03:55 <nijaba> #architecture IIRC
16:03:57 <dhellmann> I sent email to the list a couple of days ago, and we have since had a discussion about the new presentation of the API that you put forward
16:04:20 <nijaba> yup, I think we can mark this one as done too :)
16:04:24 <dhellmann> nijaba, aha, I found it
16:04:52 <nijaba> #dachary push next meetings one week
16:05:24 <nijaba> so as we had to continue the discussion on APU, the meeting schedule was indeed pushed by one week
16:05:29 <nijaba> done as well...
16:05:49 <nijaba> ok, let's move one then
16:05:55 <nijaba> #topic Agree on update to schema to include JSON formated metadata
16:05:55 <nijaba> #link http://wiki.openstack.org/EfficientMetering#Storage
16:06:11 <nijaba> any comment on this change?
16:06:37 <dhellmann> to summarize, it replaces the "payload" field with a "resource_metadata" field
16:06:56 <dhellmann> the new field is a JSON value with the content left up to the resource type, correct?
16:07:02 <nijaba> and specify the use of a json description in that field
16:07:08 <nijaba> correct
16:07:19 <dhellmann> that works for my needs
16:07:26 <nijaba> +1 for me
16:07:47 <dhellmann> some of the early requirements came from Dan from HP, is he here?
16:08:04 <nijaba> guess not...
16:08:18 <nijaba> should we not that as agreed?
16:08:19 <flacoste> i'm not too hot on the use of json payload (means it's hard to index and query), but i'm not too fussed either :-)
16:08:49 <dhellmann> are we specifying how that data will be stored, or what the message looks like?
16:08:53 <nijaba> flacoste: given that we are not planning to allow searches on it, it should work
16:09:08 <nijaba> dhellmann: not so far.  left to the implementor
16:09:14 <flacoste> dhellmann: the section is called 'Storage', but i wonderd the same thing
16:09:39 <dhellmann> for the first version the message format and storage format could potentially be the same, but we can optimize that later
16:09:52 <nijaba> I guess we can have a disussion on the schema of this field at a later point?
16:09:56 <dhellmann> sure
16:09:58 <flacoste> if it's only the meter message format, then i have no concerns
16:10:09 <flacoste> +1
16:10:23 <nijaba> marking this as agreed then
16:10:29 <dhellmann> +1
16:10:40 <nijaba> #agreed to update to schema to include JSON formated metadata
16:10:56 <nijaba> #topic Agree on API proposal
16:10:56 <nijaba> #link http://wiki.openstack.org/EfficientMetering/APIProposalv1
16:11:39 <nijaba> so I tried to summarize the discussion on the API with a detailed proposal for the REST API
16:11:49 <nijaba> most of you have already commented on it
16:12:01 <nijaba> any further remark?
16:12:30 <dhellmann> I am +1 on the current list of API endpoints
16:12:35 <nijaba> flacoste: still convinced we should not do storage and API?
16:12:58 <nijaba> or did our arguments make sense?
16:13:02 <flacoste> well
16:13:17 <flacoste> i'm not totally convinced yet
16:13:20 <flacoste> we probably need something
16:13:33 <flacoste> not sure it's the first thing we should be thinking about anymore
16:13:39 <flacoste> but it's not that important either
16:13:41 <dhellmann> fwiw, I probably won't use all of the endpoints we have described in our integration
16:13:47 <flacoste> i'll continue the discussion on the list
16:13:52 <nijaba> ok
16:13:57 <flacoste> but i think what is being discussed here
16:13:57 <dhellmann> but the list that's there makes sense
16:13:59 <flacoste> makes sense
16:14:15 <nijaba> so, on the current API proposal, let's vote...
16:14:21 <nijaba> +1 for me
16:14:24 <dhellmann> +1
16:14:48 * flacoste abstains
16:15:01 <nijaba> #agree on API proposal http://wiki.openstack.org/EfficientMetering/APIProposalv1
16:15:22 <nijaba> #topic Agree on format for date_time
16:15:22 <nijaba> #info Suggestion is to use ISO but seeking validation for best practice for REST
16:15:47 <nijaba> any pros and cons about using ISO format for this?
16:16:06 <dhellmann> I asked some of the guys at DreamHost who do more REST than I do, and they said ISO 8601 was easy to parse and supported in a lot of libraries already
16:16:23 <dhellmann> they also suggested using UTC times to avoid timezone issues within the server
16:16:38 <nijaba> dhellmann: oh yes!
16:16:47 <dhellmann> which makes sense to me, since I've fought that fight a few times :-)
16:16:52 <flacoste> yes, to UTC!
16:17:01 * dhellmann likes the easy decisions
16:17:03 <nijaba> #action nijaba to add the use to UTC for datetime
16:17:22 <nijaba> oh, I forgot another action
16:17:43 <nijaba> #action flacoste to follow on the discussion about a bus only implementation
16:18:13 <nijaba> ok, so I guess we are all in agreement about datatime format?
16:18:23 <dhellmann> it sounds like it
16:18:54 <nijaba> #agreed to use ISO for datetime
16:19:11 <nijaba> #topic Agree on the use of a transparent cache for aggregation
16:19:48 <nijaba> I personally think this is outside the scope of the high level design we are currently doing
16:20:25 <nijaba> but I think that we should agree that the main thing we store are atomic events
16:20:44 <dhellmann> what else would we store?
16:20:54 <nijaba> and that we can store other "comodity" information for perfomance reasons, such as agregation of values
16:21:17 <nijaba> but this should be left to "the implementor"
16:21:53 <flacoste> i don't understand what 'transparent cache for aggregation' means
16:22:07 <flacoste> but it does sound out of scope :-)
16:22:31 <nijaba> flacoste: in order to reduce the db traversals, we may store result of some complexe queries in the database for a set period of time
16:22:50 <flacoste> that's implementation detail for sure
16:22:58 * nijaba nods
16:23:03 <dhellmann> yeah, we expect to do that by adding data to our existing billing system
16:23:22 <dhellmann> I'm planning to ask for data, process it, and put it somewhere else
16:23:32 <dhellmann> so caching in ceilometer won't be that helpful for us
16:23:43 <nijaba> ok, noting agreement on this is implementation details
16:23:58 <nijaba> #agreed caching is an implementation detail
16:24:11 <nijaba> heh, we are moving fast today
16:24:21 <nijaba> we actually have time left for....
16:24:28 <nijaba> #topic Open discussion
16:25:12 <nijaba> anyone?
16:25:16 <dhellmann> I mentioned this on the list or during the last meeting, but one thing not handled by any of the existing counters is "discrete" events
16:25:36 <dhellmann> for example, we might have a small charge to upload a new image to glance, then charge on a recurring basis for the storage
16:25:52 <dhellmann> or we might charge a flat rate to create an instance
16:25:52 <nijaba> why not add a counter for those then?
16:26:07 <dhellmann> hmm
16:26:07 <nijaba> they are countable by number of occurence
16:26:12 <flacoste> number of instances started in period?
16:26:13 <dhellmann> I guess that makes sense -- right
16:26:20 <flacoste> number of glance uploads in period?
16:26:32 <dhellmann> most of the examples are accumulated values, I wasn't thinking in units of "number" :-)
16:26:33 <nijaba> I go 3 images upload betwen then and now, for example
16:26:54 <dhellmann> ok, well, that problem is solved then
16:26:58 * nijaba blames crappy keyboard for missing letters :)
16:27:29 <nijaba> dhellmann: you may want to document the additional counters and specify that they won't carry volume information
16:27:49 <nijaba> dhellmann: do you want that action?
16:28:09 <dhellmann> not yet. if we decide to charge for them I will add documentation before or with the code
16:28:18 <dhellmann> I don't want to commit to implementing it if no one else needs it
16:28:19 <nijaba> dhellmann: sounds good
16:28:32 <nijaba> dhellmann: we may want to document one though
16:28:41 <dhellmann> ok, I'll add an example
16:28:41 <nijaba> dhellmann: so that we don't forget about the case
16:28:46 <dhellmann> right
16:29:02 <nijaba> #action dhellmann to document a counter for discrete event as an example
16:29:31 <nijaba> any other open dicussion topics?
16:30:09 <nijaba> calling once...
16:30:28 <nijaba> twice...
16:31:02 <nijaba> ok, thanks a lot everyone...  I guess the holliday did not help to get a lot of people on this meeting today
16:31:15 <nijaba> #endmeeting