15:00:00 <rhochmuth> #startmeeting monasca
15:00:00 <openstack> Meeting started Wed Jun 15 15:00:00 2016 UTC and is due to finish in 60 minutes.  The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:02 <rhochmuth> o/
15:00:05 <openstack> The meeting name has been set to 'monasca'
15:00:07 <ericksonsantos> o/
15:00:10 <koji> o/
15:00:11 <jayahn> o/
15:00:14 <rhochmuth> agenda is at, https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:00:18 <hosanai> o/
15:00:21 <rhochmuth> Agenda for Wednesday June 15, 2016 (15:00 UTC)
15:00:21 <rhochmuth> 1.	Mid-cycle plan
15:00:21 <rhochmuth> 2.	Summit plans
15:00:21 <rhochmuth> 3.	Reviews
15:00:21 <rhochmuth> 1.	https://review.openstack.org/#/c/304812/
15:00:22 <rhochmuth> 2.	https://review.openstack.org/#/c/329866/
15:00:22 <rhochmuth> 3.	https://review.openstack.org/#/c/326639/
15:00:23 <rhochmuth> 4.	https://review.openstack.org/#/c/327339
15:00:23 <rhochmuth> 4.	Any plans/updates on dimensions resource?
15:00:26 <Kamil_> o/
15:00:29 <iurygregory> o/
15:00:32 <silvamatteus> o/
15:00:41 <shinya_kwbt> o/
15:00:55 <rhochmuth> hi everyone
15:01:09 <rhochmuth> looks like a light agenda for today
15:01:21 <rhochmuth> so, that will leave time for misc discussions/topics
15:01:26 <rbak> o/
15:01:34 <rhochmuth> First up, is the mid-cycle
15:01:41 <rhochmuth> #topic mid-cycle
15:01:55 <bklei> o/
15:02:21 <rhochmuth> We are on for July 19th and 20th, 8:00 AM MST to 1:00 PM MST
15:02:29 <rhochmuth> Via a remote webex session
15:02:54 <rhochmuth> fabiog: has the webex in
15:03:23 <rhochmuth> i'll start putting together an evernote this coming week where we can start to track agenda, and other logistics
15:03:31 <rhochmuth> does that sound good for everyone?
15:03:48 <bklei> works for me
15:04:15 <slogan> sounds good
15:04:25 <jayahn> yeap
15:04:38 <rhochmuth> so moving on
15:04:41 <rhochmuth> #topic summit
15:04:49 <rhochmuth> just a reminder that CFP is open
15:04:53 <rhochmuth> deadline is July 13th
15:04:59 <rhochmuth> it is earlier this time around I believe
15:05:04 <rhochmuth> at least it feels that way
15:05:13 <witek> :)
15:05:38 <rhochmuth> a couple of sessions that i think makes sense for monasca at a more global level
15:05:47 <rhochmuth> 1. Update on Monasca
15:05:57 <rhochmuth> 2. Tutorials/bootcamps
15:06:11 <slogan> I got the impression that 2. was needed in Austin
15:06:23 <slogan> so good :-)
15:06:28 <rhochmuth> I think a presentation supplying an update on the overall Monasca project woudl be good
15:06:50 <rhochmuth> all the features, deploys, connections to other projects, …, might be good to review
15:07:10 <witek> i agree
15:08:00 <rhochmuth> so, i think getting some authors on that would be good
15:08:09 <rhochmuth> i'm assuming you are interested witek
15:08:24 <witek> i won't say no ;)
15:08:49 <rhochmuth> i don't know if there is a limit on authors, but would like to cover a potpourri of all the stuff that is going on
15:09:01 <rhochmuth> i hope i used that word potpourri correctly
15:09:09 <rhochmuth> mayeb smorgasboard is better
15:09:24 <jayahn> usually, program committee does not like more than three authors per presentation.
15:09:25 <rhochmuth> anyway something along those lines
15:09:46 <slogan> unless it is sold as a panel discussion
15:10:01 <rhochmuth> hmmm, i haven't heard that before
15:10:10 <rhochmuth> i don't think a panel session makes sense
15:10:33 <rhochmuth> the other idea is more bootcamps/tutorials
15:10:38 <jayahn> they think a presentation with many authors are "free riders" for summit pass.
15:10:38 <slogan> unless it were people talking about their experiences and where they see it going
15:10:43 <rhochmuth> i think another session like we did in austin would be good
15:10:54 <rhochmuth> but, i'm wondering if a session on deploying monasca makes sense too
15:11:12 <rhochmuth> jayahn: yeah, i can see that
15:11:14 <slogan> aka twc?
15:11:53 <slogan> they have an interesting enough use case
15:11:55 <witek> the interest for the bootcamp in austin was big
15:12:12 <rhochmuth> yeah, that room had several hundred attendees
15:12:29 <rhochmuth> so, that makes be think that a session or two in barcelona would be good
15:12:37 <slogan> problem was I think people were looking for something more intimate and hands on
15:12:57 <rhochmuth> anyway, please let me know if you are interested
15:13:08 <rhochmuth> i dont' want to monopolize all this
15:13:21 <rhochmuth> slogan: i agree
15:13:42 <bklei> slogan, so soft music and mood lighting?
15:13:48 <rhochmuth> although, i don't think anyone wants to get intimate with me
15:13:52 <rhochmuth> oops
15:13:52 <bklei> +1
15:14:22 <rhochmuth> accepts for u bklei
15:14:33 <bklei> roger that
15:15:15 <rhochmuth> is anyone interested in submitting a tutorial/bootcamp?
15:15:34 <rhochmuth> i think we could do two submissions this time
15:15:43 <rhochmuth> building on austin
15:15:54 <jayahn> probably not as a bootcamp, but we are willing to provide "real use case" stroy if it is valuable
15:15:58 <witek> i think we could join it
15:16:12 <jayahn> as a part of any presentation if it helps
15:16:47 <rhochmuth> jayahn: that might make more sense for a general monasca session
15:17:29 <rhochmuth> ok, so i just wanted to get the ideas flowing, and gauge interest
15:17:43 <rhochmuth> let's close on this for now, and sync up next week again
15:17:51 <rhochmuth> we still have 4 weeks for submissions
15:18:36 <rhochmuth> #topic reviews
15:18:48 <rhochmuth> https://review.openstack.org/#/c/304812/
15:18:50 <slogan> I somewhat interested in some kind of "up and running in 5 minutes" sort of thing, showing how my 10 mines of python write switch data to Monasca, and how it can be visualized in grafana, but not sure I could talk in much detail about monasca itself the way others can
15:19:00 <slogan> s/mines/lines/
15:19:39 <rhochmuth> slogan: sounds like a good talk name: "Monasca: Up and running in 5 minutes"
15:19:53 <ericksonsantos> slogan, +1
15:20:01 <slogan> then later in the week there is a deeper dive
15:20:12 <slogan> can we get 3 others to talk about their depolys?
15:20:17 <slogan> er, derploys
15:20:24 <rhochmuth> So, we've got this review for adding support for sessions in the Python Keystone client
15:21:05 <rhochmuth> sorry, handling 2 discussion at once,
15:21:22 <slogan> my bad
15:21:26 <rhochmuth> np
15:21:31 <rhochmuth> it is ok with me
15:22:06 <rhochmuth> I'm just wondering if we can get some more reviews on, https://review.openstack.org/#/c/304812/
15:22:12 <rhochmuth> I've reviewed, abd looks good to me
15:22:39 <rhochmuth> There are a lot of +1's, but most of them are all buddies, so i don't trust them
15:22:42 <witek> I'll take a look
15:23:18 <rhochmuth> actually, i do trust them, but looking for some reviews outside of that group
15:23:24 <rhochmuth> thanks witek
15:23:32 <rhochmuth> if you +1, i'll merge
15:23:41 <rhochmuth> or please feel free to merge too
15:23:45 <rhochmuth> you have +2 prics
15:23:51 <rhochmuth> privs
15:24:31 <rhochmuth> I just want to point out this review, https://review.openstack.org/#/c/329866/
15:24:42 <rhochmuth> There have been a lot of new metrics added recently
15:24:49 <rhochmuth> this review allows you to disable them
15:24:54 <rhochmuth> or enable them
15:25:01 <rhochmuth> whichever way
15:25:26 <rhochmuth> i just think everyone needs to understand that all these new metrics that are being introduced put a lot of load on Monasca
15:25:45 <rhochmuth> We'll be doing a lot more scale testing over the next couple of months
15:26:00 <jayahn> we needed that disabling feature. :) great to see this.
15:26:03 <bklei> i love the ability to turn them off via config -- that's great
15:26:04 <rhochmuth> but this review is for disabling/enabling them if you don't need them and don't like the load being added
15:26:12 <bklei> +1 jayahn
15:26:30 <slogan> that was an easy one to review :-)
15:26:43 <rhochmuth> we briefly discussed making a general solution for enabling/disbling things rather than approaching this piece meal
15:26:50 <rhochmuth> but we're not doing that right now
15:27:15 <rhochmuth> so, sometime in the future maybe we'll get back to addressing this in a more general and architected/designed way
15:27:21 <rhochmuth> for now, this is the best we can do
15:27:54 <rhochmuth> also, there is a reivew for controlling the rate at which disk metrics are collected
15:28:12 <rhochmuth> https://review.openstack.org/#/c/326639/
15:28:19 <rhochmuth> It is a similar theme
15:28:41 <rhochmuth> This review allows you to collect the disk metrics, but at a slower rate
15:28:55 <bklei> nice
15:29:09 <rhochmuth> jayahn and bklei, thanks
15:29:53 <rhochmuth> so, anyway i think folks should keep an eye on the agent
15:30:18 <rhochmuth> most of it should be ok, but there have been quite a few added metrics and changes
15:30:48 <rhochmuth> so, just good to watch, and hopefully we have enough controls in-place that we dont' add a huge amount of metrics if not required
15:30:56 <rhochmuth> https://review.openstack.org/#/c/327339
15:31:09 <bklei> that's me -- not a big change
15:31:14 <bklei> just an optimization
15:31:24 <rhochmuth> so, what does it do
15:31:32 <bklei> prevents hammering nova if we have more than one 'ghost' vm
15:31:42 <bklei> a vm known to virsh/libvirt but not nova
15:32:02 <bklei> in our lab env, we have up to 10 per compute node, and poor nova gets hammered each time the agent wakes up
15:32:18 <bklei> refreshing the cache multiple times doesn't help
15:32:52 <bklei> (the real problem is the ghost vms -- and we're addressing this -- but the plugin could be smarter)
15:33:01 <rhochmuth> ok, sounds good, i'll review and merge
15:33:13 <rhochmuth> after a few more +1's
15:33:27 <bklei> gracias -- it's the same change we added to the ovs plugin that's merged, it's what made me think to do it in libvirt
15:33:55 <rhochmuth> ok, sounds good
15:34:14 <rhochmuth> #topic dimensions resource
15:34:24 <rhochmuth> Any plans/updates on dimensions resource?
15:34:25 <jayahn> i do have a quick question on monasca-agent plugins. if it is okay
15:34:33 <rhochmuth> sure jayahn
15:34:38 <rhochmuth> didn't mean to rush through
15:34:51 <jayahn> we would like to add capability to check ping rsp time & success rate. I was thinking to add these to existing "host alive" checks. but, then think it is not about checking if host is alive. in that sense, might be better to have separate ping plugin.
15:34:51 <jayahn> i need your advise. :)
15:35:26 <rhochmuth> i think it is a great idea
15:35:48 <rhochmuth> not sure if host alive makes sense or not
15:36:08 <rhochmuth> i think for the http status check we report both up/down and latency
15:36:42 <rhochmuth> however, pinging the systems multiple times, once for aliveness and once for latency sounds inneficient
15:36:45 <bklei> 'ping' gets more complicated -- to be done right you really also have to look at security groups -- is ping allowed, etc
15:37:30 <jayahn> bklei that is true.
15:37:41 <rhochmuth> we have ping for VMs and ping for infrastructure
15:38:22 <rhochmuth> There is this for physical hosts, https://github.com/openstack/monasca-agent/blob/master/monasca_agent/collector/checks_d/host_alive.py
15:39:08 <rhochmuth> and this for libvirt VMs at, https://github.com/openstack/monasca-agent/blob/master/monasca_agent/collector/checks_d/libvirt.py#L632
15:39:52 <rhochmuth> jayahn: are you referring to the host_alive check?
15:40:00 <jayahn> i was looking into ping for infrastructure.
15:40:13 <jayahn> but, host_alive
15:40:18 <jayahn> yeap. host_alive
15:41:05 <rhochmuth> i'm regretting calling that plugin host_alive
15:41:20 <rhochmuth> maybe, host_status would have been better
15:41:41 <jayahn> yeap. a word "host_alive" has very specific and narrow meaning.
15:41:55 <rhochmuth> i think it would be preferable to have a single plugin do both simultaneousely
15:42:04 <rhochmuth> that check is one of the harder checks we do
15:42:43 <rhochmuth> it has to be multi-threaded to complete in a reasonable amount of time
15:43:07 <rhochmuth> i hate to have to basically run the same pings to then get latency
15:43:12 <rhochmuth> too
15:43:41 <jayahn> agreed.
15:44:45 <rhochmuth> so, i think should add the latency to host_alive
15:44:57 <rhochmuth> but I'm not sure about renaming
15:45:25 <rhochmuth> anyway, that is idea number 1
15:45:29 <rhochmuth> maybe it is a bad one
15:46:20 <jayahn> host_status would be more suitable name, as you said. but, i will go ahead to write blueprint to add the latency to host_alive check for now.
15:46:39 <rhochmuth> thanks jayahn
15:47:34 <rhochmuth> #topic dimensions resource
15:47:42 <rhochmuth> Any plans/updates on dimensions resource?
15:48:09 <rhochmuth> I don't have any immediate plans
15:48:20 <rhochmuth> not sure who asked that question
15:48:36 <rbak> I'm pretty sure bklei added it.
15:48:40 <bklei> that's me
15:48:53 <bklei> at the summit you mentioned HPE was working it -- true?
15:49:07 <rhochmuth> we were planning on it, but it didn't materialize
15:49:29 <bklei> so no plans to pick it up?  we may if that's the case
15:49:53 <rhochmuth> are you seeing where this is going to be real helpful
15:49:54 <bklei> rbak would really like it to make grafana templating more effecient
15:50:13 <rhochmuth> ahhh, yeah, it makes complete sense
15:50:22 <rhochmuth> if you want to pick it up that would be great
15:50:33 <witek> so it would be listing all dimensions stored in influx/vertica?
15:50:40 <rhochmuth> i'm guessing we won't get to it over the next month or two or three
15:50:50 <bklei> ok -- i probably will, will confirm with resource allocaters
15:51:26 <rhochmuth> witek: the idea is that once you know a metric name, that you want to then list the dimensions for that name
15:51:44 <rbak> Actually that's not quite right
15:51:47 <rhochmuth> sonce you select a dimenion name, you then want to know all the valaues for that dimension name
15:51:48 <rbak> What we need is given a specific dimension key, list all dimension values.
15:52:05 <bklei> like 'hostname'
15:52:14 <rbak> Tempting isn't tied to a specific metric unfortunately.
15:52:23 <rbak> s/tempting/templating
15:53:35 <rbak> If you want to get the dimensions for a specific metric at the moment you can do a metric-list with --name, so that's mostly covered already.
15:53:35 <rhochmuth> so, can we review next week?
15:53:45 <bklei> :) i'll start soon
15:53:54 <witek> :)
15:53:55 <bklei> hopefully
15:54:14 <bklei> a bit of a rats-nest -- java/python/vertica/influxdb
15:54:24 <rhochmuth> aha
15:54:48 <bklei> that's why i wanted u to do it :)
15:55:07 <rhochmuth> well, i personally fell like this is a job for rbrandt
15:55:13 <rhochmuth> he's been in that code the most
15:55:19 <rhochmuth> just not sure i can get him
15:55:23 <rhochmuth> i'll check
15:55:43 <bklei> k -- i'll include him in the reviews if i start it -- but will wait to hear from you/him
15:56:03 <rhochmuth> it is hard diving into that code just adding a new feature
15:56:03 <bklei> he's alot smarter than me anyway
15:56:32 <rhochmuth> but you are better looking
15:56:39 <bklei> says u
15:57:07 <rhochmuth> we've got 3 minutes
15:57:15 <rhochmuth> anyone have anythign in closing
15:57:24 <rhochmuth> shoudl we tee upo something for next week?
15:57:37 <rhochmuth> anything urgent?
15:58:56 <rhochmuth> ok, i guess that is it
15:59:02 <rhochmuth> ended early for once
15:59:05 <rhochmuth> bye everyone
15:59:06 <bklei> thx roland
15:59:22 <witek> bye
15:59:24 <koji> bye
15:59:41 <rhochmuth> #endmeeting