15:00:34 <gordc> #startmeeting ceilometer
15:00:34 <openstack> Meeting started Thu Jul 16 15:00:34 2015 UTC and is due to finish in 60 minutes.  The chair is gordc. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:37 <openstack> The meeting name has been set to 'ceilometer'
15:00:44 <cdent> o/
15:00:44 <sileht> o/
15:00:49 <ildikov> o/
15:01:05 <eglynn> o/
15:01:18 <lakshmiS> o/
15:01:46 <gordc> i'll give it a minute.
15:02:02 <gordc> i think we have a few people out on holiday/meeting today
15:02:39 <fabiog> hi
15:03:04 <efried> Howdy y'all.
15:03:11 <gordc> cool. let's call this quorum.
15:03:30 <gordc> so start off. thanks for all those who attended last week's midcycle.
15:03:53 <gordc> not ideal timing for americas but considering our developer base, it is what it is.
15:04:02 <gordc> thanks to cdent and prad for organising
15:04:24 * cdent plays a little violin for poor gordc
15:04:26 <ildikov> yeap thanks!
15:04:27 <eglynn> yep, cdent++ prad++
15:05:10 <gordc> we'll revisit the topic later but if you have input/feedback, feel free to bring it up during open discussion (or email me if you want it to remain private because you dont want to air dirty laundry)
15:05:41 <gordc> first topic is a result of midcycle
15:05:46 <gordc> #topic recurring: roadmap items (new/old/blockers) https://wiki.openstack.org/wiki/Ceilometer/RoadMap
15:05:59 <gordc> we now have a 'formal' roadmap
15:06:27 <cdent> nice
15:06:42 <gordc> basically it lists all open priority items, some open items that could be targetted to current or next cycle
15:07:02 <gordc> and some longer term goals which have been tossed around (by devs/users)
15:07:04 <ildikov> huge +1 for having this
15:07:11 <eglynn> on the gnocchi roadmap, do we need a "what to do about v2 API coexistence" item?
15:07:27 <gordc> the longer term goals have no been discussed and will need to go through review process
15:07:54 <ildikov> eglynn: is that a Gnocchi roadmap?
15:08:03 <gordc> eglynn: yes we can add that. we discussed v3 api at the midcycle
15:08:13 <ildikov> eglynn: or can we consider momre as v2 deprecation roadmap?
15:08:21 <eglynn> ildikov: sorry, I mean the gnocchi list on the general roadmap
15:08:40 <gordc> but we didn't have a conclusive decision on whether we needed it just yet as it is only gnocchi that represents the change in representation
15:08:43 <ildikov> eglynn: a-ha, ok
15:09:31 <gordc> we decided it's something to start thinking about... but right now gnocchi api will remain separate.
15:09:53 <eglynn> gordc: one simple approach might be to disable the meters/samples/statistics endpoint in v2 API if gnochi dispatcher is enabled
15:10:33 <eglynn> ... i.e. return a fault saying "don't use me, use the gnochhi-api instead to retrieve metric data"
15:10:35 <ildikov> yeap, but we need proper docco for that as it is quite big API change...
15:11:42 <gordc> eglynn: that sounds like a easy solution... if the conf file passed to api is pointing to gnocchi as dispatcher?
15:12:20 <cdent> that makes sense gordc
15:12:28 <gordc> eglynn: i don't think the api currently is aware if gnocchi is enabled... all the normal setup is done. it would need to look at dispatcher value i think (which it doesn't currently)
15:12:33 <cdent> it is safer than just checking for gnocchi's endpoint (as that's not conclusive)
15:12:33 <eglynn> gordc, cdent: yep, or even have a separate config option to enable that stricter behavior
15:12:44 <eglynn> yep
15:13:09 <ildikov> I think checking the dispatcher value is more bullet proof
15:13:53 <gordc> just wondering if there's issues if there are multiple collectors... with different dispatchers
15:14:29 <gordc> so there's use case to publish datapoint to different targets so it's handled differently... osmething to look into.
15:14:39 <fabiog> alternatively you could have two separate pipelines in wsgi
15:14:51 <fabiog> like pipeline = request_id authtoken api-v2-server
15:14:59 <fabiog> vs. pipeline = request_id authtoken api-v3-server
15:15:14 <fabiog> so you decide what API to enable
15:15:52 <eglynn> multiple dispatchers I guess could be handled via a separate config option to turn on the stricter behavior
15:16:45 <gordc> fabiog: yeah that's true. can it point to an external api? if api-v3-server was gnocchi?
15:17:29 <fabiog> gordc: I think so, you will need a stub in the Ceilo code but then you can import the Gnocchi API in there
15:17:43 <fabiog> gordc: or make calls
15:18:11 <gordc> fabiog: kk. something to look into
15:18:38 <gordc> we should probably target this for liberty if we intend on promoting gnocchi as our usable 'default' driver.
15:19:15 <eglynn> gordc: strong +1 on that targeting
15:19:25 <ildikov> gordc: +1
15:19:37 <gordc> #action add workitem to either disable metering apis when gnocchi is enabled or create wsgi pipeline
15:20:22 <gordc> so i think one thing we haven't figured out was how to manage the road map... anyone can add stuff so how do we ensure people are aware of updates.
15:20:51 <cdent> gordc: people can subscribe to email notifications for updates on that page, if they want
15:21:26 <gordc> cdent: ah cool. i think i just didn't subscribe.
15:21:37 <ildikov> gordc: another item could be the aodh client question regarding targets there
15:21:50 <gordc> non-issue then
15:22:31 <gordc> ildikov: right. liusheng offered to start working on the aodh+ceilometer integration work
15:23:01 <sileht> devstakc plugin is ready: https://review.openstack.org/#/c/200467/
15:23:07 <ildikov> gordc: cool
15:23:15 <gordc> i believe the opinion from ceilometer users (ie. heat) is that we keep the functionality in ceilometerclient
15:23:46 <gordc> which is probably best from usability pov.
15:24:06 <gordc> i didn't get a chance to see what work is actually required to do that.
15:24:36 <gordc> or if it's possible... cdent mentioned it could be an endpoint change to aodh and fall back to ceilometer if not?
15:25:20 <gordc> but i think for aodhclient specifically. that might be something for next cycle? unless we can't integrate it in to ceilometerclient for some reason.
15:26:21 <gordc> i really don't have a break down what work items are required to be honest so anyone with better view can comment.
15:27:47 <gordc> i'll check with liusheng to see what he discovers when he starts working on it i guess.
15:27:57 <cdent> sounds like a good plan
15:28:04 <cdent> we try to predict we'll just be wrong
15:28:54 <gordc> cool cool. any other items regarding roadmap? feel free to reassign priority if you think somehting should be bumped up (and there's a resource we can attach to it)
15:30:50 <gordc> #topic recurring: ceilometerclient release?
15:31:11 <gordc> i'm tracking nothing. if someone needs a new client shout now
15:31:47 <gordc> i should mention the release would probably be next week since release team isn't fond of thurs/fri releases
15:31:58 <gordc> #topic recurring: Gnocchi status
15:32:13 <cdent> awesome devstack+gnocchi pile on this week
15:32:16 <cdent> lots of issues discovered
15:32:20 <cdent> some fixed
15:32:22 <cdent> still some to go
15:32:26 <cdent> it's almost but not quite fun
15:32:31 <gordc> lol
15:32:56 <cdent> the latest concerning thing is a bug in carbonara: https://bugs.launchpad.net/gnocchi/+bug/1475329
15:32:56 <openstack> Launchpad bug 1475329 in Gnocchi "Exception in gnocchi-metricd: ValueError: cannot reindex from a duplicate axis" [Undecided,New]
15:33:03 <gordc> i told product to start looking at it. i'll check next week to see if they've disocvered anything
15:33:14 <cdent> which came up after running with the file backend for a short while
15:33:30 <gordc> that looks scary. i don't think i saw that.
15:33:38 <sileht> I have proposed to move the samples2resources/metrics convertion to yaml like event and notification: https://review.openstack.org/#/c/202500/
15:33:40 <cdent> there have been a lot of changes to the devstack plugin in the last 24 hours so if anyone is testing with devstack, probably worth updating regularly
15:33:58 <cdent> 202500 is awesome
15:34:33 <gordc> sileht: agreed. the hardcoded resources were really really bothering me
15:34:42 <sileht> And I have reduced to only 1 resource patch per message received too: https://review.openstack.org/#/c/202589/
15:35:07 <sileht> next perf improvement in the ceilometer-notifier to batch samples into one messages
15:35:16 <gordc> sileht: awesome news. good to see we're targeting performance rather than features.
15:35:33 <cdent> death to features!
15:35:40 <gordc> are we done with features in gnocchi? aside from influxdb driver
15:35:43 <sileht> I want to see everything work in gate !
15:35:45 <eglynn> sileht: batching, coolness :)
15:36:25 <gordc> i think we should freeze features in gnocchi. assuming there isn't a massive gap somewhere.
15:36:28 <sileht> I'm not sure batching is the priority, perhaps I will take that when more gate/functionnal testing have been done
15:36:58 <gordc> sileht: yeah gating probably takes priority... then performance
15:37:23 <eglynn> +1 to that
15:38:48 <gordc> i'll sync with jd__ to confirm there's no massive gaps in gnocchi and if not we can do feature freeze.
15:38:52 <gordc> for gnocchi.
15:40:11 <gordc> for reviewers, we should probably start focusing on the same. i think the only non-performance related feature we have outstanding is alarm work but that's in aodh.
15:40:35 <gordc> any other comments on gnocchi?
15:41:15 <gordc> #topic Open discussion
15:41:39 <gordc> does anyone have oslo.messaging 1.16.x + devstack installed?
15:42:24 <gordc> just for reference, https://bugs.launchpad.net/ceilometer/+bug/1475307
15:42:24 <openstack> Launchpad bug 1475307 in Ceilometer "collector has possible memory leak" [Critical,New]
15:42:28 <lakshmiS> Have a question for ceilometer team. I am core commiter on Openstack searchlight project and we consume notifications from glance but when ceilometer is running, searchlight listener doesn't recieve those notifications.
15:42:41 <lakshmiS> We have to stop ceilometer for searchlight to receive new notifications. Searchlight project has a patchset to include a pool name: https://review.openstack.org/#/c/202392/
15:42:46 <lakshmiS> Can ceilometer do similarly or any other suggestions?
15:42:58 <eglynn> lakshmiS: you need to configure glance to emit on two topics IIRC
15:43:05 <gordc> lakshmiS: ^
15:43:10 <cdent> eglynn: that seems unfair
15:43:22 <eglynn> cdent: life is unfair :)
15:43:26 <lakshmiS> can we not use different pool names: atleast that's what the oslo messaging document says
15:43:28 <cdent> you're basically putting a dependency on a source for their to be multiple listeners
15:43:34 <cdent> s/their/there/
15:43:53 <cdent> whereas what we'd like in a distributed system is for there to be N potential listeners without needing to change the source
15:43:55 <gordc> lakshmiS: there was an issue with that oslo.messaging
15:43:58 * cdent looks at sileht
15:44:10 <lakshmiS> cdent: +1
15:44:12 <sileht> that should just work
15:44:16 <eglynn> cdent: yeap, it's certainly not pretty, I just think that's the current reality
15:44:25 * cdent does not aspire to reality ;)
15:44:34 <eglynn> sileht: a-ha, k ... good to know
15:44:44 <lakshmiS> I tried changing ceilometer listener code to have a pool name but it stops working afer a while
15:44:56 <lakshmiS> is there anyone from ceilometer team I can discuss this offline?
15:44:58 <gordc> sileht: wasn't there an issue with pools, something about it not being created at right time so we'd lose messages?
15:45:33 <sileht> kmartin,you need to take a look to your rabbitmq queues and find those prefixed with searchlight-listener
15:45:39 <gordc> lakshmiS: we're all over at #openstack-ceilometer (more euro based) but there's a few of us (me) in americas tz
15:46:28 <sileht> gordc, yes but you just lost message between the client side restart and the first server side start, that doesn't occurs offen
15:46:31 <lakshmiS> gordc: sileht: can you point me to the issue you had previously with oslo.messaging pools?
15:46:54 <sileht> lakshmiS, it not a issue, this is a historical behavior :p
15:46:59 <lakshmiS> ok
15:47:10 <sileht> unsure it's cleanly documented
15:47:27 <lakshmiS> so the solution/alternative is to have multiple topics for notification.info from glance?
15:47:36 <gordc> lakshmiS: post your issue over at #openstack-ceilometer and someone will reply. if not, we're sleeping and ML is good.
15:47:59 <lakshmiS> gordc: i wil do ML since I already did on IRC with no response
15:48:06 <gordc> lakshmiS: that is the alternative yes... that's typically what is done. (ie. stacktach)
15:48:16 <lakshmiS> gordc: thx
15:49:58 <gordc> sileht: for the above, do ceilometer  and searchlight need to create pool or just one? the problem right is we're both using hte same default pool right?
15:50:32 <sileht> gordc, I think the safer ways is to emit the notification twice on the other side
15:50:55 <lakshmiS> sileht: that would be a change on each team(glance, nova) etc right?
15:51:08 <sileht> lakshmiS, yes a configuration change
15:51:23 <sileht> gordc, this method ensure that no notifications will be missed
15:51:39 <gordc> sileht: got it. that's what i understood.
15:51:54 <lakshmiS> sileht: do you have any previous reviews doint this cofig change ?
15:52:00 <lakshmiS> s/doint/doing
15:52:10 <gordc> lakshmiS: its either or i guess. pro/con either way.
15:52:26 <gordc> lakshmiS: let me dig up stacktach docs, they might reference it
15:52:34 <lakshmiS> thanks gordc:
15:53:30 <gordc> anything other topics?
15:53:52 <gordc> lakshmiS: i'll send you link over in openstack-ceilometer unless you have another preference
15:54:34 <gordc> 30s countdown
15:55:11 <lakshmiS> gordc: please send it to lakshmi.sampath@hp.com if possbile too
15:55:16 <gordc> lakshmiS: kk
15:55:25 <gordc> ending meeting. thanks folks
15:55:28 <gordc> #endmeeting