15:00:24 <gordc> #startmeeting telemetry
15:00:25 <openstack> Meeting started Thu Jan  7 15:00:24 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:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:29 <openstack> The meeting name has been set to 'telemetry'
15:00:40 <llu-laptop> o/
15:00:45 <ildikov> o/
15:00:45 <sileht> \o
15:00:47 <zqfan> hi
15:00:53 <liusheng> o/
15:00:56 <ildikov> Happy New Year! :)
15:01:01 <gordc> hey cool. people are back from holidays
15:01:07 <llu-laptop> happy 2016
15:01:17 <gordc> happy new years.
15:01:31 <_nadya_> o/
15:01:42 <pradk> o/
15:02:02 <gordc> ok let's start this.
15:02:32 <cdent> oh, hey, hi
15:02:35 <gordc> #topic roadmap items (new/old/blockers) https://wiki.openstack.org/wiki/Telemetry/RoadMap
15:02:41 <gordc> typed in wrong window
15:03:29 <gordc> just for reference, the m-2 milestone will be in about 1.5 weeks
15:04:10 <_nadya_> gordc: is it still ok to merge specs?
15:04:12 <gordc> i think we have most things covered (except if someone wants to start looking at polling cache)
15:04:47 <gordc> _nadya_: yep, we're pretty relaxed on that. after m-2 we'll start being a lot more critical on whether something can make it in on time
15:05:12 <ildikov> m-3 is end of Febr, so it should be ok
15:05:38 <gordc> _nadya_: your caching item is probablysomething big so that should close sooner rather than later
15:05:53 <_nadya_> gordc: ok, cool. I'm investigating caching now, so will take a look at polling. Especially if it relates to "improve instance metering"
15:06:17 <gordc> _nadya_: sure. please sync with liusheng on that.
15:06:24 <_nadya_> gordc: ok!
15:06:41 <gordc> i'm going to assume rally tests are not in scope for mitaka
15:06:47 <gordc> we dont really have a name tied to that.
15:06:59 <liusheng> will keep eyes on it ;)
15:07:50 <gordc> just an fyi, i've merged the initial structure for aodhclient
15:08:02 <gordc> https://github.com/openstack/python-aodhclient
15:08:17 <gordc> i have a topic later to discuss what syntax we want
15:08:42 <gordc> liusheng: are we still on schedule for composite alarms?
15:09:06 <liusheng> gordc: I am working on it
15:10:41 <gordc> liusheng: cool cool.
15:10:43 <liusheng> gordc: will complete the bp in few days
15:10:45 <sileht> gordc, I have still work on keystonev3 and aodh
15:10:52 <sileht> gordc, and found a bug in ceilometerclient
15:11:13 <gordc> sileht: yeah i saw that, you think it needs to be ported to aodhclient?
15:11:36 <sileht> gordc, no it's on the redirection code from ceilometer to aodh
15:11:49 <gordc> ah cool cool
15:12:17 <liusheng> gordc: fyi, there is a change about alarm dashboard intergration, https://review.openstack.org/#/c/215569/
15:12:28 <sileht> Also my oslo.messaging batching code is ready
15:12:30 <liusheng> gordc: should we think about aodhclient ?
15:12:31 <_nadya_> gordc: btw, we did some ceilometer-related stuff for Rally, let me find links... #link https://review.openstack.org/#/q/topic:sample_generator_batching
15:12:45 <gordc> liusheng: cool, i was just giong to say i need to follow up on that
15:12:57 <_nadya_> #link https://review.openstack.org/#/c/244007 #link https://review.openstack.org/#/c/243841/
15:13:03 <sileht> (but gate is failing for bug unrelated to my chagne)
15:13:39 <gordc> _nadya_: are you using sileht's batching code?
15:14:17 <_nadya_> gordc: not sure. is sileht's code in Rally or in Ceilo?
15:14:21 <gordc> sileht: that's great. can't wait to get that in.
15:14:27 <gordc> _nadya_: it's not in yet.
15:14:31 <llu-laptop> _nadya_: glad to see that
15:14:50 <gordc> sileht: we can create misleading charts to show how much better it is ;)
15:15:10 <_nadya_> and one more #link https://review.openstack.org/#/c/237754/
15:15:11 <sileht> gordc, yeah good news thx _nadya_
15:15:11 <gordc> 300% faster sound like a good number?
15:15:16 <sileht> lol
15:15:38 <gordc> as long as we don't explain how we got numbers ;)
15:16:19 <gordc> _nadya_: do you know if ityaptin  is still looking at componentisation?
15:16:25 <gordc> (not really important but i thought i'd ask)
15:17:02 <_nadya_> gordc: no, we decided that it's better to do improving instead of refactoring
15:17:11 <gordc> _nadya_: agreed
15:17:12 <_nadya_> gordc: will abandon the spec
15:17:39 <gordc> kk, let's take a look at it next cycle (and finalise 'what to do with ceilometer api')
15:17:52 <_nadya_> yep
15:18:24 <gordc> #action remember to create item for austin summit re: ceilometer api
15:18:34 <ildikov> my favourite topic :)
15:19:06 <gordc> i guess last item is the poc for multiple definition files...
15:19:13 <gordc> pradk: any work there?
15:19:46 <pradk> gordc, havent looked much into that part yet.. i know someone had a patch to support loading files from a dir
15:19:58 <gordc> yeah peristeri
15:20:19 <peristeri> Hey gordc
15:20:22 <pradk> gordc, yea
15:20:52 <gordc> peristeri: you still looking at that multiple file loading stuff?
15:21:00 <pradk> gordc, i think the biggest part ogf that is to get input from other projects on if they are willing to own and maintain the files
15:21:12 <pradk> peristeri, is your stuff merged yet?
15:21:42 <ildikov> pradk: regarding willingness I would not hope much
15:21:44 <peristeri> gordc, yes, I was tied up with some internal stuff. I should have the time to finish it today/tomorrow.
15:21:47 <pradk> gordc, i can look into kicking off an email thread and see what people say
15:21:49 <gordc> pradk: there was a thread a few months back.
15:21:56 <gordc> they probably wont' maintain it.
15:22:08 <gordc> but i think it's probably more consumable if we split the files regardless.
15:22:16 <ildikov> gordc: I think I remember that one
15:22:22 <pradk> gordc, yea agree with that
15:22:29 <ildikov> gordc: +1
15:22:45 <gordc> ildikov: yeah, i don't think anyone wants to actually own anything... we're all too good at the art of deferring.
15:23:00 <pradk> gordc, i'll look into that in conjuntion with peristeri's patch for M3 perhaps
15:23:06 <ildikov> smaller files would be great, better structure, I hope
15:23:08 <gordc> pradk:
15:23:10 <gordc> cool cool
15:23:16 <ildikov> gordc: yeah, I know :(
15:24:32 <gordc> let's switch to aodhclient and run through other projects.
15:24:47 <gordc> oh wait midcycle.
15:24:54 <gordc> #topic virtual midcycle?
15:25:09 <gordc> do we want one? we have any pressing items to discuss?
15:25:29 <gordc> or does everyone have a work item that they are content with?
15:26:16 <_nadya_> I have two: transformers and metadata caching. But we can discuss it in ML or irc, as you wish :)
15:26:39 <pradk> i'm ok with skipping unless we really have stuff to go over for couple of days..
15:27:47 <gordc> kk. let's just push on virtual midcycle then.
15:28:01 <gordc> i don't see many spcs to discuss
15:28:17 <gordc> _nadya_: feel free to push the topics to ML.
15:28:21 <_nadya_> ok
15:28:29 <gordc> (might be faster than waiting for a midcycle anyways)
15:28:55 <_nadya_> maybe I'll start here if we have time :)
15:29:07 <gordc> if anything comes up that we feel like will be debateable we can setup a hangout session and announce on list
15:29:34 <gordc> _nadya_: sure. let's do aodhclient first (it'll probably be short
15:29:46 <gordc> #topic how to represent gnocchi alarms in client
15:30:11 <gordc> for reference, i've added https://review.openstack.org/#/c/263887/3/aodhclient/shell.py
15:30:22 <gordc> basic alarm CRUD commands
15:30:27 <gordc> similar to ceilometercilent
15:30:44 <liusheng> do we have a plan about aodhclient release ?
15:30:53 <gordc> only diff is i added alarm search which actually points to complex alarm api
15:31:10 <gordc> liusheng: yep, i think we just need the basic ceilometerclient features ported first
15:31:24 <liusheng> gordc: agree
15:31:28 <gordc> i think the questions i have is for alarm history are we ok with:
15:31:39 <gordc> aodh alarm-histroy show
15:31:43 <gordc> aodh alarm-history search
15:31:53 <pradk> gordc, so whats the deprecation like, we still have alarm cli in ceilometer for Mitaka? or will we remove it in favor of aodhclient
15:31:54 <gordc> ignore spelling
15:32:22 <gordc> pradk: i will probably change all the ceilometerclient alarm calls to aodhclient (if i can)
15:33:02 <gordc> but ceilometerclienet alarming functionality won't be removed (if ever, since i'm not porting everything and it's different syntax)
15:33:02 <llu-laptop> I think we already redirect the alarm api calls in ceilometerclient to aodh, right?
15:33:09 <gordc> llu-laptop: yep
15:33:23 <ildikov> I'm ok with the proposal
15:33:36 <gordc> ildikov: cool cool
15:33:59 <gordc> oh also, i was thinking of *leaving out* combination alarm support from aodhclient
15:34:29 <gordc> considering we want people to use composite alarm (when it is added)
15:35:04 <gordc> ^ another reason for keeping ceilometerclient alarming code
15:35:27 <liusheng> gordc: :)
15:35:28 <llu-laptop> gordc: in that case, we should state clearly in release notes of aodhclient
15:35:41 <ildikov> llu-laptop: +1
15:35:49 <gordc> llu-laptop: that it doesn't support combination alarms?
15:36:14 <ildikov> also the admin guide needs to be checked once the new client is ready to fly
15:36:21 <llu-laptop> gordc: yep, and don't misguide people to think aodhclient is the alarm part of ceilometerclient
15:36:25 <gordc> ildikov: yep
15:36:45 <liusheng> llu-laptop: yes, agree,
15:36:50 <llu-laptop> to avoid confusion and futher explanations
15:36:57 <gordc> llu-laptop: cool cool. yeah. i'm ok to have a direct port, i just didn't feel like porting something that we will deprecated
15:37:04 <ildikov> gordc: I couldn't get the install guide section in still, the packages are not ready as much as I saw not long ago :(
15:37:12 <llu-laptop> gordc: agreed
15:37:28 <gordc> ildikov: *sigh*
15:37:45 <ildikov> gordc: I know, a big one :(
15:38:01 <gordc> ildikov: should we just make it for fedora and leave ubuntu/suse out?
15:38:11 <gordc> or does suse have correct packages?
15:38:20 <ildikov> I can try to push for the first patch of the doc and have the Suse part later, when it's ready, but I didn't get answer regarding the Ubuntu package bug still
15:38:54 <ildikov> gordc: last time they didn't have, so I split the original patch and have the Suse part in WIP
15:39:15 <ildikov> gordc: also added a workaround to the Ubuntu part
15:39:24 <ildikov> will ping the docco guys to check at least that one
15:39:28 <gordc> workaround == use debian? :)
15:39:35 <gordc> ildikov: sounds good
15:39:38 <ildikov> although that's for Mitaka, hey don't backport parts
15:39:43 <ildikov> gordc: lol :)
15:40:03 <gordc> oh. i had one last item for client. how do we want to describe gnocchi alarm?
15:40:05 <ildikov> ok, side track ended, sorry :)
15:40:15 <gordc> ^ jd__, sileht
15:40:39 <ildikov> in what sense do we mean describe here?
15:41:07 <gordc> "aodh gnocchi-alarm *" or just reuse "aodh alarm *" and add type
15:41:35 <ildikov> ah, ok, the command name
15:41:45 <gordc> and whatever other additional params are required
15:41:54 <llu-laptop> speaking of that, I have the same question about event alarm
15:42:03 <ildikov> my vote would be on the second option or smth like
15:42:07 <gordc> llu-laptop: that too
15:42:10 <llu-laptop> we're planning to add new types of event alarm
15:42:12 <liusheng> the alarm-gnocchi-* commands are too long :(
15:42:13 <gordc> i guess it's related
15:42:22 <llu-laptop> so aodh event-alarm or aodh alarm -t <type>
15:42:44 <jd__> o/
15:42:53 * jd__ reads backlog
15:43:00 <gordc> llu-laptop: i guess both event alarm and gnocchi alarm are in same boat.. and same as composite
15:43:29 <gordc> seems like i should try to support a 'type' param and just let people use aodh alarm * -type blah
15:43:44 <llu-laptop> I saw a potential stevedore use case here :)
15:43:50 <jd__> I think alarm --type would be better
15:43:56 <liusheng> +1
15:43:57 <jd__> 'cause it's likely more easy to extend, or less weird
15:43:59 <ildikov> yeah, more generic
15:44:06 <llu-laptop> +1 for -t
15:44:11 <ildikov> jd__: +1
15:44:27 <gordc> kk. makes sense to me. will work on that.
15:44:34 <zqfan> +1 for -t
15:44:43 <gordc> will raise if i run into any blocker
15:45:32 <gordc> that's all for me. let's move on to ceilometer topics if any?
15:45:46 <gordc> #topic ceilometer topics
15:45:54 <gordc> anything?
15:46:04 <liusheng> WSME deprecation ?
15:46:25 <llu-laptop> sorry, one more question about aodhclient,
15:46:31 <Qiming> +1000 for -t
15:46:38 <gordc> liusheng: i don't know if we have a resource but if we do go for it.
15:46:41 <gordc> llu-laptop: sure
15:47:07 <llu-laptop> i'm gonna give some presentation to some customers next week, should I encourage them to use aodhclient now?
15:47:37 <llu-laptop> or ask them to wait to mitaka release?
15:47:39 <gordc> llu-laptop: i'm not really done yet. but i guess for mitaka they should use it (i should have it all good by then)
15:47:54 <gordc> llu-laptop: oh yeah, let's say aodhclient is for mitaka only
15:47:56 <llu-laptop> gordc: got that
15:48:22 <gordc> anything earlier is "use at own risk"
15:48:49 <gordc> anything for ceilometer?
15:48:50 <llu-laptop> liusheng: please go on
15:49:15 <gordc> if someone can review my doc spec, that'd be great: https://review.openstack.org/#/c/242216/
15:49:47 <gordc> let's go gnocchi
15:49:51 <gordc> #topic gnocchi topics
15:50:21 <gordc> jd__: we targeting something big for last half of cycle?
15:50:34 <jd__> just the split of archive
15:50:40 <jd__> s
15:50:45 <gordc> cool cool
15:50:53 <gordc> if i have time i'll look at tagging support
15:51:05 <jd__> sheeprine has something on that
15:51:07 <gordc> i have random thoughts but nothing on paper
15:51:11 <gordc> oh cool
15:51:15 <gordc> i'll wait and see then
15:51:18 <jd__> but if you have some thoughts, please share :)
15:51:51 <gordc> i'll keep an eye and unleash manifesto when i finish client
15:52:11 <gordc> open discussion?
15:52:26 <gordc> #topic open discussion
15:52:40 <_nadya_> I'd like to share some test results with you
15:52:47 <gordc> sure
15:53:12 <_nadya_> I had 3 notification agents and coordination enabled
15:53:21 <_nadya_> Test description:
15:53:21 <_nadya_> 30 000 samples with cpu metric was sent in total
15:53:21 <_nadya_> 1000 resources was used and samples were sent in batches 1000 samples each. Each batch contained all resources, it means that all samples in a batch belonged to different resources.
15:53:23 <_nadya_> Also, cpu for each resource is increasing by 20 each time.
15:53:25 <_nadya_> Ideally, cpu.delta should be 20 for all resources
15:54:17 <_nadya_> try to take a look here https://www.dropbox.com/s/r5ik5l89gb0c5vq/transformers.png?dl=0
15:55:00 <_nadya_> is it accessible?
15:55:02 <llu-laptop> sorry, dropbox is also banned in PRC
15:55:22 <_nadya_> oh((
15:55:31 <gordc> _nadya_: what is the y access?
15:55:42 <_nadya_> llu-laptop: what can I use instead?
15:56:13 <gordc> llu-laptop: picture a rectangle with a diagonal line from bottom left to top right :)
15:56:40 <_nadya_> yep :) it's to make it clear what data was send
15:56:41 <llu-laptop> _nadya_: don't bother, I'll try to find a way to access it through company VPN tomorrow when I in office
15:57:03 <_nadya_> gordc: y is metric value
15:57:10 <llu-laptop> I don't know if liusheng can access that :)
15:57:30 <_nadya_> so the plot below should be a line with y=20
15:57:33 <liusheng> llu-laptop: no
15:57:51 <liusheng> llu-laptop: apparently :(
15:58:20 <_nadya_> but you see that we have 320, it means that we lost 16 samples during transformation
15:58:36 <_nadya_> and one more picture https://www.dropbox.com/s/oen9c7hdwxmxt5k/redis_vs_rabbit.png?dl=0
15:59:38 <_nadya_> the plot below with 3 notification agents but with Redis for caching . It's better, but still can't get "20" line
16:00:06 <gordc> _nadya_: want to carry this on in #openstack-telemetry (i have a feeling someone is going to yell at exactly 1600)
16:00:15 <gordc> ok. let's switch
16:00:17 <_nadya_> gordc: ok
16:00:18 <gordc> thanks everyone
16:00:24 <gordc> #endmeeting