15:00:04 <rhochmuth> #startmeeting monasca
15:00:05 <openstack> Meeting started Wed Dec  2 15:00:04 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:06 <rhochmuth> o/
15:00:09 <openstack> The meeting name has been set to 'monasca'
15:00:19 <rhochmuth> roll call
15:00:35 <rbak> o/
15:00:38 <witek> hi
15:00:41 <bklei> o/
15:01:07 <rhochmuth> hello everyone
15:01:16 <bklei> hola
15:01:19 <rhochmuth> looks like we have a good turn out
15:01:23 <shinya_kwbt> o/
15:01:27 <bmotz> o/
15:01:34 <rhochmuth> Let's start at the top of the agenda and work down
15:01:49 <openstack> rhochmuth: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
15:01:55 <rhochmuth> https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:02:02 <rhochmuth> Agenda for Wednesday December 02, 2015 (15:00 UTC)
15:02:02 <rhochmuth> 1. Monasca Python Client integration in requirements (fabiog)
15:02:02 <rhochmuth> 1.1. https://review.openstack.org/#/c/251674/
15:02:02 <rhochmuth> 2. Healtcheck for python API (monasca-api, monasca-log-api)
15:02:02 <rhochmuth> 2.1. oslo.middleware - it is fine ?
15:02:02 <rhochmuth> 2.2. Figuring out best solution to add healtchecks
15:02:03 <fabiog> o/
15:02:03 <rhochmuth> 3. yandex.ru
15:02:03 <rhochmuth> 3.1 https://review.openstack.org/252305
15:02:04 <rhochmuth> 3.2 https://review.openstack.org/252302
15:02:04 <rhochmuth> 3.3 https://review.openstack.org/252315
15:02:05 <rhochmuth> 4. Status update on api caching?
15:02:05 <rhochmuth> 5. InfluxDB plugin (use of service vs. component dimension, naming of metrics) (jobrs)
15:02:06 <rhochmuth> https://review.openstack.org/#/c/196167/
15:02:16 <rhochmuth> #topic Monasca Python Client integration in requirements (fabiog)
15:02:17 <jobrs> hi, sorry for last minute addition to agenda
15:02:31 <fabiog> nothing major here
15:02:33 <rhochmuth> OK, fabiog
15:02:46 <fabiog> just posted the change to integrate our client with the greater openstack
15:02:51 <fabiog> please support the change
15:02:59 <fabiog> and I think we need infra to approve it
15:02:59 <bklei> link?
15:03:04 <witek> it seems the last meeting is not finished
15:03:21 <rhochmuth> no, i started it twice by accident
15:03:24 <fabiog> https://review.openstack.org/#/c/251674/
15:03:25 <witek> ok
15:03:37 <rhochmuth> thanks fabiog
15:03:53 <fabiog> rhochmuth: please +1 it and see if any of the HP infra guys can give some love
15:03:55 <tgraichen> o/
15:04:05 <rhochmuth> i'll review and +1 …
15:04:16 <fabiog> rhochmuth: it is blocking the integration with Congress and all the potential others
15:04:17 <rhochmuth> but i'll only +1 f it is good
15:04:21 <bklei> lgtm
15:04:42 <fabiog> rhochmuth: yeah, 2 lines of text changes ... :-)
15:04:51 <rhochmuth> #topic Healtcheck for python API (monasca-api, monasca-log-api)
15:05:05 <tomasztrebski> yeah, hello...made it :)
15:05:14 <rhochmuth> hi tomasz
15:05:31 <rhochmuth> so, i've seen the changes to the monasca-log-api for adding a healtcheck
15:05:45 <rhochmuth> and obviousely, we would like to do the same for the monasca-api and monasca-events-api
15:06:02 <tomasztrebski> link https://review.openstack.org/#/c/249685/
15:06:10 <rhochmuth> but it sounds like we have to figure out what the right approach is
15:06:31 <bklei> would love that for monasca-api -- we hope it's lightweight though, would like to call from load balancers
15:06:35 <tomasztrebski> good to hear, that was my assumption that's why I wanted to bring it up here
15:06:44 <witek> #link https://review.openstack.org/#/c/249685/
15:07:01 <bklei> does it require auth?
15:07:08 <rhochmuth> so, what is the overall design
15:07:10 <tomasztrebski> thx witek
15:07:14 <rhochmuth> can you step us throught that
15:07:22 <rhochmuth> via irc?
15:07:32 <tomasztrebski> an overall proposal, lets call it like that, was to use oslo middleware so something from openstack
15:07:43 <tomasztrebski> I think that's a nice idea while being under a tent
15:07:46 <fabiog> bklei: it does because is a filter
15:07:53 <bklei> bummer
15:08:15 <rhochmuth> so, the middleware is a filter that would end-up in the stack on every call?
15:08:22 <rhochmuth> every method?
15:08:24 <tomasztrebski> basically what Fabio has noticed is that using middleware from oslo ties it up to the API
15:08:27 <fabiog> rhochmuth: yes
15:08:37 <bklei> would like something similar for monasca-api, and eventually anything behind a lb that doesn't fill the logs with auth errors
15:09:06 <fabiog> tomasztrebski: also it prevents the loadbalancer to perform the check, because you have to do a "real" call
15:09:07 <bklei> maybe that's not 'healthcheck' as much as 'alive'
15:09:21 <tomasztrebski> with gunicorn standing behind monasc-api, monasca-log-api and events too I believe only solution is to run secondary process on different port doing a healtcheck
15:09:47 <rhochmuth> that would be more similar to how the java api works
15:09:55 <rhochmuth> dropwziard bases
15:09:59 <fabiog> tomasztrebski: not necessaroly. If we have an endpoint called health a load balancer can it that at the frequency they want
15:10:15 <bklei> +1
15:10:28 <tomasztrebski> yes and quite achievable with upstart for instance and dependent services, i.e. start after as far as I remeber
15:10:53 <fabiog> as I mentioned in the comment you can implement HEAD and GET, HEAD just being aliveness and GET being a full checking that all the components are working
15:11:18 <tomasztrebski> yes, that's another disadvantage of current implementation in oslo.middleware
15:11:20 <fabiog> so deployers can decide if to use a single validation point or monitor the components separately
15:11:26 <tomasztrebski> check does not know what HTTP method was used
15:11:38 <rhochmuth> is it possible to start-up a second server in a python api, with a new endpoint declared
15:12:01 <rhochmuth> and would that make sense?
15:12:01 <fabiog> rhochmuth: why do you want a second server?
15:12:14 <rhochmuth> well, maybe because i'm confused
15:12:26 <fabiog> rhochmuth: if the second server is down you report an error that may not exist
15:12:34 <tomasztrebski> rhochmuth: it is possible
15:12:40 <rhochmuth> but, i think having a private or second endpoint in the api is what i'm after
15:12:56 <tomasztrebski> but fabioq proposal is to have it builtin in the API right ?
15:12:57 <fabiog> +1
15:13:04 <fabiog> tomasztrebski: yes
15:13:28 <rhochmuth> but, i don't think it should be visible externally/publicially
15:13:45 <rhochmuth> or maybe it should, but that is not what i usually do
15:13:57 <tomasztrebski> but that will be a a difference between Java/Python, because with gunicorn you ties up an app to given port and only that port
15:14:08 <tomasztrebski> AFAIK
15:14:23 <fabiog> tomasztrebski: yes it will have the same port
15:14:41 <rhochmuth> well, i was thinking a new endpoint for healtchecks that runs on a different host and port
15:14:47 <fabiog> something like 8087:/v2/logs/health
15:14:57 <rhochmuth> so you could control and lock it down independetly of the public api
15:15:07 <rhochmuth> if you want to
15:15:46 <fabiog> rhochmuth: but how do you make sure that if that server is down the real service is running and vice versa?
15:15:55 <rhochmuth> for example, you loadbalance healthcheck would be able to access it, but it wouldn't be avaialble publically
15:16:15 <rhochmuth> not sure i understand
15:16:21 <rhochmuth> your question fabiog
15:16:21 <tomasztrebski> healthcheck could verify if a port is open for instance
15:16:33 <tsv> +1 on the separate endpoint for healthcheck. Btw, tomasztrebski are we tied to gunicorn ? for example, companies may use apache instead ?
15:16:37 <fabiog> rhochmuth: load balancer hits the health check endpoint that is a different server
15:16:54 <fabiog> rhochmuth: if that is down it does not mean that  Monasca API is down
15:17:35 <fabiog> rhochmuth: if it is part of the same server as soon as that instance is down lb knows and can re-route traffic to another instance
15:17:40 <rhochmuth> by separate server, it is just a separate server within the same monasca-api that is running
15:17:42 <tomasztrebski> tsv: we are using gunicorn as the common ground in monasca, monasca-api has it too, that's why it is used, but essentially it is WSGI, so any WSGI server can be used
15:18:04 <rhochmuth> For example, start a private endpoint using
15:18:05 <rhochmuth> if __name__ == '__main__':
15:18:05 <rhochmuth> wsgi_app = (
15:18:05 <rhochmuth> paste.deploy.loadapp('config:etc/api-config.ini',
15:18:05 <rhochmuth> relative_to=os.getcwd()))
15:18:05 <rhochmuth> httpd = simple_server.make_server('127.0.0.1', 8080, wsgi_app)
15:18:05 <rhochmuth> httpd.serve_forever()
15:18:53 <fabiog> rhochmuth: ok, so it is a child process of the main monasca api service
15:19:03 <rhochmuth> i guess
15:19:07 <fabiog> rhochmuth: so if that is dead you know monasca api is dead
15:19:15 <rhochmuth> that is what i was thinking
15:19:20 <tomasztrebski> yummy, makes sense to me
15:19:33 <rhochmuth> problems is in python i guess you can't just start up a separate thread with the server running on it
15:19:35 <fabiog> rhochmuth: I think that is important to be sure of, because you don't want two separate moving parts
15:19:37 <rhochmuth> like you can in java
15:19:46 <rhochmuth> with dropwizard
15:20:08 <tomasztrebski> let's call it investigation and see where does it lead to...I am mostly interested in doing it right rather then fast
15:20:17 <rhochmuth> so, it seems like some more investigation is necessary on whether that can be done or not
15:20:22 <tomasztrebski> +1
15:20:26 <rhochmuth> ok, tomasz, i was midstread in my sentence
15:20:42 <rhochmuth> so you're going to continue to investigate
15:20:49 <tomasztrebski> yes
15:20:56 <rhochmuth> ok, thanks
15:21:12 <rhochmuth> let's close this topic then and see what tomasz finds out
15:21:19 <witek> #action tomasztrebski Investigate adding healthchecks
15:21:21 <tomasztrebski> internally that's what we want to have, change was more or less a proposal and ground to start a discussion
15:21:22 <rhochmuth> if anyone else has ideas please work with tomasz
15:21:34 <tomasztrebski> you know where to find me :P
15:22:04 <rhochmuth> #topic yandex.ru
15:22:19 <rhochmuth> yandex.ru
15:22:20 <rhochmuth> 3.1 https://review.openstack.org/252305
15:22:20 <rhochmuth> 3.2 https://review.openstack.org/252302
15:22:20 <rhochmuth> 3.3 https://review.openstack.org/252315
15:22:34 <tomasztrebski> lots and lots of LOC
15:22:41 <rhochmuth> So, I'm wondering what this all about
15:22:50 <tomasztrebski> don't ask my, I wanted to ask the same
15:23:09 <rhochmuth> is oiskam1 available or anyone else from yandex
15:23:14 <witek> :) someone would like to replace hibernate
15:23:32 <bklei> ^^^ is a scary set of patches
15:23:34 <tomasztrebski> and mysql to be precise
15:23:43 <rhochmuth> yeah, that is what it looks like
15:23:57 <tomasztrebski> those changes remove everything that monasca did before fujitsu and what Fujitsu has addded
15:23:57 <rhochmuth> i haven't looked at in any detail
15:24:10 <fabiog> rhochmuth: please ask for a spec first
15:24:27 <rhochmuth> well, it would be good to first understand what the movitivation is and then a discussion and spec
15:24:28 <shinya_kwbt> jooq
15:24:51 <fabiog> rhochmuth: the spec should have the motivation in it, right?
15:24:53 <rhochmuth> ok, doesn't sound like anyone is here form yandex
15:25:01 <rhochmuth> correct fabiog
15:25:20 <rhochmuth> i think we just need to leave some comments and -1 at this point
15:25:44 <tomasztrebski> I didn't expect someone from yandex to be here, there is nobody assigned to those changes apart from Jenkins
15:25:55 <tomasztrebski> but Jenkins is being invited to each party, so....
15:26:08 <rhochmuth> we don't have any understanding of why the change is proposed
15:26:17 <rhochmuth> i'll add my comments to the reviews
15:26:18 <fabiog> rhochmuth: done ;-)
15:26:25 <rhochmuth> and i would encourage others to do the same
15:26:33 <rhochmuth> and we'll have to see where this leads to
15:26:40 <tomasztrebski> that's a tall mountain to climb on....
15:26:45 <tomasztrebski> but we'll try
15:27:01 <rhochmuth> #topic Status update on api caching?
15:27:14 <rhochmuth> Am i supposed to give an update
15:27:29 <rhochmuth> no change
15:27:30 <rhochmuth> sorry
15:27:36 <rhochmuth> i was out last week
15:27:49 <rhochmuth> and this week is not going well
15:27:59 <rhochmuth> pretty mich reviews and meetings all week
15:28:08 <bklei> ok -- np, been busy doing other stuff here too
15:28:19 <rhochmuth> can this wait until next year
15:28:28 <fabiog> rhochmuth: the price of being famous ...
15:28:45 <bklei> if it has to i suppose, may try to get to it if you don't
15:28:51 <bklei> if i can clear my deck
15:29:03 <rhochmuth> i'll be happy to work with you on what i think should be done
15:29:08 <rhochmuth> if you free up
15:29:16 <rhochmuth> also get deklan's eye on it
15:29:27 <bklei> ok - will let you know if i do
15:29:27 <rhochmuth> to get a proper design in-place
15:29:30 <bklei> and deklan
15:29:36 <rhochmuth> i'll keep you updated
15:29:42 <bklei> gracias
15:29:45 <rhochmuth> on my status
15:30:01 <rhochmuth> #topic InfluxDB plugin (use of service vs. component dimension, naming of metrics) (jobrs)
15:30:02 <rhochmuth> https://review.openstack.org/#/c/196167/
15:30:20 <jobrs> that's me
15:30:25 <rhochmuth> jobrs that you
15:30:56 <jobrs> so, I took what Dexter had prepared
15:31:31 <jobrs> and address the leftovers, which seemed to focus on naming of metrics
15:31:56 <jobrs> as it turned out, there is more to fix and it will take me some more days
15:32:27 <jobrs> two questions came up: what to use dimension "service" for and for what "component" is good
15:32:53 <rhochmuth> service is usually the nice human readable name for the service
15:32:54 <jobrs> Monasca: service=monitoring, component=e.g. apache-storm, monasca-api, ...
15:33:00 <rhochmuth> nice tautology isn't it
15:33:09 <jobrs> absolutely!
15:33:15 <rhochmuth> so, for a service like nova/compute
15:33:24 <rhochmuth> the service is "compute"
15:33:25 <jobrs> my perception so far: service for the exposed service
15:33:27 <jobrs> yep
15:33:38 <rhochmuth> that service has a bunch of components in it like nova-api, nova-compute, …
15:33:54 <jobrs> and component for the technical part (which might be a service, micro service, whatever)
15:33:56 <rhochmuth> so the component is the actual executable
15:34:10 <rhochmuth> in the case of something like mysql
15:34:14 <jobrs> so looking at influxdb, it is generic
15:34:18 <rhochmuth> the component woudl be mysqld
15:34:23 <jobrs> service=<user defined>
15:34:30 <rhochmuth> with the "d" on the end for the mysql daemon
15:35:21 <rhochmuth> so, for influxdb i would use service=influxdb
15:35:49 <rhochmuth> the component name might be component=influx or influxd
15:36:03 <rhochmuth> whatever is the name of the influxdb component
15:36:11 <rhochmuth> Is everyone still there
15:42:56 <fabiog> witek: yes.
15:42:56 <tomasztrebski> mhm...here we go again....
15:43:32 <fabiog> witek: all the monasca code has a 2015.1 tag, that corresponds to stable/kilo
15:44:10 <fabiog> witek: I asked to be added in the official set for Monasca, but apparently Openstack does not have a deLoran yet, so they cannot go back in time and add it
15:44:15 <fabiog> deLorean
15:45:00 <fabiog> witek: the first release that we can officially add is Mitaka since we weren't really ready before Liberty was cut
15:45:15 <fabiog> witek: still there?
15:45:38 <tgraichen_> new we from berlin were thrown out as well for a moment
15:45:39 <witek> fabiog: yes, reading
15:49:09 <fabiog> I think Roland has been caught in the connectivity outage net
15:49:52 <witek> seems so
15:50:27 <jobrs> continue with influx+naming topic or postpone?
15:54:30 <jobrs> so I will just finish what I wanted to say (for the recording):
15:55:34 <witek> jobrs: yes, go on
15:55:49 <jobrs> for the influxdb plugin I will not set service-dimension (since there are InfluxDBs not serving Monasca) and set the component-dimension to 'influxdb' (which is not just the process but InfluxDB as a whole)
15:56:55 <jobrs> I changed the metric names to remove Camel-case and removed the .count, .curr, etc. suffixes since IMHO they do not add meaning to the name
15:57:51 <jobrs> finally I would like to introduce meaningful defaults for today's parameters, so that it is sufficient to merely set the user credentials to make the plugin work
15:58:50 <jobrs> that's it - let's follow-up inside https://review.openstack.org/#/c/196167/
15:59:19 <witek> jobrs: thanks
16:00:00 <witek> so, I think we should end the meeting
16:00:13 <witek> anyone knows, how to do it without admin?
16:00:41 <jobrs> wait for the next meeting and its admin
16:00:42 <zehicle> if you started it, then you can edit it
16:00:49 <zehicle> we're here
16:00:58 <openstack> zehicle: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
16:01:07 <zehicle> #endmeeting