15:00:35 <witek> #startmeeting monasca
15:00:36 <openstack> Meeting started Wed Nov  7 15:00:35 2018 UTC and is due to finish in 60 minutes.  The chair is witek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:39 <openstack> The meeting name has been set to 'monasca'
15:00:47 <witek> Hello everyone
15:00:54 <TuanVu> Hi Witek :)
15:00:55 <chaconpiza> Hi
15:00:57 <dougsz> hey all
15:01:03 <truongnh> Hi al
15:01:20 <koji_n> hi
15:01:22 <witek> agenda seems quite light today
15:01:31 <witek> https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:01:43 <witek> let's start
15:01:55 <witek> #topic openstack-discuss mailing list
15:02:23 <dougsz> signed up, thanks for reminder
15:02:31 <witek> first an announcement/reminder
15:02:51 <witek> already posted on #openstack-monasca and openstack-dev already
15:03:05 <witek> http://lists.openstack.org/pipermail/openstack-dev/2018-October/136114.html
15:03:19 <witek> please register for the new list
15:04:05 <witek> #topic disable Java build job for monasca-api
15:04:27 <witek> we have hit a problem with building Java components in the last days
15:05:05 <witek> there are apparently bugs in Ubuntu's openjdk-8 package and maven-surefire-plugin
15:05:41 <witek> the workarounds for monasca-common, persister and thresh seem to work
15:05:56 <witek> https://review.openstack.org/615557
15:06:06 <witek> https://review.openstack.org/615873
15:06:33 <witek> the second one needs review
15:06:52 <witek> but I couldn't find an easy solution for monasca-api
15:07:28 <witek> so, I would like to propose disabling building Java packages for monasca-api
15:07:40 <witek> as it was deprecated in Queens already
15:07:43 <dougsz> As you say it's deprecated
15:07:48 <witek> https://review.openstack.org/615905
15:08:00 <dougsz> I'm all for cutting down on maintenance :)
15:08:39 <witek> thanks dougsz, other opinions?
15:09:16 <witek> joadavis: ?
15:09:40 <joadavis> I think I'm ok with it.  I was trying to think of any objections but have none
15:09:55 <witek> thanks
15:11:04 <witek> the reviews are up there, so after merging we can start rebasing other blocked changes
15:11:23 <dougsz> thanks for fixing witek
15:11:30 <witek> #topic reviews
15:12:03 <witek> events spec:
15:12:12 <witek> https://review.openstack.org/615905
15:12:34 <witek> could we get a consensus which way we go?
15:12:48 <witek> we have two documents there now
15:13:49 <dougsz> I need to find time to go through them properly, i've over manged to skim read so far
15:13:57 <dougsz> s/over/only
15:14:03 <witek> wrong url
15:14:04 <witek> https://review.openstack.org/#/c/583803/
15:14:06 <joadavis> I think the events listener is a better approach. I'd kept the ceilometer based version for history, but we can drop it or move it to another 'wontfix' directory
15:14:57 <joadavis> we don't currently have a directory for specs we have decided not to implement
15:15:33 <witek> joadavis: true, good idea to move it to a different dir
15:16:41 <witek> I also think listener is better
15:17:01 <witek> left some comments in review
15:17:11 <joadavis> thanks
15:17:51 <witek> persister perf spec:
15:17:56 <witek> https://review.openstack.org/#/c/605782/
15:18:40 <joadavis> I tried to refresh the spec and move it out of the WIP state
15:18:45 <witek> thanks for updating
15:19:09 <joadavis> I don't think we have anyone to implement it currently, but it is good to capture what needs to be done
15:19:16 <witek> we have some review adding Prometheus instrumentation
15:19:28 <joadavis> ah, interesting
15:19:29 <witek> so we should link these
15:20:41 <witek> here the change:
15:20:44 <witek> https://review.openstack.org/#/c/605664/
15:22:08 <joadavis> thanks, I'll take a look at that
15:22:40 <witek> it might be it needs further work
15:23:23 <witek> also, due to dependency on prometheus-client, the lib would have to be added to global requirements
15:23:54 <dougsz> I did wonder if statsd might be a lighter alternative given some services support it already
15:24:41 <joadavis> yeah, it does look like it is adding prometheus as a hard requirement, and there are still many deployments where that is not in place or needed
15:24:44 <witek> yes, I'm also not sure about which approach is better
15:27:30 <witek> ok, please leave comments in review if you have opinion or concerns
15:27:53 <witek> upgrade check:
15:27:58 <witek> https://review.openstack.org/#/c/603465/
15:29:11 <joadavis> yes, I quickly refactored my earlier work to match the framework that has been pushed out to many other projects
15:29:19 <witek> so, it's using oslo.upgradecheck now
15:29:25 <joadavis> yes
15:29:38 <joadavis> it still doesn't do any "real" check
15:29:54 <joadavis> but we can add checks when we see the need
15:30:06 <witek> are other projects using it already?
15:30:21 <witek> I mean oslo.upgradecheck
15:30:49 <joadavis> from what I've seen, only a few have merged them. But a couple engineers from NEC pushed the framework out to almost all the OpenStack projects
15:31:22 <witek> nice
15:31:27 <joadavis> I think nova and glance are the only ones that have really implemented checks
15:32:19 <joadavis> its a large list if you look in the upgrade-checkers topic in gerrit
15:33:31 <witek> found a change for Glance https://review.openstack.org/610661
15:34:06 <joadavis> the one shortcut I took in our checker is the localization.  Monasca didn't seem to have the same support for _()
15:34:20 <joadavis> the list of all changes - https://review.openstack.org/#/q/topic:upgrade-checkers+(status:open+OR+status:merged)
15:35:46 <witek> thanks for this work joadavis
15:35:52 <joadavis> sure.
15:36:09 <witek> should we move it to `Needs Review` on our board?
15:36:28 <joadavis> That brings up another point - I have seen a number of Zuul failures lately
15:36:41 <joadavis> yes, we can put it under review
15:37:01 <witek> done
15:37:07 <witek> https://storyboard.openstack.org/#!/board/111
15:37:17 <joadavis> thanks
15:37:27 <witek> back to Zuul failures
15:37:53 <joadavis> seems to be random tempest failures, possibly due to timing
15:39:03 <witek> yes, I've seen this as well
15:39:20 <joadavis> glad it wasn't just me. :)
15:39:57 <joadavis> I hope it clears up soon
15:41:01 <witek> we could spend some time trying to improve tempest tests, but that's laborious
15:42:05 <joadavis> the failures looked like it was still trying to set up the computes before the tests. so maybe an infra problem
15:43:04 <witek> oh yes, that one looked like infra problem, but we have other failures as well
15:44:45 <witek> should we move to the next topics?
15:44:49 <joadavis> yes
15:44:52 <witek> thanks
15:45:00 <witek> #topic pro-active HA
15:45:19 <TuanVu> if there’s any comment on “use cases for Monasca in Proactive HA for VMs”, please feel free to let us know
15:45:30 <TuanVu> We are also welcome any comments for “The list of metrics which are necessary for Proactive HA”
15:45:46 <TuanVu> At this moment, we’re building Prove of Concept for Proactive HA.
15:45:47 <TuanVu> In particular, we’re trying to fill the gap of communication between Monasca and Watcher
15:46:33 <witek> I've chatted with Cong Tuan this week
15:46:53 <truongnh> Hi all, we already proposed the Use Case for Monasca in Proactive HA for VMs here: https://etherpad.openstack.org/p/Use_cases_for_Monasca_in_Proactive_HA_for_VMs
15:47:37 <witek> I could add some description how the generic notification plugin could look like
15:47:43 <TuanVu> Hi Witek, thanks a lot for your great help!
15:47:54 <TuanVu> that's awesome
15:48:36 <witek> have you considered how you would like to collect temperature measurements?
15:49:05 <truongnh> Hi witek, that's very kind of you. We highly appreciate your help.
15:50:06 <TuanVu> we haven't figured it out yet
15:50:09 <truongnh> We're investigating the source codes monasca-notification
15:50:43 <TuanVu> if you have any advice, please don't hesitate to let us know
15:51:26 <witek> as we talked during the PTG Watcher does not `understand` the webhook notification which we could send
15:51:49 <witek> so I thought about adding a generic http notification plugin
15:52:04 <witek> with flexible request body
15:52:36 <witek> when creating a notification method you would have to provide a template
15:52:49 <witek> which could be stored in configuration database
15:53:37 <witek> this template would be used then when sending the notification and filled with actual data, as needed by Watcher
15:54:44 <TuanVu> thanks for detailed information, Witek
15:55:04 <TuanVu> we'll follow your recommendation and let you know if there's any other concern
15:55:32 <witek> I can add some description to the etherpad
15:56:16 <TuanVu> that's great! Thank you very much!
15:56:24 <witek> thanks for working on this\
15:57:12 <witek> next week is Summit week
15:57:30 <witek> not sure if I can join the meeting
15:58:29 <witek> the sessions are till 5:50pm
15:58:30 <joadavis> I think it is customary to skip meetings during the summit. :)
15:58:51 <witek> yes, I think it's best idea
15:59:25 <witek> let's meet here again in 2 weeks then
15:59:41 <witek> and for those attending, see you on Tue
15:59:50 <dougsz> Yep, see you there
15:59:57 <witek> dougsz: when do you arrive?
16:00:11 <dougsz> Monday evening
16:00:20 <witek> have to close now, see you there
16:00:24 <witek> #endmeeting