15:00:43 <rhochmuth> #startmeeting monasca
15:00:44 <openstack> Meeting started Wed Dec  9 15:00:43 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:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:47 <openstack> The meeting name has been set to 'monasca'
15:00:58 <rhochmuth> o/
15:01:03 <tomasztrebski> o/
15:01:06 <witek> hello
15:01:09 <bklei> o/
15:01:17 <rbak> o/
15:01:24 <rhochmuth> Agenda is at, https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:01:31 <shinya_kwbt> o/
15:01:32 <rhochmuth> Agenda for Wednesday December 09, 2015 (15:00 UTC)
15:01:32 <rhochmuth> 1. InfluxDB plugin for Agent (jobrs)
15:01:32 <rhochmuth> 1.1 https://review.openstack.org/#/c/196167/
15:01:32 <rhochmuth> 2. Less restrictive e-mail address check for notifications (javax.mail replacing apache-commons validation)
15:01:33 <rhochmuth> 2.1 https://bugs.launchpad.net/monasca/+bug/1501239 --> https://review.openstack.org/#/c/254643/
15:01:33 <openstack> Launchpad bug 1501239 in Monasca "Create Notification UI does not accept email addresses ending with .corp " [Undecided,Triaged]
15:01:33 <rhochmuth> 3. TWC reviews/pull requests:
15:01:33 <rhochmuth> 3.1 https://review.openstack.org/#/c/241626/
15:01:33 <rhochmuth> 3.2 https://review.openstack.org/#/c/254842/
15:01:33 <rhochmuth> 3.3 https://github.com/hpcloud-mon/grafana/pull/16
15:01:34 <rhochmuth> 4. Alarms on logs
15:01:39 <rhochmuth> hi everyone
15:01:52 <ddieterly> o/
15:02:12 <rhochmuth> so, irc went out last week in the middle of the meeting
15:02:27 <tgraichen> o/
15:02:38 <rhochmuth> i think we have a couple of items to carry over from last week
15:03:15 <rhochmuth> #topic InfluxDB plugin for Agent (jobrs)
15:03:25 <rhochmuth> hi jobrs
15:03:28 <jobrs> hi
15:03:41 <jobrs> so where should I continue?
15:03:44 <rhochmuth> you've done some work in completing the monitoring of influxdb
15:04:01 <rhochmuth> well, i don't think we discussed you review at all
15:04:13 <rhochmuth> so, how about anything that we should know
15:04:25 <rhochmuth> related to arch, design, coding, …, would be good
15:04:38 <rhochmuth> i just took a quick look this morning at the review
15:04:50 <rhochmuth> is this ready for final review
15:04:59 <jobrs> arch and design are a tricky topic: currently the plugin leaves some room for improvement
15:05:11 <mroderus> o/
15:05:26 <rhochmuth> ok, what would you suggest
15:05:34 <jobrs> no, I took this code over since there was no progress. And now I see that I should do some more refactorings.
15:05:57 <rhochmuth> ok, we would definitely love to see the work completed
15:05:58 <jobrs> the topic I wanted to discuss first is the topic of naming metrics and dimensions properly.
15:06:03 <rhochmuth> ahh
15:06:04 <rhochmuth> ok
15:06:32 <jobrs> since this was where the progress stopped before I took over
15:06:38 <rhochmuth> ok
15:06:53 <rhochmuth> i think a metric name with a prefix of influxdb.
15:06:59 <rhochmuth> is a good start for a name
15:07:22 <rhochmuth> service, by default would be "influxdb" which is redundant
15:07:26 <rhochmuth> with the metric name
15:07:31 <rhochmuth> but we've done that elsewher
15:07:42 <jobrs> was this all about it? that was not clear from the discussion in the change
15:08:13 <rhochmuth> then the component would be "influxd" I believe, not influxdb
15:08:48 <rhochmuth> i think influxd instead of influxdb, as the process name is influxd
15:08:54 <jobrs> so this is what I did (see protocol from last meeting): set component to "influxdb", leave service alone
15:09:07 <jobrs> influxd IMHO is process_name
15:09:08 <fabiog> hi, sorry I am late ..
15:09:36 <tomasztrebski> that's pretty much a daemon in the system as far as I know
15:09:37 <jobrs> other than that I removed all that suffixes like cnt.curr from the metric names
15:09:48 <tomasztrebski> project, component or whatsoever is influxdb in my opinion
15:09:50 <rhochmuth> yeah, the convention we've been following is the component would be "influxd"
15:10:12 <jobrs> and changed from camel-case names to lower case with _
15:10:19 <rhochmuth> correct
15:10:23 <rhochmuth> on the camel case
15:10:56 <rhochmuth> i was about to type in the case of mysql
15:11:08 <rhochmuth> metric prefix is "mysql."
15:11:14 <rhochmuth> service = "mysql"
15:11:21 <rhochmuth> component = "mysqld"
15:11:44 <jobrs> component, no service - otherwise we have no place for "monitoring"
15:12:14 <jobrs> this is consistent with the other monasca components (even though they are technically speaking services somehow)
15:12:21 <rhochmuth> well, i'll need to check on this, since i forgot, but i think we supply a service name like "mysql"
15:12:34 <rhochmuth> but then we overrid the serice name if it is part of a service
15:12:52 <rhochmuth> so, if influxdb is just part of monitoring, then you woudl override serivce=monitoring
15:13:05 <rhochmuth> For example, mysql is a shared service
15:13:13 <rhochmuth> so we assing service=mysql in that case
15:13:26 <jobrs> yep, when I install mysql for monasca then I tell the agent that the mysql is for service 'monitoring'
15:13:33 <rhochmuth> However, if you deployed a specific instance of mysql for monitoring, then service=monitoring
15:13:58 <jobrs> agreed, but this is something the detection cannot possibly know
15:14:17 <jobrs> therefore I leave the service-slot empty and use component for that purpose.
15:14:23 <rhochmuth> when you run the detection you can supply overrides
15:15:04 <rhochmuth> i would just take a look at mysql or rabbitmq to understand what we are doing in there
15:15:25 <rhochmuth> and follow the same precedent
15:15:28 <rhochmuth> whatever it is
15:15:31 <jobrs> makes sense, I just think that there should be some consistency here and I took mon.py as a reference
15:15:33 <rhochmuth> yeah, i should know this
15:15:51 <jobrs> let's follow up in the change
15:15:54 <rhochmuth> ok
15:16:03 <rhochmuth> i'll also review your change the the code that is there
15:16:28 <rhochmuth> #topic Less restrictive e-mail address check for notifications (javax.mail replacing apache-commons validation)
15:17:15 <jobrs> so here apache-commons validation has an issue: it is based on hard-coded whitelists of TLDs.
15:17:49 <jobrs> IMHO this is not 'sustainable' since you have to change the software every time ICANN comes up with a new TLD
15:18:14 <rhochmuth> ok, can't say i have an appreciation for this topic
15:18:22 <jobrs> as an alternative I picked javax.mail, since it focuses on syntax
15:18:59 <rhochmuth> so, you are basically just replacing the email validator with somehting that is more correct
15:19:03 <jobrs> it's a show-stopper for us (sap)
15:19:17 <rhochmuth> ok, i don't see any problems with adding it
15:19:50 <jobrs> javax.mail is Java EE, not sure whether this could mean licensing issues
15:19:50 <rhochmuth> Currently, Jenkins has -1
15:20:03 <rhochmuth> on pep8 failures
15:20:13 <rhochmuth> for you java code
15:20:15 <jobrs> yep, because of python code - but python code is not part of the change
15:20:46 <rhochmuth> so, i'm not sure what the issue is, but will need to dive into the console log
15:20:54 <rhochmuth> have you done that before
15:21:15 <jobrs> sorry, no, I was not aware that pep8 processes Java files
15:21:38 <rhochmuth> no, i was just kidding about the pep8 on java
15:21:59 <rhochmuth> here is the problem
15:22:01 <rhochmuth> http://logs.openstack.org/43/254643/3/check/gate-monasca-api-pep8/c66c6bf/console.html#_2015-12-08_19_15_20_724 | pep8 runtests: commands[0] | flake8 monasca_api
15:22:01 <rhochmuth> http://logs.openstack.org/43/254643/3/check/gate-monasca-api-pep8/c66c6bf/console.html#_2015-12-08_19_15_20_725 |   /home/jenkins/workspace/gate-monasca-api-pep8$ /home/jenkins/workspace/gate-monasca-api-pep8/.tox/pep8/bin/flake8 monasca_api
15:22:01 <rhochmuth> http://logs.openstack.org/43/254643/3/check/gate-monasca-api-pep8/c66c6bf/console.html#_2015-12-08_19_15_23_018 | monasca_api/__init__.py:1:1: H802  git commit title ('stop checking e-mail addresses against outdated whitelists by replacing the apache-commons which works with hard-coded whitelists with javax.mail validation.') should be under 50 chars
15:22:01 <rhochmuth> http://logs.openstack.org/43/254643/3/check/gate-monasca-api-pep8/c66c6bf/console.html#_2015-12-08_19_15_23_018 |
15:22:01 <rhochmuth> http://logs.openstack.org/43/254643/3/check/gate-monasca-api-pep8/c66c6bf/console.html#_2015-12-08_19_15_23_018 | ^
15:22:01 <rhochmuth> http://logs.openstack.org/43/254643/3/check/gate-monasca-api-pep8/c66c6bf/console.html#_2015-12-08_19_15_23_018 | monasca_api/__init__.py:1:1: H803  git commit title ('stop checking e-mail addresses against outdated whitelists by replacing the apache-commons which works with hard-coded whitelists with javax.mail validation.') should not end with period
15:22:01 <rhochmuth> http://logs.openstack.org/43/254643/3/check/gate-monasca-api-pep8/c66c6bf/console.html#_2015-12-08_19_15_23_018 |
15:22:02 <rhochmuth> http://logs.openstack.org/43/254643/3/check/gate-monasca-api-pep8/c66c6bf/console.html#_2015-12-08_19_15_23_018 | ^
15:22:02 <rhochmuth> http://logs.openstack.org/43/254643/3/check/gate-monasca-api-pep8/c66c6bf/console.html#_2015-12-08_19_15_23_099 | ERROR: InvocationError: '/home/jenkins/workspace/gate-monasca-api-pep8/.tox/pep8/bin/flake8 monasca_api'
15:22:18 <jobrs> it's the commit title
15:22:25 <jobrs> I will fix that
15:22:29 <rhochmuth> yeah
15:22:35 <rhochmuth> that's it
15:22:59 <jobrs> next topic I would say
15:23:03 <rhochmuth> ok, so i'm assuming everyone is ok with that change
15:23:08 <rhochmuth> reviewers will take a look
15:23:24 <rhochmuth> #topic TWC reviews/pull requests:
15:23:28 <jobrs> that would be good
15:23:34 <rhochmuth> https://review.openstack.org/#/c/241626/
15:23:38 <bklei> that's me
15:23:58 <rhochmuth> you always act surprised
15:24:16 <rhochmuth> so, i was testing last night, mainly the vertica code
15:24:24 <bklei> i see deklan had a comment on the big one -- deklan, you want those issues address in this change?
15:24:37 <bklei> transactional comment i'm not sure how to address
15:24:49 <ddieterly> i think we should make it one transaction
15:24:54 <ddieterly> that's an easy fix
15:25:07 <ddieterly> i think that the close issue should be addressed in another change
15:25:12 <bklei> can you point me to an example?  it's not clear to me.
15:25:23 <bklei> yeah, i can open a bug and put a separate change up for the close
15:25:29 <ddieterly> just pass the handle to the function for the second sql query
15:25:35 <bklei> oh, duh.
15:25:39 <bklei> will change that
15:25:56 <ddieterly> cool
15:26:03 <bklei> rhochmuth -- testing vertica going ok?
15:26:14 <rhochmuth> well, i sent you an email
15:26:18 <bklei> oh
15:26:19 <ddieterly> not sure why we did not see resource problems because of the open handles that we are not closing
15:26:19 <rhochmuth> i think i sent one anyway
15:26:35 <bklei> don't see one, but outlook can be flaky
15:26:43 <rhochmuth> i wasn't positive that the end_time was using the right time zone
15:27:26 <rhochmuth> when i didn't supply a time zone, i got the correct results
15:27:40 <rhochmuth> bu i thought my end_time was looking like it had to be 8 hours in the future
15:27:56 <rhochmuth> so, i'll just need to take a look some more
15:28:04 <rhochmuth> it could jsut be my environment or tester error
15:28:13 <rhochmuth> as i stepped through all the code and all looked ok
15:28:16 <bklei> ok, if it's an issue here, it's probably an issue in measurements/statistics too
15:28:34 <rhochmuth> well, that was also strange
15:28:49 <rhochmuth> the measuremnts/statistics was returning what i expected
15:29:04 <rhochmuth> i'll just take another look then
15:29:11 <bklei> that's strange, i thought i handled the parms the same
15:29:12 <bklei> ok
15:29:24 <bklei> i'll push a patch for the transactional change this morning
15:29:26 <rhochmuth> other than that, it all looked good to me and i didn't catch any other issues
15:29:52 <rhochmuth> https://review.openstack.org/#/c/254842/
15:29:53 <bklei> there's two other changes that will take advantage of the big change
15:30:00 <bklei> yeah, python client
15:30:13 <bklei> i think that one is ok?  have some +1's
15:30:23 <rhochmuth> yup
15:30:26 <rhochmuth> looks good
15:30:45 <bklei> cool
15:30:49 <rhochmuth> https://github.com/hpcloud-mon/grafana/pull/16
15:30:57 <rhochmuth> a pull request for grafana
15:31:03 <bklei> yeah, that just lets the UI pass start time
15:31:22 <bklei> really speeds up some dashboards here, without merge flag
15:31:37 <bklei> when you have stale metrics for a project
15:31:46 <bklei> like deleted vms, etc
15:31:57 <rhochmuth> so, the start_time is determined buy the grafana time panel
15:32:01 <bklei> yeah
15:32:13 <rhochmuth> ok, is there anyone that can test this
15:32:22 <rhochmuth> i probably don't get to this one
15:32:34 <rhochmuth> code looks fine though
15:32:51 <rhochmuth> i could just merge and trust you
15:32:52 <bklei> i tested it by watching the javascript console, and monasca-api log on the back end to see metric-list come through with start time parm
15:33:28 <bklei> up to you, i feel good about it, but i'm an optimist :)
15:33:42 <rhochmuth> i'm a
15:33:44 <rhochmuth> never mind
15:33:49 <bklei> :)
15:34:16 <rhochmuth> #topic Alarms on logs
15:34:23 <mroderus> that's me
15:34:40 <mroderus> we've had a couple of previous discussions on this topic
15:34:47 <mroderus> last time was in Tokyo at the team meeting
15:35:25 <mroderus> rhochmuth: I remember you made a proposal how we can implement a very simple alarming mechanism on logs without having to invoke StackTach
15:35:29 <mroderus> do you remember?
15:35:58 <rhochmuth> i'm assuming that you are talking about using the purely logstash based approach
15:36:09 <mroderus> exactly
15:36:20 <rhochmuth> yes, we are interested in that
15:36:38 <rhochmuth> because the CEP is still lacking progress
15:36:59 <mroderus> Logstash is there to produce single, discret events from single log entries
15:37:11 <mroderus> in this case I suppose that would already be a metric
15:37:18 <rhochmuth> right, it is not stateful
15:37:38 <mroderus> I was just wondering how the threshold engine can process these kind of events/metrics
15:37:39 <rhochmuth> so, you can generate metrics when an error occurs in your log file
15:38:06 <rhochmuth> you can create alarms that use the "count" function
15:38:08 <mroderus> right, that could be a metric e.g. for an error level
15:38:13 <rhochmuth> correct
15:38:31 <rhochmuth> one problem is that the threshold engine requires periodic metrics
15:38:42 <rhochmuth> but, log files would result in non-periodic errors
15:38:50 <rhochmuth> for example, if there were no errors
15:39:00 <rhochmuth> then maybe, there wouldn't be any metrics sent
15:39:08 <ddieterly> bklei: http://jdbi.org/dbi_handle_and_statement/
15:39:19 <rhochmuth> so, we probably also need to add support for something we cal non-periodic metrics
15:39:28 <mroderus> ok, understand. So Logstash would have to create a metric (e.g. 0 := OK) regularly
15:39:42 <rhochmuth> no, i wouldn't do it there
15:39:46 <bklei> thx ddieterly, will push a patch for that
15:39:52 <mroderus> otherwise the state in Monasca would turn to "undefined"
15:39:59 <rhochmuth> i would modify the threshold engine to not go into the undetermined state if there are no metrics
15:40:27 <mroderus> but that would be only for distinct metrics. In other cases, "undefined" makes sense
15:40:28 <ddieterly> bklei: for every db open, there needs to be a close in a finally clause
15:40:41 <rhochmuth> right
15:40:50 <bklei> yup, check for null and close in a finally
15:41:23 <mroderus> ok, I think that's enough info for me (for now)
15:41:28 <ddieterly> yea, amazing that we missed that
15:41:28 <ChristianB> does that mean thresh is stateful?
15:41:37 <mroderus> Fujitsu-guys: any more questions on this?
15:41:40 <rhochmuth> thresh is stateful
15:42:26 <tomasztrebski> no, I dont think so
15:42:53 <ChristianB> what do you think about a new component to analyse logs and create metrics?
15:42:55 <bklei> ddieterly https://bugs.launchpad.net/monasca/+bug/1524392 will track close issue
15:42:55 <openstack> Launchpad bug 1524392 in Monasca "monasca api and persister java code doesn't close any db connections" [Undecided,New] - Assigned to Bradley Klein (brad-klein)
15:42:56 <ddieterly> thresh is the mast stateful component we have besides the db
15:43:20 <ddieterly> bklei: thx
15:43:28 <bklei> np
15:43:36 <rhochmuth> ChristianB Are you asking me?
15:44:04 <ChristianB> yes
15:44:15 <Menger> 
15:44:19 <rhochmuth> so, what do you mean by a new component
15:44:30 <rhochmuth> we had talked about doing this in logstash
15:44:42 <rhochmuth> sounds like you are thinking outside of logstash
15:45:10 <rhochmuth> there is a huge amount to leverage in the logstash community
15:45:23 <ChristianB> well the transformer transforms...I think it is not the right place to do "analytics"
15:46:06 <rhochmuth> yeah, we were just trying to get by i think with something expedient
15:46:19 <rhochmuth> so, i would be interested in a more custom component
15:46:35 <mroderus> I also think we should leverage what's there
15:46:48 <tsv> +1
15:46:53 <rhochmuth> so, it really comes down to the use cases that you want to address
15:46:54 <mroderus> Logstash is very flexible and can be used for many use cases
15:47:01 <mroderus> at least for the first step
15:47:02 <rhochmuth> that wouldn't be covered by logstash
15:47:18 <rhochmuth> for example, handling state isn't easily done
15:47:22 <rhochmuth> from what i've seen so far
15:47:26 <rhochmuth> but i'm not an expert
15:48:00 <rhochmuth> So, who is saying farewell
15:48:04 <mroderus> so let's go with Logstash until we hit a wall
15:48:13 <mroderus> That'
15:48:16 <mroderus> That's me
15:48:20 <rhochmuth> and i also want to cover mid cycle and fabiog's topis
15:48:29 <rhochmuth> ohhh, is this your last meeting
15:48:33 <mroderus> this is probably the last time for me in this round
15:48:35 <mroderus> yes
15:48:45 <rhochmuth> well, it has been great working with you
15:48:50 <mroderus> so I just wanted to say goodbye and thanks for the great collab
15:49:01 <mroderus> rhochmuth: same with you
15:49:03 <ddieterly> mroderus: ciao
15:49:05 <rhochmuth> i wish you well in your new endeavor
15:49:12 <bklei> that's a bummer mroderus
15:49:15 <rhochmuth> and hope to stay in touch
15:49:16 <mroderus> thanks a lot
15:49:45 <mroderus> yeah, sorry. It wasn't an easy decision
15:50:00 <mroderus> So all the best to all of you and hope to see you!
15:50:00 <bklei> where are you off to?
15:50:07 <ddieterly> that's what everybody always says ;-)
15:50:16 <mroderus> but I mean it :)
15:51:25 <rhochmuth> so, i just wanted to check with fabiog
15:51:30 <rhochmuth> on topics
15:51:52 <rhochmuth> fabiog wanted to run a mid-cycle
15:52:01 <fabiog> rhochmuth: yes, we can
15:52:15 <rhochmuth> so, did you check with congress
15:52:20 <fabiog> rhochmuth: I will host the Congress one from Jan 26-29
15:52:34 <fabiog> rhochmuth: and there is one day dedicated to Monasca integration
15:52:42 <rhochmuth> an entire day
15:52:46 <rhochmuth> wow
15:52:49 <fabiog> rhochmuth: pretty much
15:53:11 <fabiog> rhochmuth: this is the tentative agenda for Congress
15:53:13 <fabiog> Tue Jan 26: Discussion with Monasca team about integration. - Intro to Congress (slides or whiteboard)  - Intro to Monasca (slides or whiteboard) - Design discussion - Prototyping  Wed Jan 27: Congress team code sprint for distributed arch  Thu Jan 28: Congress team design session for high availability and high throughput
15:53:39 <fabiog> rhochmuth: I can have the topic on Cognress moved to Thu
15:53:51 <fabiog> so we could have a Thu and Fri Monasca cycle
15:54:00 <fabiog> otherwise we can do the first week of Feb
15:54:04 <rhochmuth> i see, tues congress/monasca
15:54:09 <fabiog> and be separate from congress
15:54:18 <rhochmuth> actually i think i meant wed
15:54:27 <fabiog> rhochmuth: I can have that moved it Thu if more people from Monasca will come
15:54:48 <rhochmuth> so, this would be in san jose
15:55:00 <rhochmuth> can anyone else make those days
15:55:07 <rhochmuth> do we want to do a poll
15:55:23 <fabiog> I will send out a doodle in the mailing list for Jan 28/29 and for the first week of Feb
15:55:26 <fabiog> would that work?
15:55:32 <bklei> wfm
15:55:40 <rhochmuth> ok
15:55:45 <rhochmuth> what is wfm
15:55:46 <ddieterly> sure
15:55:49 <fabiog> then you guys can vote and at the beginning of Jan we decide if to have the mid-cycle or not
15:55:57 <bklei> wfm == works for me
15:56:01 <rhochmuth> ohhh
15:56:04 <rhochmuth> thanks
15:56:10 <rhochmuth> ok, sounds good
15:56:13 <rhochmuth> thanks fabio
15:56:32 <rhochmuth> anymore topics in closing
15:56:40 <fabiog> rhochmuth: np
15:56:52 <fabiog> btw, it will be at the Cisco Campus in San Jose California
15:56:56 * Menger slaps ChristianB around a bit with a large fishbot
15:57:15 <rhochmuth> ohhh, i did want to mention that the tempest tests are now gating monasca-api
15:57:29 <rhochmuth> we have 111 tests passing for both python and java
15:57:33 <bklei> awesome!
15:57:51 <rhochmuth> there might be a couple of tests that randmoly fail
15:57:54 <rhochmuth> due to timing
15:58:13 <rhochmuth> so, if you run into any problems, it might not be a code failure
15:58:23 <bklei> good to know
15:58:27 <rhochmuth> but we are closing those niggling issues still
15:58:48 <rhochmuth> ok, bye everyone
15:58:53 <ddieterly> ciao
15:58:56 <bklei> cya
15:59:18 <fabiog> http://doodle.com/poll/yy4unhffy7hi3x67
15:59:19 <witek> bye
15:59:25 <Menger> Good bye
15:59:25 <fabiog> I have the doodle set up
15:59:35 <rhochmuth> thanks fabio
15:59:37 <rhochmuth> that was fast
15:59:38 <fabiog> please choose
16:00:11 <rhochmuth> #endmeeting