15:00:22 <rhochmuth> #startmeeting monasca
15:00:23 <openstack> Meeting started Wed Mar  2 15:00:22 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:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:27 <openstack> The meeting name has been set to 'monasca'
15:00:29 <rhochmuth> o/
15:00:30 <rbak> o/
15:00:36 <bmotz> o/
15:00:48 <witek> hello
15:00:51 <bklei> o/
15:01:12 <rhochmuth> Agenda is at, https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:01:17 <rhochmuth> It is a little light right now.
15:01:21 <slogan_r> morning
15:01:24 <rhochmuth> Agenda for Wednesday March 2, 2016 (15:00 UTC)
15:01:24 <rhochmuth> 1.	Preperation for Austin Summit
15:01:24 <rhochmuth> 2.	java tempest tests / hibernate support
15:01:24 <rhochmuth> 3.	influxdb 0.10?
15:01:55 <rhochmuth> So, I would like to discuss the Austin Summit and prep for that
15:02:17 <rhochmuth> There is a request from the TC for rooms
15:02:24 <rhochmuth> room requests that is
15:02:28 <slogan_r> TC?
15:02:37 <rhochmuth> TC = Technical Committee
15:02:45 <slogan_r> ah
15:02:58 <rhochmuth> So, I would like to get back to them on room requests
15:03:11 <rhochmuth> How many folks are planning on being there?
15:03:29 <rhochmuth> And what topics would like to be discussed
15:03:37 <witek> me
15:03:53 <bklei> me
15:03:58 <rbak> I'll be there
15:04:27 <bmotz> I'll be there if our talk gets approved :)
15:04:31 <slogan_r> I should be there showing off the broadview stuff if that is sothing we could use a room for, then ok
15:04:45 <slogan_r> s/sothing/something
15:05:06 <rhochmuth> i was hoping to discuss anomaly detection and clustering more in-depth, but i'm not sure about attendance
15:05:31 <rhochmuth> how about two room slots
15:05:40 <rhochmuth> somewhere on the order of 2-3 hours
15:05:44 <witek> +1 for clustering
15:05:46 <rhochmuth> we can do general planning
15:05:54 <rhochmuth> presentations
15:06:17 <slogan_r> so, even if we don't get an approval for a talk, we can do the same in a room?
15:06:23 <witek> grafana?
15:06:52 <rhochmuth> yes, we can have a presentation/demo to the team Monasca team
15:07:07 <rhochmuth> on broadview lib and discussion on monitoring physical and vswitches
15:07:15 <rhochmuth> that is a topic i'm interested in
15:07:18 <slogan_r> perfect
15:07:37 <rhochmuth> but, it won't be a big audience presentation, unless i request a big room
15:07:57 <witek> how about joint sessions with congress or vitrage?
15:08:00 <slogan_r> better than nothing
15:08:09 <rhochmuth> Here are the options
15:08:10 <rhochmuth> * Fishbowl slots (Wed-Thu)
15:08:10 <rhochmuth> Our traditional largish rooms organized in fishbowl style, with
15:08:11 <rhochmuth> advertised session content on the summit schedule for increased external
15:08:11 <rhochmuth> participation. Ideal for when wider feedback is essential.
15:08:11 <rhochmuth> * Workroom slots (Tue-Thu)
15:08:11 <rhochmuth> Smaller rooms organized in boardroom style, with topic buried in the
15:08:12 <rhochmuth> session description, in an effort to limit attendance and not overcrowd
15:08:12 <rhochmuth> the room. Ideal to get work done and prioritize work in small teams.
15:08:13 <rhochmuth> * Contributors meetup (Fri)
15:08:14 <rhochmuth> Half-day session(s) on the Friday to get into the Newton action while
15:08:14 <rhochmuth> decisions and plans are still hot, or to finish discussions started
15:08:15 <rhochmuth> during the week, whatever works for you.
15:08:37 <rhochmuth> I'm not sure about the Fishbowl slot
15:09:07 <rhochmuth> but if we could get a Fishbowl slot, then that opens the door for presenting to a larger audience
15:09:09 <rhochmuth> i guess
15:09:20 <rhochmuth> Grafana would be a possiblity too
15:09:27 <rhochmuth> Logging
15:09:29 <rhochmuth> ...
15:09:45 <witek> sure
15:09:49 <rhochmuth> I think anything that didn't get in would possibly be an option for a fishbowl
15:09:55 <slogan_r> I'm guessing our marketing peeps would love the added messaging that goes with the fishbowl
15:09:57 <rhochmuth> if i understand
15:10:07 <rhochmuth> they would
15:10:17 <rhochmuth> but, i tend to ignore marketing
15:10:23 <rhochmuth> :-)
15:10:39 <slogan_r> I won't pass that one along :-P
15:10:51 <rhochmuth> don't worry, i'm already in trouble
15:10:57 <rhochmuth> with that crew
15:11:23 <rhochmuth> ok, i'll get 2-3 hours, with the possiblity for a fishbowl
15:11:27 <slogan_r> whatever you think is best, we'll be there
15:11:42 <rhochmuth> there is always the option for lot's of impromptu discussions
15:12:07 <rhochmuth> but if you want to drive something more formal around the topic of virtual/physical switch montioring that could powwibly fill an entire slot
15:12:32 <slogan_r> when do they announce who made it as a presentation?
15:12:55 <rhochmuth> Shoudl be real soon, but i don't know the offical date
15:13:09 <rhochmuth> Early March was what I read
15:13:09 <slogan_r> that would be the determination I think the need of a fishbowl
15:13:18 <slogan_r> yeah, that's what I heard too
15:13:20 <rhochmuth> yeah, i agree
15:13:31 <rhochmuth> Next topic?
15:13:49 <rhochmuth> This is a leftover from last week
15:13:57 <rhochmuth> #topic ava tempest tests / hibernate support
15:14:05 <rhochmuth> i'm guessing witek?
15:14:21 <witek> I'm working on synchronizing hibernate implementation in monasca-api
15:14:40 <witek> and thought of creating the new tempest gate for hibernate
15:14:47 <rhochmuth> That would be awesome
15:15:01 <witek> cool, I will push the change when ready
15:15:22 <rhochmuth> So, today we test Java and Python MySQL
15:15:33 <rhochmuth> Java tests are non-voting, and there are a few failures still
15:15:56 <rhochmuth> So, after you are done, we woudl have Java MySQL and Hibernate too
15:16:10 <witek> that was my idea
15:16:23 <rhochmuth> What about Python SQLAlchemy and MySQL?
15:17:02 <witek> do we want to support pure mysql in python?
15:17:22 <rhochmuth> Not really
15:18:13 <witek> the new orm change in python changed the config, so sqla is already being tested
15:18:26 <rhochmuth> Is it the default for CU
15:18:28 <rhochmuth> CI
15:18:31 <witek> yes
15:18:40 <rhochmuth> I need to pay more attention
15:19:58 <witek> next topic?
15:20:01 <rhochmuth> OK, then as long as the SQLA is good, then after a few weeks or months, we can probably remove the MySQL
15:20:11 <Kamil> +1
15:20:20 <rhochmuth> #topic influxdb 0.10
15:20:35 <witek> just wanted to ask if anyone tried it out?
15:20:47 <rhochmuth> we are starting too
15:20:58 <rhochmuth> have you tried it out
15:21:03 <witek> no :(
15:21:09 <rhochmuth> we know it works
15:21:21 <rhochmuth> we haven't done any performance analysis
15:21:26 <Christian_> also in cluster mode?
15:21:33 <rhochmuth> we have looked at stability
15:21:39 <rhochmuth> yes, in a three node cluster
15:22:03 <rhochmuth> so far, stability looks good with our limited testing which involves taking down one of the nodes
15:22:04 <witek> cool, promising?
15:22:07 <Christian_> HA?
15:22:11 <rhochmuth> and then rejoining it back to the cluster
15:22:15 <rhochmuth> yes, HA testing
15:23:07 <rhochmuth> We will hopefully have some more analysis in a couple of weeks
15:24:16 <rhochmuth> Next topic?
15:24:33 <rhochmuth> #topic https://review.openstack.org/#/c/284252/
15:24:47 <bklei> that's me
15:24:59 <rhochmuth> way to stay alert
15:25:05 <bklei> i think that guys is ready to go unless someone objects?
15:25:05 <rhochmuth> :-)
15:25:09 <bklei> :)
15:25:26 <rhochmuth> OK
15:25:49 <bklei> I'd really like to get him merged -- and then could we publish monasca-notification to pypi and tag?
15:25:51 <rhochmuth> I already +1'd, but then I took it back
15:26:14 <rhochmuth> but, looks like i merge
15:26:26 <rhochmuth> sure, i can get a new tag applied
15:26:33 <rhochmuth> i'm getting good at that
15:26:46 <bklei> bueno -- we'll pull it in as soon as that happens :)
15:27:02 <bklei> thx rhochmuth and the others who reviewed it
15:27:40 <slogan_r> that change looks ok to me
15:27:53 <rhochmuth> Are there more topics?
15:27:56 <rhochmuth> review?
15:28:00 <rhochmuth> reviews?
15:28:03 <bklei> that was my only one, thx
15:28:16 <slogan_r> how is the devstack implementation in monasca api viewed?
15:28:41 <bklei> with great admiration
15:28:46 <slogan_r> I'm probably going to file some bugs given my experiences
15:29:08 <rhochmuth> so, i think the overall view is that we would like to move away from monasca-vagrant to the DevStack env
15:29:26 <slogan_r> I moved away already :-)
15:29:34 <rhochmuth> There are some things that need to happen to the DevStack env for everyone to do that
15:29:46 <rhochmuth> The DevStack env doesnt' support Vertica
15:29:52 <slogan_r> devstack in general, or our scripts?
15:30:06 <rhochmuth> The monasca devstack plugin
15:30:45 <rhochmuth> i lost track of the monasca horizon and grafana integrating in the DevStack plugin
15:30:53 <rhochmuth> so, that might need some work
15:31:20 <rhochmuth> From witek, support for Hibernate in the Java API
15:31:46 <slogan_r> I'll at least see about filing some bugs I ran into just using it in general, possibly patches to fix them
15:31:57 <rhochmuth> thx
15:32:11 <rhochmuth> please file bugs
15:32:32 <bmotz> having just looked at that review, I think there may be an issue...
15:32:35 <rhochmuth> I should mention that the monasca-vagrnat environemtn was updated this week
15:32:47 <bmotz> I'll add a comment
15:32:57 <rhochmuth> ok, i'll hold off merging
15:33:28 <rhochmuth> So, there were a few points mentioned last week about the moansca-vagrant environment
15:33:43 <rhochmuth> Horizon want' working, Grafana wasn't working, and a couple of others
15:33:47 <rhochmuth> Those are all resolved
15:34:00 <rhochmuth> The environment has also been updated with a new DevStack vm
15:34:12 <witek> thanks Roland!
15:34:23 <rhochmuth> So, prior to doing "vagrant up" in the monasca-vagrant env, do vagrant box update
15:34:36 <rhochmuth> a new devstack image will get pulled down
15:34:44 <rhochmuth> then vagrant up
15:35:37 <Kamil> About global/local dimensions in logs? Do we want to merge or replace? At the end we will need to check each local-dimension anyway.
15:36:07 <rhochmuth> i think a merge is preferred, if performance isn't an issue
15:36:11 <rhochmuth> what are your thoughts?
15:37:04 <tsv> copy and merge, to avoid checking if the fields are same - correct ?
15:37:36 <Kamil> i think merging is the most useful case. But as you mentioned, it could be a performance issue
15:38:00 <bmotz> (I've added a comment on https://review.openstack.org/284252)
15:38:03 <witek> merge here: add the new ones, replace existing ones
15:38:22 <rhochmuth> tsv or Kamil, can you do a quick check on perf
15:38:23 <witek> like python update()
15:38:41 <rhochmuth> sounds like merge is what everyone prefers
15:39:05 <tsv> rhochmuth, sure, based on bmotz's latest comment on the review, i see this has to be a copy of the global dims and merge local dims into it
15:39:24 <rhochmuth> right
15:39:57 <Kamil> or we discard the global dimensions
15:40:50 <Kamil> but then we will need more time to validate all local-dimensions
15:41:31 <tsv> kamil, i was thinking we need to validate the local dimensions anyway. no ?
15:42:06 <Kamil> yes, but if you have global dimensions, then you need to check them only once
15:42:17 <tsv> ah, true
15:42:52 <Kamil> Okay. Let us try to do the merge and check the performance?
15:42:57 <rhochmuth> thx
15:43:04 <tsv> +1
15:43:38 <rhochmuth> witek, have your and your team started working on the non-periodid alarms blueprint?
15:44:16 <witek> not yet :(
15:44:30 <rhochmuth> on a related topic, we might be adding support for periodic notifications to better support Heat
15:44:31 <witek> but still high prio
15:44:36 <rhochmuth> thx
15:44:43 <rhochmuth> looking forward to that
15:45:06 <witek> but 'period' field stays as agreed?
15:45:23 <rhochmuth> yes, these are two separate discussions
15:45:34 <rhochmuth> there are non-periodic/periodic alarms
15:45:50 <rhochmuth> there are also periodic notifications
15:46:10 <rhochmuth> periodic notifications woudl be notficiations that are sent periodicially, even though the state hasn't changed
15:46:26 <witek> get it
15:46:37 <rhochmuth> currently, notifications are one-shot
15:46:45 <rhochmuth> fire and forget once
15:47:03 <rhochmuth> bklei, about that bug yesterday
15:47:14 <rhochmuth> is there a plan on this
15:47:30 <rhochmuth> would be nice to get the old method in, with the fix for limits, i agree
15:47:53 <rhochmuth> are you/twc looking into this or rbrandt
15:47:53 <bklei> yes -- after i get that notification change in i'll push a patch with the reduction of inner joins, but fixed for limits
15:48:03 <rhochmuth> awesome
15:48:03 <bklei> it's broken right now in master -- yes, i'll fix
15:48:10 <rhochmuth> thanks
15:48:22 <bklei> np, should be today or tomorrow
15:48:32 <rhochmuth> so, is there a good test that can be written to catch this?
15:48:36 <rhochmuth> Tempest test?
15:49:00 <bklei> probably -- will look at it.  i think any grafana graph that does a metrics list then stats call would hit it
15:49:16 <bklei> the default monasca one does
15:49:32 <rhochmuth> thx
15:49:58 <bklei> any update on your side for the multiple metrics in one call?
15:50:10 <bklei> sounded like you might be interested in that change for opsconsole?
15:50:18 <rhochmuth> i'm starting to think about it again
15:50:41 <bklei> cool, looking forward to thinking converting to code :)
15:50:56 <rhochmuth> i'll get to looking at it today, unless i get scheduled in for a pile of meetings
15:51:56 <rhochmuth> well, we are winding down
15:52:01 <rhochmuth> anymore topics
15:52:49 <jobrs> dimensions again
15:53:17 <jobrs> I came across this change: https://github.com/openstack/monasca-agent/commit/51b4f9b221099a29357970b1fa6a7267a1445a03
15:53:33 <rhochmuth> did that impact you
15:54:23 <jobrs> in combination with the changed override behavior, yes
15:55:20 <jobrs> maybe you remember the discussion whether mysql is a "component" or a "service". with the change many plugins report component and service with the same value.
15:55:31 <jobrs> does it make sense?
15:55:49 <rhochmuth> yes
15:55:52 <jobrs> my assumption was "service" means openstack-service, not microservice
15:56:02 <rhochmuth> bug component should really be mysqld, the process name
15:56:16 <jobrs> https://github.com/openstack/monasca-agent/commit/3a08640e06af468feeeafcd48e1caec1b1f2f88b
15:56:17 <rhochmuth> the shared service could be mysql
15:56:35 <rhochmuth> the component could be mysqld, or whatever else runs when mysql runs
15:56:45 <rhochmuth> in some databases there are multiple components/processes
15:56:47 <jobrs> that change caused plugins to override user settings for the service dimension
15:57:03 <jobrs> we have service, component and process
15:57:29 <rhochmuth> so, do we need a condition to control the bahaviour
15:57:31 <jobrs> I believe service is good for openstack services, component for components and technical services (like apache, mysql)
15:57:40 <jobrs> and finally process to the processes
15:58:25 <Kamil> but it also makes an merge, right? "new_dimensions.update(dimensions.copy())"
15:58:36 <rhochmuth> correct
15:58:36 <Kamil> but not in the api. It happens in the agent
15:58:42 <rhochmuth> it is a merge
15:58:46 <rhochmuth> and it is in the agent
15:58:54 <jobrs> Kamil, yes but with the latest change the override over has changed.
15:59:29 <rhochmuth> jobrs: we are out of time
15:59:37 <rhochmuth> can we cover this next week, or is this urgent
15:59:39 <Kamil> yes i see
15:59:39 <jobrs> together with more plugins setting the service themselves makes service unusable to group components belonging to the same openstack service
15:59:50 <jobrs> not urgent, we have our own fork.
15:59:57 <rhochmuth> ok,
16:00:04 <rhochmuth> let's talk next week on that topic
16:00:11 <Kamil> bye
16:00:16 <jobrs> bye, thanks
16:00:19 <rhochmuth> bye everyone
16:00:26 <shinya_kwbt> bye
16:00:29 <bklei> cya
16:00:34 <tgraichen> bye
16:00:41 <rhochmuth> #endmeeting