15:00:51 <rhochmuth> #startmeeting monasca
15:00:53 <openstack> Meeting started Wed Aug 31 15:00:51 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:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:57 <openstack> The meeting name has been set to 'monasca'
15:01:19 <rhochmuth> o/
15:01:20 <rbak> o/
15:01:24 <koji> o/
15:01:24 <rhochmuth> Hi everyone
15:01:28 <cbellucci> o/
15:01:30 <shinya_kwbt> o/
15:01:34 <rhochmuth> The meeting agenda has been posted at, https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:01:44 <rhochmuth> Agenda for Wednesday August 31, 2016 (15:00 UTC)
15:01:45 <rhochmuth> 1.	Ceilosca
15:01:45 <rhochmuth> 2.	Status of monasca-events?
15:01:45 <rhochmuth> 3.	Schedule for Monasca-Newton (RC, GA, when last contributions are possible, list of new features)
15:01:45 <rhochmuth> 4.	Reviews
15:01:45 <rhochmuth> 1.	https://review.openstack.org/#/c/361476/
15:01:45 <rhochmuth> 2.	https://review.openstack.org/#/q/status:open+monasca,n,z
15:01:46 <rhochmuth> 3.	https://review.openstack.org/#/c/351930/
15:01:46 <rhochmuth> 4.	Dimension names and IDs
15:01:47 <rhochmuth> 5.	https://review.openstack.org/#/c/362339/
15:02:03 <rhochmuth> If there are any other items to discuss please append to the list
15:02:26 <rhochmuth> So, the first item was Ceilosca
15:02:34 <rhochmuth> I'm not sure everyone is here for that discussion yet
15:02:52 <rhochmuth> I'm expecting a couple of folks from HPE and a couple from Watcher
15:03:02 <rhochmuth> Is anyone here from Watcher?
15:03:06 <bklei> o/
15:03:36 <rhochmuth> OK, so maybe I should have put the Ceilosca/Watcher discussion later in the agenda
15:03:46 <rhochmuth> Let's see if folks show-up for that later
15:03:49 <Atul> Hi Roland, Atul is here from Ceilosca.
15:03:56 <rhochmuth> hi atul
15:04:04 <rhochmuth> thanks for joining
15:04:14 <rhochmuth> i'm not seeign any folks from watcher yet
15:04:15 <Atul> apologies this is my first IRC meeting, are we supposed to type only?
15:04:39 <rhochmuth> yes, it is typing only
15:04:45 <ashwinhpe> hi atul and roland
15:04:50 <Atul> roger! if they are not here. you can push ceilosca to later
15:04:54 <rhochmuth> hi ashwinhpe
15:05:32 <rhochmuth> i'll check back to see if anyone from watcher shows-up
15:05:40 <rhochmuth> let's move on then
15:05:45 <rhochmuth> #events
15:05:50 <rhochmuth> #topic events
15:05:54 <cbellucci> this was from Tomasz
15:06:13 <rhochmuth> so, are you just wondering about status?
15:06:14 <cbellucci> there were discussions about events and we would like to know the status and interest
15:06:18 <cbellucci> correct
15:06:34 <rhochmuth> it looks like this is moving up in priority from hpe
15:06:49 <rhochmuth> we are expecting to put resources on it and have started to work on it again
15:07:10 <rhochmuth> if you/fujitsu are interested, we would love to have your involvement
15:07:17 <cbellucci> great to hear that. how can we proceed?
15:07:20 <cbellucci> indeed
15:08:00 <rhochmuth> i think we're going to need some more in-depth planning and esign discussions
15:08:09 <rhochmuth> to coordinate activities
15:08:19 <rhochmuth> i can setup some meetings next week
15:08:25 <rhochmuth> to discuss further
15:08:28 <cbellucci> perfect! thank you
15:08:32 <rhochmuth> i don't think this format is going to be some great for that
15:08:40 <rhochmuth> so probably lync disucssions
15:08:42 <cbellucci> agree :)
15:08:52 <rhochmuth> i was also going to setup some meetings about cassandra
15:08:57 <rhochmuth> next week too
15:09:04 <cbellucci> next week Witek will be back too and Tomasz is interested
15:09:12 <rhochmuth> so it will be a busy week
15:09:17 <rhochmuth> next week
15:09:17 <cbellucci> yep, cassandra is hot topic too
15:09:32 <cbellucci> matthias is wokring on that
15:09:38 <rhochmuth> ok, will send invites out later today
15:09:44 <cbellucci> thank you
15:10:16 <rhochmuth> #topic monasca-newton schedule
15:10:24 <cbellucci> again fujitsu :)
15:10:30 <rhochmuth> i've been gone so long, i haven't tracked well
15:10:39 <rhochmuth> so, i'll probably be in trouble again
15:10:45 <cbellucci> we would like to understand better deadlines and until when we can contribute
15:10:52 <rhochmuth> in general though, the quality is extremely high right now
15:11:05 <rhochmuth> i think the deadline is basically very soon
15:11:13 <rhochmuth> there is a schedule posted by openstack
15:11:19 <cbellucci> we see 12th...
15:11:27 <rhochmuth> we are supposed to be mainly in wa mode
15:11:35 <rhochmuth> 12th of september hopefully
15:11:38 <rhochmuth> not august
15:11:43 <cbellucci> yep :)
15:11:56 <rhochmuth> so, i think the 12th it is
15:12:09 <rhochmuth> that would work as far as i know for everything we are trying to get done
15:12:12 <cbellucci> ok. can we contribute until that day?
15:12:24 <rhochmuth> most of the work right now is on bug fixes
15:12:48 <rhochmuth> yes, you can contribute until that day, but i'm not expecting any new features, beyond what is in flight and almost complete
15:12:58 <cbellucci> ok, there is a list of new features too?
15:13:01 <cbellucci> ok sure
15:13:05 <rhochmuth> would like to see focus on bugs
15:13:19 <rhochmuth> there are the blueprints we are working on
15:13:30 <cbellucci> ok, thanks
15:13:40 <rhochmuth> but the reviews we';; be covering in a few minutes are the main focus
15:14:00 <rhochmuth> i'm just not expecting a new blueprint to show-up
15:14:03 <cbellucci> understood
15:14:21 <rhochmuth> are we good then, can we move on?
15:14:31 <cbellucci> perfect, thanks let's move on
15:14:40 <rhochmuth> #topic reviews
15:14:53 <rhochmuth> https://review.openstack.org/#/c/361476/
15:15:32 <rhochmuth> So this review introduces a parameter to the libvirt plugin to control the frequency of collecting vnic metrics
15:15:39 <rhochmuth> It is a simple change
15:15:51 <rhochmuth> but, i wanted to point it out and see if it impacted anyone
15:16:29 <rhochmuth> expecially charter, as you guys are deploying off of master
15:16:55 <rhochmuth> oops, it looks like craig merged it
15:17:01 <rhochmuth> i wasn't expecting that
15:17:12 <rhochmuth> was hoping to check with folks first
15:17:17 <rbak> I'll take a look, but I don't think it will be a problem.
15:17:25 <rhochmuth> thanks rbak
15:17:40 <rhochmuth> sorry, it got merged prior to your approval
15:17:43 <rhochmuth> was hoping to check
15:17:48 <rhochmuth> first
15:17:57 <rhochmuth> if it is a problem, let me know
15:18:09 <rbak> will do
15:18:15 <rhochmuth> thx
15:18:22 <rhochmuth> https://review.openstack.org/#/q/status:open+monasca,n,z
15:18:42 <rhochmuth> uh oh, that isn't a review
15:18:51 <rhochmuth> https://review.openstack.org/#/c/351930/
15:19:41 <rhochmuth> So, just wanted to point out this review has been in progress
15:20:26 <rhochmuth> This review allows you to specify multipl coom delimited dimension in the group_by query parameter
15:20:36 <rhochmuth> coom -> comma
15:21:00 <rhochmuth> rbak: you might be interested in that review too, for integration into grafana
15:21:16 <rbak> Yeah, we've been waiting for this.  I'll take a look
15:21:47 <rhochmuth> thx: i believe rbrandt is basically done, barring any issues that come up
15:22:05 <rhochmuth> https://review.openstack.org/#/c/350830/
15:22:21 <rhochmuth> So, this is the one that I really wanted to discuss today
15:22:58 <rhochmuth> It was all looking good, until Kaiyan mentioned ids and that also got me thinking about pagination, my favorite topic
15:23:48 <rhochmuth> the first question, independent of grafana, is why would you need ids?
15:24:14 <rhochmuth> in the case of metric names, it is a 1D structure
15:24:24 <rhochmuth> in the case of dimension names and values, it is a 2D structure
15:24:32 <rhochmuth> a list of lists
15:24:39 <rhochmuth> similar to measurements and statistics
15:25:00 <rhochmuth> the combinatino of a metric name and a dimension name uniquely identify it
15:25:29 <rhochmuth> in the case of the values query, you also need to know the dimenion values that are returned
15:25:44 <rhochmuth> so, it looks like there is a problem with pagination right now
15:25:49 <rhochmuth> in the dimension values query
15:27:03 <rbak> I would say that if anything we need more consistency.  I shouldn't need to know what I'm paging through in order to stitch the pages back together.
15:27:18 <rbak> It just makes the api easier to use, and having an id is a step in that direction.
15:27:55 <rhochmuth> so, how does the id help?
15:28:03 <rhochmuth> in this case?
15:28:20 <rbak> Like I said. consistency.
15:28:40 <rbak> It isn't strictly necessary, but it means I can process these pages the same as any of the others.
15:29:10 <rhochmuth> consistency with what, other queries
15:29:28 <rbak> metrics, statistics, dimension values, etc.
15:29:32 <rhochmuth> ok
15:30:13 <rhochmuth> so, what happens if you query the dimension values for a dimension name of "resource_id", for which there are millions of potential resources
15:30:42 <rhochmuth> how would you  page through the list of values for the dimension value of resource id?
15:30:55 <rhochmuth> if the limit is 10,000
15:31:34 <rhochmuth> i'm expecting that the query woudl return a max of 10,000 dimenion values, similar to how the measuremnts and statistics queries work with 2-D lists of lists
15:31:49 <rbak> I don't remember the specifics, but it's something like query for all the pages using the next links.  At the end use the ids to stitch together the results.
15:32:12 <rbak> I can point you to the current grafana code if you want.
15:32:33 <bklei> exactly -- and when paginating through pages of statistics, rbak would use id.   so doing the same for dimension names/values is a noop
15:32:34 <rbak> But Grafana is only an example here.  This would make it easier for anyone writing a client
15:33:16 <rhochmuth> the id that is returned is a composite of (metric name, dimension name)
15:33:36 <rhochmuth> actually a hash of (metric name, dimension name)
15:33:47 <rhochmuth> but the dimension value is not part of the id
15:34:08 <rhochmuth> if you had more than 10,000 values, i'm just wondering how to page
15:34:35 <bklei> right -- just so it's unique per api call
15:34:54 <rhochmuth> i'm expecting the next link that is returned to somehow get to the same metric name and diemsion name, but offset to the correct dimension value
15:34:59 <bklei> (consistent among pages for a given api call, that is)
15:35:38 <bklei> yes -- that's how it works, but offset in this case isn't id -- but the dimension name (in the /dimensions/names/values case)
15:35:52 <bklei> the list is returned alphabetically
15:35:53 <Kaiyan> The offset is an individual dimension value in this case. We can't use the id to be offset in current implementation.
15:36:10 <bklei> +1
15:36:29 <rbak> Right, and that id shouldn't be offset.  offset changes.  id needs to be consistent amongst all the pages.
15:36:58 <rhochmuth> the offset that is returned would have to be a combination of ((metric name, dimension name), dimension value)
15:37:02 <rhochmuth> or
15:37:09 <rhochmuth> (id, dimension value)
15:37:34 <rhochmuth> in string format
15:37:42 <rhochmuth> id_dimensionvalue
15:38:01 <bklei> no -- just the dimension name or value -- so we can grab the spot in the list
15:38:37 <bklei> id doesn't play into offset at all in this case, because id isn't in the db
15:38:53 <rhochmuth> but don't you need to know the metric name too, so you know what list you are indexing into
15:39:29 <rhochmuth> it is a 2-D structure
15:39:31 <rhochmuth> a list of list
15:39:48 <bklei> metric name is optional, and is part of the url to get the list to return.  but either the dimension name or value (depending on the api call) is how you know where the offset lands
15:40:12 <rhochmuth> ok, i'll take another look off-line
15:40:26 <rhochmuth> sounds like i need to spend a little more time on this
15:40:39 <bklei> i'm speaking mostly for /dimensions/names/values -- kaiyan can correct me for the new patch
15:41:13 <rhochmuth> i'll create some examples with greater than 10,000 resources and see what happens
15:41:17 <rhochmuth> i should have done that sooner
15:41:34 <bklei> we've tested with very low offsets, it works :)
15:41:40 <bklei> or limits rather
15:41:50 <Kaiyan> there is no required input arg for dimensions/names but for dimensions/names/values dimension_name is required
15:42:04 <rhochmuth> thx bklei
15:42:26 <rhochmuth> ahh, yes i could specify a limit of 2 or 10
15:42:32 <rhochmuth> that will save me some time loading the db
15:42:35 <bklei> yeah
15:42:41 <rhochmuth> thx
15:42:50 <bklei> (thumbsup)
15:43:14 <rhochmuth> https://review.openstack.org/#/c/362339/
15:43:18 <rhochmuth> i think that is the last one
15:43:34 <rbak> That's mine, just trying to get some eyes on it.
15:43:43 <rbak> It should be a simple fix
15:44:00 <rbak> And right now it means that anyone creating an alarm through the cli can break the overview page.
15:44:02 <rhochmuth> ok, it looks good to me
15:44:43 <rbak> Thanks, that's all I had.
15:44:50 <rhochmuth> #topic ceilosca/watcher
15:44:58 <rhochmuth> has anyone shown up from watcher project
15:46:13 <rhochmuth> sorry ashwin and atul
15:46:26 <rhochmuth> i thought they would attend the monasca meeting this week
15:46:37 <rhochmuth> i beleive they have their meeting right after ours
15:46:52 <rhochmuth> so, we could hang-out
15:47:03 <ashwinhpe> np...if they can try this patch out and let us know that will be great https://review.openstack.org/#/c/363315
15:47:05 <rhochmuth> it is in this irc room
15:47:54 <rhochmuth> besides watcher/ceilosca, are there any other areas to look at/discuss
15:48:03 <ibmko> rhochmuth, one thing
15:48:20 <rhochmuth> my one action item is to setup a cassandra and events meetings next week
15:48:30 <ibmko> rbak, reminding myself with the clean up script for the deleted VMs :)
15:49:05 <rbak> Turns out we already had that in our puppet repo.
15:49:23 <rbak> Give me a moment and I'll find the link
15:49:28 <ibmko> thanks
15:49:46 <rhochmuth> we also updated our vm deletion script, but it is not upstream
15:49:52 <rbak> https://github.com/openstack/puppet-monasca/blob/master/templates/vm_alarm_cleanup.py.erb
15:49:55 <rhochmuth> sorry, ibmko
15:50:14 <ibmko> thanks we will have a look
15:50:55 <rhochmuth> thx rbak
15:51:35 <ibmko> so this puppet repo is now primary means of monasca deployment ?
15:51:48 <ibmko> from what it use to be the ansible one ?
15:52:04 <rhochmuth> the puppet repos are used by charter
15:52:17 <rhochmuth> the ansible one's are a bit out-dated
15:52:21 <rbak> It's one way of deploying, I don't know if I would say it's primary
15:52:30 <ibmko> ok
15:52:36 <rbak> We use it, and there are a few other companies at least looking at it.
15:52:55 <ibmko> we have our own at the moment
15:52:59 <ibmko> ansible based
15:53:17 <rhochmuth> there is also a new ansible monasca project being created
15:53:19 <rhochmuth> see, https://review.openstack.org/#/c/360140/
15:53:36 <ibmko> ok thx
15:54:23 <rhochmuth> so Jesse Pretorius from Rackspace has proposed adding a openstack-ansible project for monasca, which will be approved shortly i'm assuming
15:54:39 <rhochmuth> in the future, i think that is going to be the best place to look for ansible based deployer
15:54:58 <rhochmuth> i don't know what he has completed and what is available in an upstream repo
15:55:04 <rhochmuth> but you could check with him
15:55:20 <rhochmuth> as this seems to be getting more recent development
15:55:36 <rhochmuth> other than that, i don't know anything about it
15:56:08 <ibmko> rhochmuth, thanks I'll check that
15:56:33 <rhochmuth> so, i'm going to end this meeting, unless someone has another item
15:56:39 <ibmko> as we don't want to maintain our own if not necessary
15:56:44 <rhochmuth> i'll hangout for watcher too thoguh
15:56:51 <rhochmuth> imbko: right
15:57:19 <rhochmuth> ok, bye everyone
15:57:52 <rhochmuth> #endmeeting