15:00:24 <eglynn> #startmeeting ceilometer
15:00:24 <openstack> Meeting started Thu Apr  2 15:00:24 2015 UTC and is due to finish in 60 minutes.  The chair is eglynn. 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:29 <openstack> The meeting name has been set to 'ceilometer'
15:00:30 <sileht> o/
15:00:30 <cdent> o/
15:00:34 <ityaptin> o/
15:00:37 <prad> o/
15:00:43 <gentux> o/
15:00:54 <ildikov_> o/
15:00:55 <idegtiarov> o/
15:01:00 <gordc> o/
15:01:06 <eglynn> hey y'all!
15:01:33 <_nadya_> o/
15:01:34 <eglynn> #topic kilo-rc1
15:01:53 <eglynn> #link https://launchpad.net/ceilometer/+milestone/kilo-rc1
15:02:12 <eglynn> this interesting one is the only outstanding patch for now
15:02:13 <eglynn> https://bugs.launchpad.net/ceilometer/+bug/1435855
15:02:15 <openstack> Launchpad bug 1435855 in Ceilometer "Default rule does not work in ceilometer policy.json" [High,In progress] - Assigned to Divya K Konoor (dikonoor)
15:02:26 <llu-laptop> o/
15:03:01 <eglynn> we discussed the patch with edmondsw on IRC and the ML
15:03:12 <eglynn> I'm pretty happy with the outcome
15:03:34 <cdent> It did seem to reach a reasonable conclusion
15:03:41 <eglynn> it combines the intent of fabiog's RBAC approach with the ability to parse default rules
15:03:45 <eglynn> yeap
15:03:55 <eglynn> so I think we can definitely land this
15:04:17 <ildikov_> this short summary sounds reasonable to me too
15:04:33 <gordc> quick glance seems ok.
15:04:43 <eglynn> we need to triage the bug queue also in case there are any lurking blockers
15:04:51 <eglynn> release bloeckers that is
15:05:00 <eglynn> I was hoping to find time for that this week
15:05:28 <ildikov_> we have a looong Easter weekend coming ;)
15:05:29 <eglynn> but very swamped, so would appreciate it if anyone else can help out with the triage
15:05:36 <eglynn> a-ha, yeah
15:05:55 <eglynn> so there's no pressure to cut kilo-rc1 until the week of April 9th
15:06:15 <ildikov_> sorry, bad joke, I will try to look at it too
15:06:37 * gordc hasn't seen any huge bugs yet.
15:06:51 <eglynn> coolness, thanks folks!
15:07:15 <eglynn> the other spanner in the works was the python-ceiloclient versioning issue for heat
15:07:40 <eglynn> #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/060439.html
15:08:06 * eglynn hangs head in shame for breaking SEMVER on the 1.0.13 tag
15:08:46 <eglynn> anything else on RC1?
15:09:16 <eglynn> #topic gnocchi status
15:09:33 <eglynn> jd__: what's happening in your pasta kitchen?
15:10:30 <sileht> eglynn, I think jd__ is not around today
15:10:37 <eglynn> sileht: a-ha cool
15:10:50 <eglynn> so here's the recent activity ...
15:10:51 <eglynn> https://review.openstack.org/#/q/status:merged+project:openstack/gnocchi,n,z
15:11:20 <eglynn> cdent, sileht: anything notable either merged or in the review queue?
15:11:39 <sileht> we move to openstack namespace
15:11:55 <cdent> there's a change in progress where whole objects instead of ids are being passed around to avoid multiple calls to fill the object
15:12:00 <cdent> that ought to merge later today
15:12:13 <eglynn> a-ha, cool on both counts :)
15:12:40 <sileht> history of resource attributes is still in progress
15:13:17 <eglynn> sileht: that's a really interesting one
15:13:40 <eglynn> is there any particular area that stands out as needing attention?
15:14:30 <prad> sileht, cdent, if there are any areas you guys need help in gnocchi, lemme know. I can squeeze it on my plate i think
15:14:43 <_nadya_> idegtiarov has started mongo indexer testing afaik
15:15:02 <eglynn> it would be good to have maybe a running list of on-ramp tasks for folks who are interesting in getting involved
15:15:21 <eglynn> i.e. acheivable tasks that have good learnign potential
15:15:48 <cdent> I've found "write some gabbi tests" to be a good one for that (in both gnocchi and ceilo)
15:15:58 <eglynn> cdent: good point
15:16:24 <eglynn> certainly in terms of learning the shape of the API, seems like an excellent starting point
15:16:49 <idegtiarov> _nadya_, thanks indeed i've filed a bp and started work on tha patch
15:16:52 <cdent> it usually sends you off other places too to figure out why something isn't like you expect
15:16:54 <prad> cdent, will sync up with ya on that.. happy to write some gabbi goodness if it helps
15:17:06 <eglynn> coolness
15:17:07 <cdent> cool prad
15:17:08 <ildikov_> I like the idea too, the APIs could use some attention
15:18:47 <eglynn> anything else on gnocchi?
15:20:24 <eglynn> #topic meter deprecation
15:20:33 <eglynn> ildikov_: the floor is your's
15:20:42 <ildikov_> eglynn: thanks
15:21:05 <ildikov_> so there was a modification in the IPMI meters and one was renamed
15:21:26 <ildikov_> I realized it when I reviewed an OS Manuals patch
15:21:54 <ildikov_> in my opinion it is not too user friendly to change the name of a meter from one release to the other
15:22:08 <eglynn> yeah I've never been very comfortble with such name changes
15:22:13 <eglynn> ... after a major release
15:22:14 <ildikov_> the same for deleting instance:<favor>, which I know is unnecessary
15:22:50 <ildikov_> ... but still, if someone uses it, it will not be that straight forward to figure out why it is not available anymore
15:22:58 <eglynn> so how about we simply approach this like an API major version deprecation?
15:23:12 <ildikov_> so I thought to raise this "backward compatibility" topic
15:23:46 <ildikov_> how long that is?
15:23:47 <eglynn> i.e. giving a certain period of notice that a meter is on the deprecation path
15:23:51 <eglynn> 1 cycle?
15:24:14 <gordc> ildikov_: this sort of connects with the ironic patch that allows them to define meters.
15:24:18 <ildikov_> we said for the event-type meters that we would deprecate them for Liberty and then get rid of them as they are already in the event db
15:24:21 <gordc> re: name changing
15:24:38 <ildikov_> gordc: yeap, that one is even worse from this point of view
15:24:50 <eglynn> gordc: got a link?
15:25:07 * cdent gets out his broken record:
15:25:17 <cdent> long term we will have to allow people to define their own meters
15:25:20 <gordc> https://review.openstack.org/#/c/130359/
15:25:22 <ildikov_> eglynn: 1 cycle sounds good to me, this is what we discussed earlier
15:25:42 <ildikov_> cdent: I think it is a different case
15:26:07 <cdent> Changing existing ones is a problem, I agree ildikov_
15:26:08 <ildikov_> cdent: this one will give a set of meter to users IIRC, which is named on the Ironic side
15:26:11 <llu-laptop> eglynn: in that deprecation cycle, should we record both 2 meters with old/new name?
15:26:13 <gordc> is there a way to treat our meter names similar to 'display_names'? ie. another unique identifier we can query on?
15:26:33 <ildikov_> cdent: and it is an issue that we acnnot tell, what we offer
15:26:53 <ildikov_> cdent: letting the user defining meters is another thing, as in that case they know what they have
15:27:45 <prad> one cycle seems reasonable heads up time. But we did run into this for network service meter names as well, thouhg that luckily was within the same cycle
15:27:47 <ildikov_> gordc: unless it is a UUID it will prolly have the same issue
15:28:09 <gordc> llu-laptop: regarding the removal of instance:<flavour> meter, we could technically add a workaround that can auto build the correct query if you type it in?
15:28:24 <ildikov_> so let's get back to the deprecation first, as now we have a renamed and a removed meter what I know about
15:28:31 <prad> so seems like a more than a less common use case to change meter names.. perhaps a reason to think for a better approach in the long run
15:28:55 <ildikov_> and if we say that it should be deprecated for a cycle, then we need to deal with this now, to add them back
15:29:26 <eglynn> llu-laptop: recording both would double the storage footprint, or?
15:29:41 <ildikov_> llu-laptop: I guess we can have some kind of a mapping as for project/project_id maybe?
15:30:01 <gordc> eglynn: yeah. it's literally the exact same record. just with a tagged meter name.
15:30:24 <eglynn> gordc: yeah, that would seem pretty wasteful
15:30:30 <ildikov_> gordc: I'm fine with the workaround too, TBH, unless others don't have anything against
15:30:35 <_nadya_> why do we want remove metrics?
15:30:44 <eglynn> ... given the storage bloat already with the snapshotted resource metadata
15:30:51 <eglynn> _nadya_: s/remove/rename/
15:31:17 <ildikov_> _nadya_: one example is gordc's patch as instance:<favor> can be retrieved now by using group-by
15:31:20 <gordc> _nadya_: it's not really removing meters, in case of instance:<flavour>. it's more removing a workaround which isn't needed anymore.
15:31:42 <ildikov_> _nadya_: the other part is the "event-type" meters, which have a constant 1 volume
15:31:50 <_nadya_> aha, got it
15:32:23 <eglynn> _nadya_: so two spearate concerns ... remove unecessary ones, rename misnamed ones
15:32:32 <ildikov_> should these workarounds be RC1 candidates?
15:32:53 <ityaptin> ildikov_, are we want to use events instead of "event_type" meters?
15:33:16 <eglynn> ildikov_: which workarounds now?
15:33:35 <gordc> ildikov_: i think so. the problem with workaround (re: instance:<flavour>), it might cause a gap in meter-list?
15:33:54 <eglynn> ildikov_: if we want to start the deprecation timing ticking, we'll need to get the change into kilo
15:34:14 <gordc> ityaptin: i think the suggestion is to use events... but they "event" meters are still available in kilo (but deprecated)
15:34:24 <ildikov_> ityaptin: yes, gordc made it possible to turn off to store them now and store only events, we plan to use this approach as default in Liberty and then remove
15:34:55 <ildikov_> ok, I will report a bug for this issue then first
15:35:03 <gordc> ildikov_: sounds good.
15:35:09 <ildikov_> and then let's figure out the tagging and workaround
15:35:31 <ildikov_> or well, continue it here we have plenty of time :)
15:36:13 <llu-laptop> ildikov_: gordc: in that case of events, I think there are use cases for event statistics and event based alarm
15:36:19 <llu-laptop> which we dont' have now
15:36:47 <eglynn> ildikov_: so if we want to target these changes at RC1, bare in mind the timeline
15:36:49 <eglynn> (i.e. kilo-rc1 to be tagged in w/c April 9th)
15:37:01 <eglynn> (i.e. time is relatively short)
15:37:06 <gordc> llu-laptop: right. i think it's something i wanted to do for kilo but didn't have time. but it'd be good to do in L*
15:37:10 <ityaptin> ildikov_, gordc: thanks! Whats you think about updating the api for collecting and querying the events by periods, as statistics now?
15:37:27 <ildikov_> llu-laptop: we could have this as a kind of priority item for Liberty
15:37:43 <ildikov_> llu-laptop: I agree that it is necessary to cover before removing the meters
15:37:48 <ityaptin> ildikov, Ok, I see your message)
15:38:23 <ildikov_> eglynn: yeap, I have the deadline, if we can agree on a solution then I will be on to solve it
15:39:41 <eglynn> ildikov_: what remains to be agreed, and what would be the best way of converging on that agreement quickly?
15:39:53 <eglynn> e.g. just get a strawman patch proposed?
15:40:40 <ildikov_> well gordc raised the meter-list issue in case of instance:<favour> workaround
15:41:28 <ildikov_> I guess we are on the side of tagging the renamed meters somehow, but correct me if I'm wrong here
15:41:55 <gordc> ildikov_: i can play with it... i'm pretty sure it'll be super hacky to get 100% parity though.
15:42:19 <ildikov_> goodes: you mean the whole issue or the instance... one?
15:42:34 <gordc> i take it a doc that says 'use this query' isn't enough.
15:42:40 <ildikov_> goodes: sorry, I was too quick with the tab...
15:42:45 <eglynn> so just to be clear, the workaround propsoed is to report the instance:<flavour> from an internal query over the bare instance meter?
15:42:51 * gordc shakes fist at backward-compat
15:43:05 <gordc> eglynn: right.
15:43:20 <ildikov_> gordc: I think the doc will be the very last thing a user will check as no one expects that it got deleted
15:43:56 <gordc> ildikov_: eglynn: so i guess the fail proof/easy solution is to just revert it and bring it back.
15:44:07 <ildikov_> gordc: and we already have a lack of good user feedbacks and we need to handle the deprecation later anyhow IMHO
15:44:50 <eglynn> yeah, if the workaround looks too tricky to land for RC1, reverting would be sensible
15:44:53 <ildikov_> gordc: sorry about this, I really didn't want to hurt with raising this issue :(
15:45:09 <gordc> ildikov_: i blame you 100% :P
15:45:16 <eglynn> ... but if reverting also explicitly deprecating in the kilo release notes
15:45:19 <gordc> eglynn: yeah revert is easiest.
15:45:20 <ildikov_> ok, then let's revert that one first and then figure out if we can handle it
15:45:29 <eglynn> ... so that the deprecation timer starts now
15:45:35 <eglynn> OK
15:46:02 <ildikov_> gordc: I can take it, no worries, I like hiccups ;)
15:46:17 <eglynn> #agreed revert remove and explciitly deprecate instance:<flava> from kilo onwards
15:46:24 <gordc> ildikov_: cool cool.
15:46:34 <ildikov_> eglynn: yeap, now is better
15:46:48 <ildikov_> as for the IPMI one, let's tag it?
15:47:05 <eglynn> tag?
15:47:38 <ildikov_> to handle the old/new names without store it twice
15:48:04 <eglynn> a-ha, k
15:48:07 <eglynn> cool, go tit
15:48:13 <eglynn> *got it
15:48:33 <ildikov_> eglynn: sorry, so I meant the rename case
15:48:50 <eglynn> ildikov_: yeap, got it, thanks
15:49:33 <eglynn> #topic open discussion
15:50:13 <ildikov_> eglynn: does this mean something like a tag would be ok? :)
15:51:05 <eglynn> ildikov_: if a tag means that the user can pretend that the rename didn't happen, yeap
15:51:44 <llu-laptop> eglynn: where can we put the design summit topic candidates?
15:52:21 <ildikov_> eglynn: that should exist only in the code as opposed to be a user facing thing
15:52:46 <eglynn> llu-laptop: we should create a google doc sheet to do
15:52:56 <eglynn> #action eglynn create googledoc
15:53:10 <eglynn> ildikov_: yeap agreed!
15:53:16 <eglynn> in case y'all haven't heard, prad has (re-)joined us in Red Hat :)
15:53:25 <eglynn> ... we were only lending him to Cisco :)
15:53:33 <prad> :)
15:53:35 <_nadya_> eglynn: about your letter:) I wish you all the best with your "new role"!
15:53:46 <eglynn> _nadya_: thank you! :)
15:53:48 <gordc> thanks for being ptl for past year eglynn!
15:53:57 <eglynn> gordc: thank you sir!
15:54:07 * eglynn has lump in throat
15:54:15 <eglynn> right-o, folks I gotta run for a call
15:54:26 <eglynn> story of my life :(
15:54:26 <ildikov_> eglynn: tears in my eyes! I wish you all the best!
15:54:40 <eglynn> let's call it a wrap, thanks all for your time!
15:54:40 <ityaptin> eglynn: Thanks very much! It was cool to work with you!
15:54:46 <eglynn> :)
15:54:52 <eglynn> #endmeeting ceilometer