15:00:38 <gordc> #startmeeting telemetry
15:00:38 <openstack> Meeting started Thu Jan 28 15:00:38 2016 UTC and is due to finish in 60 minutes.  The chair is gordc. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:42 <openstack> The meeting name has been set to 'telemetry'
15:00:56 <jd__> o/
15:01:18 <idegtiarov> o/
15:01:35 <gordc> ... very quick meeting?
15:01:56 <llu-laptop> o/
15:01:59 <pradk> o/
15:02:23 <gordc> let's blame through this
15:02:24 <_nadya_> o/
15:02:27 <ildikov> o/
15:02:37 <sileht> o/
15:02:41 <gordc> #topic roadmap items (new/old/blockers) https://wiki.openstack.org/wiki/Telemetry/RoadMap
15:02:42 <ityaptin> o/
15:02:53 <gordc> ok. so we are in final stretch
15:03:11 <gordc> i have list of Roadmap items listed... if someone still has open time
15:03:20 <gordc> but i have nothing really to add. any blockers?
15:04:11 <gordc> cool. nothing
15:04:18 <gordc> #topic aodh topics
15:04:23 <gordc> anything for aodh?
15:04:41 <_nadya_> yep! I have a question about mandatory limits
15:04:48 <gordc> _nadya_: kk
15:05:20 <_nadya_> so, I don't think we need it in aodh. Also, it affects QAs and customers very much
15:05:27 <gordc> #topic aodh mandatory limits
15:06:22 <_nadya_> the main purpose of mandatory limits in Ceilo was not to show too many resources and not create a load on dbs
15:06:25 <gordc> _nadya_: qa because they need to update default return setting?
15:06:58 <gordc> _nadya_: so i'm pretty indifferent to mandatory limits... are we against adding limit completely though?
15:07:24 <_nadya_> gordc: yes. so you have a test with expectation that 10001 resource should be returned, but it starts return only 10000
15:07:24 <llu-laptop> So the question is that how many alarms typically would return in a query for production?
15:07:38 <liusheng> o/
15:07:51 <gordc> _nadya_: well we can  have a limit but make it optional?
15:08:03 <gordc> liusheng: do you know how many alarms we have?
15:08:16 <gordc> i guess per resource it becomes a lot?
15:08:21 <_nadya_> gordc: yep, I don't mind to have -l option, but not mandatory
15:08:53 <ildikov> I think it's better to keep the option, but I agree to skip the mandatory part
15:09:03 <jd__> there's a standard in OpenStack, let's use it
15:09:04 <liusheng> gordc: don't have a exact num
15:09:17 <gordc> jd__: what's the standard?
15:09:31 <gordc> jd__: this seems like taht pagination craziness again.
15:09:38 <jd__> the one we use in Gnocchi AFAIK, that is backed by oslo.db features
15:09:40 <llu-laptop> jd__: the standard for limit is optional or mandtary?
15:10:03 <liusheng> gordc: but seems about several thousands
15:10:16 <jd__> gordc: that's that, but it's standardized AFAIK now – at least for sql
15:10:41 <gordc> jd__: is pagination in oslo.db?
15:10:56 <jd__> yes AFAIK
15:10:58 <jd__> sileht knows
15:11:08 <gordc> the problem is we aren't killing mongo/hbase for aodh just yet
15:11:43 <gordc> so... maybe we should officially mark them deprecated
15:11:57 <jd__> yes, we merged a spec for that
15:11:59 <gordc> and then start applying all the oslo.db pagination easy stuff afterwards.
15:12:02 <jd__> and just not implement the feature there
15:12:35 <ildikov> gordc: I will add docco if we deprecate Mongo and HBase now
15:13:08 <gordc> jd__: i'm ok with adopting oslo.db pagination. we just need to formally say: 'mongo/hbase aodh is what it is'
15:13:17 <gordc> and maybe have a v2.1 api or something
15:13:27 <jd__> no need AFAIK since it's just addition
15:13:47 <gordc> something to consider.
15:14:08 <gordc> so we all ok with prioritising deprecation spec
15:14:24 <_nadya_> I'm not sure I wanted this....
15:14:28 <gordc> and we can apply oslo.db rules for api limits in aodh?
15:14:39 <gordc> _nadya_: the deprecation?
15:15:00 <_nadya_> gordc: yep :) So we will have only one db option for Aodh?
15:15:14 <gordc> _nadya_: yes.
15:15:28 <gordc> let's be honest here, our resources are stretch too thin as is.
15:15:45 <_nadya_> gordc: agreed
15:15:49 <gordc> unless someone yells "i'm using mongo/hbase and i will work on it"
15:15:52 <liusheng> gordc: the pagination in oslo.db can surppot limit, marker, sort, don't have a default limit confg option
15:15:55 <gordc> i don't see how we can maintain it.
15:16:27 <gordc> liusheng: so it could solve our concerns still?
15:17:02 <gordc> _nadya_: i think i consider it like zmq or qpid in oslo.db.
15:17:07 <sileht> gordc, you just have to set it like this: https://github.com/openstack/gnocchi/blob/master/gnocchi/indexer/sqlalchemy.py#L526
15:17:10 <_nadya_> gordc: people usually use the same backend for alarming as for metering. but probably, it is not a blocker. It just a tradition
15:17:13 <gordc> it's there. but no one gives a damn about it so probably don't use it.
15:17:34 <gordc> or at least for qpid
15:17:48 <gordc> sileht: ah cool.
15:17:49 <gordc> nice.
15:18:20 <gordc> sileht: qpid still exists right? in oslo.messaging?
15:18:27 <gordc> it just not tested or worked on?
15:18:35 <sileht> gordc, no it have been removed
15:18:38 <ildikov> _nadya_: I assume it's the easiest to handle, but it's prolly not a blocker
15:18:39 <gordc> oh.lol
15:18:48 <sileht> the 1 cycle deprecation have been done
15:18:54 <_nadya_> ildikov: yep, tend to agree
15:18:57 <gordc> yeah. so i guess we do the same.
15:19:09 <gordc> we deprecate and if no one steps up. it's gone?
15:19:24 <gordc> for me i'd rather have one working rather than 3 broken options.
15:19:53 <ildikov> _nadya_: although if we go into this direction I assume we will hear complainings from ops if it wasn't a that good idea
15:20:38 <gordc> ildikov: yep. and then they can go to their boss and let them know backend support don't grow on trees
15:20:46 <gordc> and then we get more resources :)
15:20:48 <jd__> gordc++
15:20:49 <llu-laptop> if we want to deprecate mongodb/hbase, maybe we should write an tool to help migrate them into sql?
15:21:03 <jd__> llu-laptop: no, same answer than gordc just gave
15:21:15 <ildikov> gordc: lol :) agreed
15:21:32 <ildikov> gordc: also the code is still up on github it can be picked up later...
15:21:44 <gordc> llu-laptop: yeah. if there's a request... we're not at point where we can give false hope. :)
15:21:52 <_nadya_> jd__: why not? It should be pretty easy
15:22:06 <gordc> ildikov: ++
15:22:06 <_nadya_> false hope, ok
15:22:15 <liusheng> llu-laptop: I have tried that, but I am in busy for other things these days :(
15:22:16 <gordc> _nadya_: yeah, all about resources.
15:22:19 <jd__> _nadya_: sure, you'll do it?
15:22:40 <gordc> _nadya_: we can backlog it.
15:22:50 <_nadya_> jd__: ok, I understood :) Anyway, I think I will
15:23:08 <gordc> i should create a section that says: 'pay someone, tell them to do this, and it will happen'
15:23:10 <jd__> _nadya_: taking your word for it :)
15:23:39 <gordc> although, that's basically the enitre backlog
15:23:48 <_nadya_> jd__: my name can be translated in english as "hope" :)
15:23:57 <gordc> :) we all good?
15:23:59 <llu-laptop> gordc: yeah, let's backlog that and encourage new comer to work on that.
15:24:19 <gordc> #action backlog mongo/hbase to sql tool
15:24:39 <gordc> #action prioritise db deprecation
15:24:53 <gordc> #action adopt oslo.db for pagination/limits
15:24:57 <jd__> _nadya_: good to know lol
15:25:13 <gordc> cool. anything else?
15:25:33 <jd__> llu-laptop: all those shitty tasks in the backlog that nobody wants to work on, you call that encouragement. remind me to never work for you ;)
15:26:56 <gordc> jd__: intel has a lot of money... you may eat your words
15:27:06 <gordc> #topic ceilometer topics
15:27:59 <gordc> i'm going to assume nothign for this?
15:28:01 <_nadya_> can I merge this nova polling improvements https://review.openstack.org/#/c/209799/9?
15:28:13 <jd__> gordc: don't confuse the man and the company :)
15:29:58 <gordc> _nadya_: sorry, was readnig liushengs comment
15:30:01 <gordc> i'm ok merging.
15:31:12 <gordc> _nadya_: i'm going to edit to make liushengs comment address my comment but i'll push merge or fix later
15:31:29 <gordc> _nadya_: feel free to merge now if you like
15:31:36 <_nadya_> gordc: ok!
15:31:39 <gordc> #topic gnocchi topics
15:32:05 <jd__> I just released 1.3.4 with a bunch of interesting fixes
15:32:05 <gordc> jd__: anything? or just check openstack-telemetry logs to see all the comments?
15:32:33 <gordc> jd__: we haven't released the split timeserie patch yet right?
15:32:38 <jd__> now I'm planning on 2.0 in the next weeks, once dust settles
15:32:43 <jd__> gordc: no that'd be in 2.0
15:32:49 <gordc> jd__: kk.
15:32:52 <jd__> whereas my plan to release it in the upcoming weeks
15:33:04 <llu-laptop> jd__: i'm not sure stevelle has pinged you or not about the ansible support problem of gnocchi with swift
15:33:10 <gordc> good to see what bugs we get from nicodemus_
15:33:13 <jd__> next we'd release 2.1 with sileht work on dynamic resource type, probably around mitaka I guess
15:33:19 <jd__> llu-laptop: he didn't
15:33:25 <gordc> jd__: make sense.
15:33:41 <jd__> then the dynamic resource type support will have to got in Ceilometer for N I guess :)
15:33:58 <jd__> other than that, project is in really good shape so far
15:35:50 <gordc> jd__: cool cool.
15:36:05 <llu-laptop> jd__: the problem is that if goncchi saves data into swift, the ceilometermiddleware will send out notifications which are turned into metrics to be published into gnocchi
15:36:11 <llu-laptop> a loop
15:36:15 <gordc> jd__: hoping lab is ready next week and i can start etsting in a few weeks.
15:36:23 <gordc> llu-laptop: yeah.
15:36:29 <gordc> you can filter it in ceilometermiddleware
15:36:38 <gordc> or just disable ceilometermiddleware.
15:36:40 <sileht> llu-laptop, a configuration flags exists to filterout the gnocchi account
15:36:50 <gordc> or create another proxy-server?
15:37:02 <jd__> what sileht said
15:37:09 <llu-laptop> sileht: configuration flag in ceilometermiddleware?
15:37:17 <jd__> in Gnocchi
15:37:31 <gordc> sileht: i think it needs to happen at proxy-server rather than dispatcher.
15:37:44 <sileht> llu-laptop, https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L39
15:38:00 <sileht> llu-laptop, or https://github.com/openstack/ceilometer/blob/master/ceilometer/dispatcher/gnocchi.py#L47
15:38:09 <sileht> depending of your needs
15:38:45 <gordc> llu-laptop: i'd recommend the ceilometermiddleware. the dispatcher filter will still hammer queue. but yeah, you have options
15:40:09 <gordc> any other items?
15:40:46 <gordc> #topic open discussion
15:41:13 <gordc> just a heads up, feb 1 is last day to submit speaker talks for summit (if you plan to do antyhing)
15:41:19 <gordc> that's all i have.
15:42:51 <gordc> let's call it.
15:42:54 <gordc> thanks folks.
15:42:57 <gordc> #endmeeting