14:00:24 <witek> #startmeeting monasca
14:00:24 <openstack> Meeting started Wed Oct 18 14:00:24 2017 UTC and is due to finish in 60 minutes.  The chair is witek. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:28 <openstack> The meeting name has been set to 'monasca'
14:00:37 <jgr> Hello
14:00:46 <akiraY> Hi.
14:00:48 <koji> o/
14:00:50 <witek> Hello
14:00:58 <rhochmuth> o/
14:01:37 <witek> agenda: https://etherpad.openstack.org/p/monasca-team-meeting-agenda
14:01:48 <witek> please feel free to add topics
14:02:01 <witek> #topic Zuul v3 status
14:02:35 <witek> Adrian and kornicameister have finally managed to get legacy gate jobs passing
14:03:10 <witek> so we can start merging changes which have been blocked last 2 weeks
14:03:27 <witek> we're still half the way
14:04:03 <witek> the configuration of new jobs have to be created in service repositories
14:04:31 <witek> legacy jobs will be turned off some time
14:05:20 <witek> at the moment we have problems getting the configuration right, and the tempest plugins cannot be started
14:05:40 <pabelanger> witek: fell free to ask us in #openstack-infra for help
14:05:45 <pabelanger> or even add issues to etherpad.openstack.org/p/zuulv3-issues
14:06:16 <witek> thanks, will forward to adrian and kornicameister
14:06:53 <witek> I guess we'll need that help :(
14:08:10 <witek> these are the the current reviews:
14:08:13 <witek> https://review.openstack.org/508861
14:08:52 <witek> https://review.openstack.org/#/c/509339/
14:09:46 <witek> #topic Add Service Domain Spec
14:10:12 <witek> I have just given +2
14:10:41 <jgr> Thanks :-)
14:10:44 <witek> https://review.openstack.org/#/c/507110/
14:11:03 <jgr> (I put it
14:11:13 <jgr> on the agenda because I want to get started on implementation at some stage)
14:11:27 <witek> I there are no other comments, I'll merge
14:11:31 <witek> if
14:12:10 <witek> I guess, we have an agreement that we want that feature, so you can start implementing
14:12:28 <jgr> Ok
14:13:03 <jgr> Thanks
14:13:13 <witek> you're welcome :)
14:13:20 <witek> #topic Grafana datasource
14:13:41 <jgr> I put that on there as well
14:13:59 <jgr> So there is this Grafana data source plugin for Grafana 3.x and up
14:13:59 <witek> It's definitely a good idea to have a release tag for it
14:14:23 <jgr> It allows us to use Monasca from recent Grafana
14:14:32 <jgr> s/Monasca/Monasca metrics/
14:14:44 <joadavis> sounds cool
14:14:46 <jgr> The only problem is that it's only got a master branch so far...
14:15:00 <jgr> It is. It even works :-)
14:15:20 <witek> it has "independent" release model
14:15:34 <jgr> (I messed with it a bit today and got it to use the Monasca Horizon plugin's metrics API proxy)
14:16:32 <jgr> Which means we no longer need to worry about authentication (its normal mode of operation involves a Keystone token pasted into the Grafana plugin configuration...)
14:17:01 <jgr> witek: does "independent" prevent us from having tarballs on http://tarballs.openstack.org?
14:17:33 <witek> I guess tarballs are generated for every release tag, which we can have anytime we want
14:18:00 <jgr> witek: basically I'd like to have a master tarball with a development version increased on a per-commit basis in there
14:18:38 <witek> isnt't that too much of tagging?
14:18:56 <jgr> Well, it's the regular tagging...
14:19:07 <jgr> See https://tarballs.openstack.org/monasca-api/monasca-api-master.tar.gz for an example
14:19:31 <jgr> It's got the base version from master (2.2.1) and its development revision is dev22 right now.
14:19:42 <witek> ok, I'll check how it works
14:20:16 <jgr> Basically I'd like to have this sort of thing for monasca-grafana-datasource as well so I've got a source of truth for the version to use in my package :-)
14:20:29 <witek> understand
14:21:10 <jgr> Absolutely no need for a stable branch - I'm fine with targeting master
14:21:32 <witek> so how does grafana-datasource operate with monasca-ui proxy?
14:22:01 <jgr> Smoothly :-)
14:22:09 <witek> we use it for longer time already but only with Grafana Keystone auth fork
14:22:27 <jgr> You point it at http://<dashboard url>/monitoring/proxy and that's it, mostly
14:22:59 <jgr> You need a small patch to get it to omit the API version from the URL it generates based on that base URL, too
14:23:16 <witek> so you disable Grafana's authentication?
14:23:24 <jgr> Mostly, yes
14:23:48 <jgr> What I'm doing right now is allow anonymous login and log in as admin to edit the dashboard
14:24:07 <jgr> That way the anonymous user can view the dashboard but not modify it
14:24:21 <jgr> I think that's a fairly sensible way to go about things
14:25:23 <jgr> One could allow the anonymous user to edit dashboards or configure authentication in Grafana to allow users to create and modify their own personal dashboards
14:25:51 <jgr> But for now I'll settle for the "admin defines, all others view" approach
14:26:41 <witek> sounds reasonable, I'll have to take a look how it works
14:26:48 <jgr> The main thing I wanted to make sure of for now is whether re-using the Horizon session for authentication on the API/API Proxy side (and that appears to work just fine)
14:27:29 <jgr> I've got a rough-and-ready patch against monasca-grafana-datasource
14:27:47 <jgr> I'll polish that up a a bit and add a bit of a writeup for the monasca-grafana-datasource documentation
14:27:58 <witek> cool
14:28:07 <jgr> Once it's in a clean shape I'll submit a review
14:28:20 <witek> what we're losing, is ability for tenants to create their dashboards
14:29:00 <jgr> Well, with Grafana 1.5 these are not persistent either...
14:29:24 <witek> but with Grafana 4 and Keystone auth fork
14:30:29 <jgr> Hmm. Maybe one could even add a Horizon auth plugin to Grafana.
14:30:36 <jgr> That way one wouldn't need an extra login.
14:31:30 <jgr> After all the Horizon session contains tenant information...
14:32:48 <witek> I think we'll follow up on it
14:33:06 <jgr> Yeah
14:33:07 <witek> thanks for the update
14:33:33 <witek> #topic metrics_db_check() migration
14:33:41 <witek> https://review.openstack.org/501601
14:34:19 <akiraY> Any comments?
14:35:30 <witek> I think the gates should pass now
14:35:37 <witek> you can try to recheck
14:35:44 <akiraY> Ok, i'll do it.
14:35:53 <witek> I promised review, but didn't get to it
14:36:42 <akiraY> thanks
14:36:44 <sc> add to my todo list
14:37:28 <witek> #topic value_meta
14:38:29 <akiraY> recently, I've researched TSDBs and I found there are some TSDBs supporing only float.
14:38:58 <akiraY> I have a question: is value_meta used (or required)?
14:40:44 <rhochmuth> value_meta is used to provide additional information about a metric
14:41:02 <rhochmuth> for example, let's say you have a metric called http_status
14:41:17 <rhochmuth> a value of 0 implies OK, a value of 1, implies down
14:41:47 <rhochmuth> the value_meta would be used to provide addition information, such as the status code and text message
14:42:19 <rhochmuth> for example, status_code=500, msg="internal server error"
14:43:53 <akiraY> more comments?
14:43:56 <witek> akiraY: which TSDB does not support key/value pairs of strings?
14:44:17 <akiraY> https://docs.google.com/spreadsheets/d/1sMQe9oOKhMhIVw9WmuCEWdPtAoccJ4a-IuZv4fXDHxM/pubhtml
14:45:15 <akiraY> GridDB is one of them.
14:46:10 <akiraY> See 'supported data types' row.
14:46:11 <rhochmuth> well, i think yiou would just eliminate the value meta if you wanted to support a tsdb that doesn't support strings
14:46:20 <witek> the field is optional in the API
14:47:01 <akiraY> Yes.
14:48:16 <witek> does it answer your question?
14:48:39 <akiraY> hmm...
14:49:48 <akiraY> I want to know:
14:50:20 <akiraY> a) is value_meta used?
14:50:30 <rhochmuth> the field is optional in the API, but you will end-up dropping it in GridDB
14:50:40 <rhochmuth> i meant not store it
14:50:51 <rhochmuth> so, basically loss of information
14:50:59 <akiraY> b) is it important?
14:51:37 <akiraY> c) can any metrics DB ignore it?
14:52:14 <rhochmuth> well, it isn't preferred
14:52:22 <witek> a) yes
14:52:50 <witek> b) might be
14:53:09 <witek> c) it's not the main purpose of the TSDB to store value_meta
14:54:01 <akiraY> I see. thanks:)
14:54:51 <witek> I think it depends how you operate Monasca
14:55:03 <witek> it's definitely a plus if you can store additional info
14:55:35 <akiraY> I think so.
14:56:44 <witek> anything else for today?
14:57:42 <witek> if not, thank you all
14:57:56 <akiraY> thank you.
14:58:06 <witek> see you next week
14:58:09 <witek> bye
14:58:27 <haruki> bye, thanks
15:00:03 <pramchan> #info pramchan
15:00:16 <witek> #endmeeting