15:00:17 <rhochmuth> #startmeeting monasca
15:00:17 <openstack> Meeting started Wed Nov 25 15:00:17 2015 UTC and is due to finish in 60 minutes.  The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:22 <openstack> The meeting name has been set to 'monasca'
15:00:22 <rhochmuth> o/
15:00:27 <slaweq_work> bye
15:00:33 <mroderus> o/
15:00:35 <njohnston> thanks all
15:00:43 <bklei_> o/
15:00:48 <witek> hello
15:00:53 <bmotz> o/
15:00:54 <bklei_> hola
15:01:17 <rhochmuth> hi everyone
15:01:24 <bklei_> happy turkey day
15:01:36 <rhochmuth> i'm supposed to be off this week, but i failed in that endeavor again
15:01:44 <bklei_> rats
15:02:15 <rhochmuth> so, i haven't really been responding to emails, and not been doing review
15:02:23 <rhochmuth> or writing code
15:02:33 <rhochmuth> but i'm here
15:02:46 <mroderus> good to read you again :)
15:02:55 <rhochmuth> so, we might as well get started
15:03:13 <rhochmuth> There is a review at, https://review.openstack.org/244483
15:03:36 <witek> thats mine
15:03:47 <rhochmuth> i started to take a look at this last week
15:03:51 <rhochmuth> it looks fine to me
15:03:59 <witek> nice
15:04:02 <rhochmuth> the only reason i haven't merged is test
15:04:12 <rhochmuth> just trying to verify all is good
15:04:19 <rhochmuth> i won't get to it this week
15:04:23 <witek> ok
15:04:44 <rhochmuth> i asked for some help from my team, but obviousely know one else looked at it either
15:04:47 <rhochmuth> so, sorry
15:05:02 <rhochmuth> the bottlneck is just verification
15:05:09 <rhochmuth> that everything still works
15:05:36 <witek> i wanted to push log management into monasca-vagrant
15:05:44 <witek> and it blocks a little
15:05:55 <rhochmuth> unless someone else looks at it, then we'll just have to wait a little longer
15:06:26 <rhochmuth> so the log-api in monasca-vagrant would be another area
15:06:43 <rhochmuth> so, are you blocked on https://review.openstack.org/244483
15:07:01 <rhochmuth> before you want to proceed adding the logging support?
15:07:11 <witek> yes, but I want to sync our ansible roles
15:07:32 <rhochmuth> the only other option is to do the merges and hope for the best
15:08:00 <rhochmuth> i would prefer not doign that
15:08:12 <witek> it's fine
15:08:31 <rhochmuth> so, there changes to three ansible roles and then the monasca-vagrant changes
15:08:48 <witek> that's right
15:08:56 <rhochmuth> are you ok waiting a little longer
15:09:15 <witek> how little is little? :)
15:09:26 <rhochmuth> epsilon
15:09:34 <witek> :)
15:09:39 <witek> it's ok
15:09:52 <rhochmuth> i'll see what i can get done in the background
15:10:04 <rhochmuth> but early next week is what i would target
15:10:10 <witek> great
15:10:35 <rhochmuth> THen there is, https://review.openstack.org/#/c/241626/
15:10:52 <bklei_> that's me
15:11:00 <bklei_> it's beautiful, no?
15:11:04 <rhochmuth> so, it all looks ready to go
15:11:08 <rhochmuth> i think it is the same issue
15:11:12 <rhochmuth> test/verification
15:11:30 <bklei_> yeah, tests well on my side, but would like others to confirm
15:12:04 <rhochmuth> i think it will be similar situation
15:12:14 <rhochmuth> waiting for more folks to look at it
15:12:15 <bklei_> the good news is, if the new code is broken (don't think it is), only affects if you pass the new parms
15:12:33 <rhochmuth> yes, seems like low risk change
15:12:47 <rhochmuth> as in adds new capabilities, but doesn't impact existing functionality
15:13:02 <bklei_> yeah
15:13:09 <rhochmuth> so, i'll probably get to this on monday/tuesday too
15:13:13 <bklei_> bueno
15:13:23 <rhochmuth> hoping someone else looks at this too
15:13:37 <bklei_> any volunteers?
15:14:09 <bklei_> for the influxdb side of the house, java/python, devstack works well to test
15:14:18 <bklei_> vertica is a bit more complicated
15:14:51 <bklei_> crickets/tumbleweeds
15:14:58 <rhochmuth> ok, next topic
15:14:59 <rhochmuth> Any update on cache fix?
15:15:03 <tomasztrebski> i'd look at this, but I am pretty much blocked by other stuff and this is my recent job...exclusively, I was looking at your change by only looking at the code
15:15:19 <rhochmuth> thanks tomasz
15:15:20 <bklei_> sure, thx tomasztrebski
15:15:20 <tomasztrebski> no chance to do something more for any other change
15:15:36 <bklei_> understood, we're all in that boat
15:15:59 <tomasztrebski> hopefully I see a light in that tunnel and maybe I will get a time to finally do my review-part properly
15:16:21 <rhochmuth> So, I don't have any updates on the cache fix
15:16:27 <rhochmuth> I started writing code last week
15:16:41 <bklei_> that's progress
15:16:48 <rhochmuth> but then was basically inundated with impromtu meetings for 3 days that pretty much killed me
15:17:13 <rhochmuth> i'm a little concerned now with the remainder of Decmber
15:17:20 <rhochmuth> i didn't take any time off all year
15:17:22 <bklei_> yeah, we're doing a datacenter migration, taking 95% of my time instead of wonderful monasca work
15:17:27 <rhochmuth> and now i'm trying to catch-up
15:17:41 <bklei_> better keep that wife happy
15:17:45 <rhochmuth> so, my development time is low
15:18:02 <rhochmuth> rigt now
15:18:29 <rhochmuth> anyway, i'll probably get to this next week too, but i'm not expecting to complete next week
15:18:40 <bklei_> ok, thx for setting expectations
15:19:08 <rhochmuth> Update for pymysql
15:19:21 <rhochmuth> @topic Update for pymysql
15:19:26 <rhochmuth> #topic Update for pymysql
15:19:32 <witek> we are testing the replacement
15:19:39 <rhochmuth> awesome
15:19:44 <witek> and it seems to be straight forward
15:19:58 <rhochmuth> is a drop-in replacement?
15:20:03 <witek> yes
15:20:14 <tomasztrebski> implementing was quite fast, our colleague needed..what..2 days, I guess
15:20:46 <tomasztrebski> along with some testing he's been doing in parallel with mysql
15:20:57 <rhochmuth> so, we did all this work a few months ago for postgres support and hibernate
15:21:26 <rhochmuth> are we goign to need to do somethign similar for the monasca-api
15:21:37 <witek> we would like to
15:21:59 <tomasztrebski> that's another brick actually, completely seperate...we agreed to provide pymysql as replacement so that's the first task to complete
15:22:11 <tomasztrebski> doing hibernate-like stuff and postgres would be next step
15:22:11 <rhochmuth> i see
15:22:32 <rhochmuth> so, possibly adding support for sqlalchemy in the python monasca-api
15:23:03 <tomasztrebski> that's what we have in mind
15:23:13 <rhochmuth> i think everything else is covered
15:23:22 <rhochmuth> python monasca-notification was already converted/added
15:23:30 <rhochmuth> monasca-persister doesn't use mysql
15:23:40 <rhochmuth> all the java code was converted
15:23:43 <witek> monasca-common
15:24:05 <rhochmuth> oh yeah
15:24:06 <rhochmuth> that too
15:24:46 <rhochmuth> so i don't see any problems objections to pymysql
15:25:05 <witek> cool, we'll push the change to review
15:25:23 <rhochmuth> ok, thanks
15:25:44 <rhochmuth> #topic  How does tempest know URL of monasca api ?
15:25:45 <witek> we also started working on sqlalchemy
15:26:10 <rhochmuth> thank witek
15:26:21 <rhochmuth> changed topics a bit soon
15:26:50 <rhochmuth> Not sure who asked the question about the Tempest tests
15:26:54 <witek> i'm finished :)
15:27:06 <tomasztrebski> yeah, so that's a question from me...basically I am trying to port log-api tempests to be with the project, and apart from normal issues with first try of new framework
15:27:40 <tomasztrebski> i am a little bit puzzled, where's the information where to look monasca-api server written ?
15:27:48 <rhochmuth> so, the monasca-api registers with keystone
15:28:22 <rhochmuth> there is a file called, ./etc/tempest.conf
15:28:37 <rhochmuth> that has the endpoint information and credentials
15:28:42 <rhochmuth> for keystone
15:28:59 <tomasztrebski> yes, I am looking at it right now
15:29:17 <rhochmuth> Have you seen the directions at, https://github.com/openstack/monasca-api/tree/master/monasca_tempest_tests
15:29:23 <tomasztrebski> and there is services available configuration property in file...config.py, isn't ?
15:29:43 <rhochmuth> hmm, i don't know anything about config.py
15:29:44 <tomasztrebski> yeah, I am basically trying to follow up your setup, because it works
15:30:17 <tomasztrebski> https://github.com/openstack/monasca-api/blob/master/monasca_tempest_tests/config.py#L21
15:30:22 <tomasztrebski> I am talking about that
15:31:02 <rhochmuth> that looks familiar now, i think i wrote that
15:31:32 <rhochmuth> so, for the log api there would be a similar skeleton
15:31:54 <rhochmuth> one possiblity is to create monasca_log_tempest tests in the monasca-log-api repo
15:32:06 <rhochmuth> and then copy/past the code and modify
15:32:42 <tomasztrebski> ok, that clears things a bit, guess I need to understand that to make it work, but I will follow up your suggestion, seems actually so good that I am astonished that I didn't think of it before
15:32:48 <tomasztrebski> :/
15:33:14 <tomasztrebski> ok, in case of any problems I will probably ask over mail or something like that
15:33:23 <tomasztrebski> I dont want to spent too much time over this topic
15:33:26 <rhochmuth> well, i think it makes sense to have the log api with it's own tempest tests
15:33:26 <tomasztrebski> thanks for your help
15:33:45 <rhochmuth> the other option is to add to the monasca-api directly
15:33:47 <tomasztrebski> it makes perfect sense that's why I am trying to embrace that stuff ;)
15:34:10 <rhochmuth> but, then we start mixing things together
15:34:20 <tomasztrebski> but that does not seem right, after all it was decided some time ago to keep those API seperate
15:34:25 <tomasztrebski> and for me it was good decision
15:34:30 <rhochmuth> ok, well, let me know if you run into any problems
15:34:34 <rhochmuth> i'm not an expert
15:34:40 <tomasztrebski> I hope not, but thx ;)
15:34:49 <rhochmuth> but i did do the original work in that area so might know a little more
15:35:19 <rhochmuth> i heavaily modeled on manila as they seemed to have a really good model
15:35:58 <rhochmuth> ok, next topi
15:36:04 <rhochmuth> #topic Summit videos + slides on Wiki page
15:36:11 <mroderus> that's mine
15:36:20 <rhochmuth> Sounds like a great idea
15:36:27 <rhochmuth> someone was wasking me about that yesterday
15:36:32 <mroderus> I was just wondering if we should add the video links and pdfs on the wiki page
15:36:45 <rhochmuth> yes, i agree
15:36:45 <mroderus> do I have permissions to do that?
15:36:50 <rhochmuth> you should
15:36:59 <mroderus> ok, so I'll put my stuff online
15:37:00 <rhochmuth> i don't know what the permissions on wiki pages are
15:37:13 <rhochmuth> i think anyone can modify
15:37:13 <mroderus> I'll try. If I run into problems I'll ask by email
15:37:22 <rhochmuth> ok, thanks
15:37:44 <mroderus> Fabio is not here today, right? So I'll ping him by email so he also uploads his presentation
15:38:13 <rhochmuth> correct, no fabio
15:38:22 <mroderus> that's all from me
15:38:31 <rhochmuth> ok
15:38:36 <rhochmuth> #topic https://review.openstack.org/#/c/226733/
15:39:29 <rhochmuth> tomasz i'm guessing you want a +2
15:39:40 <rhochmuth> i see deklan +2'd yesterday
15:39:44 <tomasztrebski> yeap, again me...I hope that now that should be finished and it should have higher chance of acceptance
15:40:28 <rhochmuth> i'll take a quick look and +2 unless i see anything
15:40:35 <rhochmuth> i'm assuming deklan tested well
15:40:50 <tomasztrebski> well, I'd love that +2, however to be fair, I dont know what to think about new gate for tempests, that's another reason why I wanted to bring this topic
15:41:06 <rhochmuth> ok
15:41:10 <tomasztrebski> I assume that gate is experimental, so failure there should not be a reason to worry ?
15:41:32 <rhochmuth> uhhh, the gates are marked as experimental
15:41:44 <rhochmuth> but, we are closing in on 100% passing
15:41:56 <rhochmuth> right now, the last i checked, there were only 5 tests failing
15:41:59 <rhochmuth> as of last night
15:42:04 <rhochmuth> this is against the python api
15:42:10 <rhochmuth> the java api should be completley passing
15:42:20 <tomasztrebski> ok, so please review that and in case of unclear parts just leave a comment
15:42:33 <tomasztrebski> let's hope it does
15:42:40 <rhochmuth> ok
15:43:08 <rhochmuth> ahhh, yes i see at the bottom of the review the failure
15:43:14 <rhochmuth> everyone is getting that right now
15:43:17 <rhochmuth> so, that isn't a problem
15:43:35 <rhochmuth> unless all of a sudden something was failing that was passing previousel
15:43:43 <rhochmuth> it would be difficult for you to know that right now
15:43:54 <rhochmuth> pretty soon, we should be at 100%
15:44:29 <rhochmuth> then we will change from experimental to checks, but not voting i beleive
15:44:34 <rhochmuth> then it will be clearer
15:44:40 <tomasztrebski> ok, I will prepare some fireworks
15:44:41 <tomasztrebski> :)
15:44:45 <rhochmuth> so, no cause to panic
15:45:20 <rhochmuth> ok, moving on
15:45:24 <rhochmuth> #topic Quota status
15:45:33 <mroderus> That's me again. I remember we had some discussions about quotas in Monasca some weeks ago. It was brought up by bklei_ . I was just curious if there have been any actions around this topic during the last weeks
15:45:54 <rhochmuth> There haven't been any actions
15:46:14 <rhochmuth> We should possibly get a blueprint to work on this
15:46:51 <bklei_> i'd love to see that topic move fwd
15:47:01 <mroderus> ok thanks. May be that this will become a topic at Fujitsu as well in the next months
15:47:16 <rhochmuth> Yes, it is important for doing tru monitoring as a service
15:47:26 <rhochmuth> on public cloud endpoints
15:47:28 <bklei_> if you start a blueprint mroderus, i'll help add my thoughts
15:47:47 <mroderus> right. I think that's a fundamental requirement for a monitoring cloud service
15:48:06 <bklei_> from our perspective, one quota we'd like to see is data retention period (per project)
15:48:09 <mroderus> ok bklei_ . I'll ping you as soon as we start working on this
15:48:16 <bklei_> great
15:48:45 <rhochmuth> we might need to get started on that soon too
15:48:53 <mroderus> bklei_: so you mean a maximum time the data is stored, right?
15:48:58 <rhochmuth> we had some requests around this recently
15:49:07 <bklei_> right -- per project is what we need
15:49:13 <bklei_> (keystone project/tenant)
15:49:30 <mroderus> have you also discussed  volume-based quotas?
15:49:44 <bklei_> even if the API just tracked what it is, we could just consume that and do what we will with it for starts
15:49:49 <mroderus> such as number of metrics or  megabytes
15:50:00 <bklei_> i'm just thinking time
15:50:13 <bklei_> we'll probably default to 6 weeks or something
15:50:23 <bklei_> could be fancier, but that'd get us started
15:50:34 <rhochmuth> we also need quotas on number of alarms
15:50:48 <bklei_> yeah, that could spiral
15:50:49 <mroderus> rhochmuth: right
15:51:08 <rhochmuth> and in addition to time/retention period on metrics, probably the number of metrics too
15:51:45 <rhochmuth> number of notification methods, …
15:51:51 <mroderus> I'm just worrying that time/project may not be enought. A project may have an infinite number of agents sending at an arbitrary fine resolution
15:51:54 <mroderus> (theoretically)
15:51:58 <bklei_> custom metrics i'd assume, ignoring libvirt?
15:52:28 <bklei_> we already have quota mgmt for # of instances
15:52:36 <mroderus> ok
15:52:50 <mroderus> is that already in Monasca?
15:52:56 <bklei_> it's in nova
15:53:04 <bklei_> nova quota-show
15:53:10 <bklei_> or something like that
15:53:58 <bklei_> i'm just saying, since openstack already has a mechanism for capping # of instances, we shouldn't cap the default libvirt metrics
15:54:06 <mroderus> ah, ok.. so that quota is for the provisioned VMs. But apart from this, a user can additionally install agents and post metrics to the API. Is that considered as well?
15:54:36 <bklei_> exactly, if we add quotas for # of metrics, should likely be 'custom' metrics they POST, not the default metrics
15:54:59 <mroderus> right, makes sense
15:55:22 <bklei_> thx for working on this mroderus
15:55:38 <mroderus> bklei_: thanks back to you
15:55:57 <rhochmuth> i just wanted to point out that we have a blueprint
15:55:59 <rhochmuth> https://blueprints.launchpad.net/monasca/+spec/alarm-count-resource
15:56:06 <rhochmuth> https://wiki.openstack.org/wiki/Monasca/UI_UX_Support#Alarm_Counts_Resource
15:56:16 <mroderus> cool
15:56:18 <rhochmuth> we had a number of requests from our UI team
15:56:35 <bklei_> cool
15:56:41 <rhochmuth> to to server side filtering, sorting/ordering, and return summaries for alarms
15:56:54 <rhochmuth> this blueprint is from the summary of counts of alarms
15:56:56 <bklei_> nice, would like to see that ui
15:57:11 <rhochmuth> the ui is in helion
15:57:17 <rhochmuth> called opsconsole
15:57:20 <bklei_> i know :)
15:57:42 <bklei_> rbak is our UI team :)
15:57:56 <rbak> thanks
15:58:16 <rhochmuth> the general idea for alarms counts resource to ti return the total alarms, and alarms in various states of ALARM, ACKNOWLEDGED, …
15:58:26 <rhochmuth> so, it would be good to take a look at that
15:58:41 <rhochmuth> we're also going to have blueprints for ordering/storing better
15:58:58 <bklei_> gonna be a busy 2016
15:59:07 <rhochmuth> i believe fujitsu had a bluepring for ordering/sotring too, so we might end-up adding to yours
15:59:26 <rhochmuth> anyway, just wanted to point out that we've started on this
15:59:41 <mroderus> uh.. honestly speaking I'm not aware of anything. But that doesn't mean much :)
15:59:42 <rhochmuth> rbrandt is the engineeer working on that
15:59:57 <rhochmuth> ok, looks like we are done
16:00:04 <tomasztrebski> yeah, that blueprint you're talking about was done some time ago
16:00:05 <tomasztrebski> ;)
16:00:26 <rhochmuth> need to end the meeting folks
16:00:29 <rhochmuth> see you next week
16:00:32 <mroderus> ok.. bye!
16:00:35 <bklei_> bye
16:00:42 <witek> thanx, bye
16:00:43 <tomasztrebski> bye
16:00:50 <rhochmuth> #endmeeting