15:01:29 <rhochmuth> #startmeeting monasca
15:01:30 <openstack> Meeting started Wed May 24 15:01:29 2017 UTC and is due to finish in 60 minutes.  The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:33 <openstack> The meeting name has been set to 'monasca'
15:01:35 <cbellucci> hi kornica!
15:01:42 <rbrndt__> o/
15:01:45 <kornica> o/
15:01:50 <kamil> o/
15:01:50 <cbellucci> hi everyone :)
15:01:51 <rhochmuth> loops, a little late, was doing some email
15:01:52 <haruki> o/
15:01:56 <rhochmuth> o/
15:02:00 <witek> hello
15:02:04 <shinya_kwbt> o/
15:02:10 <rhochmuth> https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:02:18 <hosanai> o/
15:02:23 <koji> o/
15:02:24 <rhochmuth> Agenda for Wednesday May 24 2017 (15:00 UTC)
15:02:24 <rhochmuth> 1.	https://storyboard.openstack.org/#!/story/2001037
15:02:24 <rhochmuth> 2.	Review/Opinion needed
15:02:24 <rhochmuth> 1.	https://review.openstack.org/#/q/status:open+branch:master+topic:new_client
15:02:24 <rhochmuth> 2.	https://review.openstack.org/#/q/status:open+topic:story/2000995
15:02:24 <rhochmuth> 3.	InfluxDB patch upgrade [ https://review.openstack.org/#/c/459051/ + https://review.openstack.org/#/c/467482 ]
15:02:24 <rhochmuth> 4.	Reevaulating stevedore ?
15:02:25 <rhochmuth> 5.	Reviews ?
15:02:25 <rhochmuth> 6.	Should we use 'project' and deprecate using 'tenant' term?
15:02:26 <rhochmuth> 1.	Keystone uses 'project' (v2 which was using 'tenant' was deprecated in Mitaka)
15:02:26 <rhochmuth> 2.	But other services use the terms exchangeably and not consistently, e.g. nova
15:02:27 <rhochmuth> 7.	Change Monasca meeting time:
15:02:27 <rhochmuth> 1.	Can we meet an hour earlier?
15:02:33 <rhochmuth> Lot's of topics today
15:02:44 <witek> should we start with the last one?
15:03:00 <rhochmuth> Sure
15:03:06 <rhochmuth> That was mine
15:03:12 <sc> hi
15:03:14 <rhochmuth> #topic Change Monasca meeting time:
15:03:37 <kamil> i am fine
15:03:49 <rhochmuth> So based on my meeting schedule and a request for a company that would like to be more involved in the meetings there was a request to move to one hour earlier
15:03:52 <kamil> with meeting one hour earlier
15:03:55 <kornica> I can adjust to majority, for me it is harder to jon the meetings anyway :/
15:03:57 <sc> suggest time?
15:04:07 <rhochmuth> WOuld that work for folks?
15:04:16 <kornica> +1
15:04:19 <rhochmuth> +1
15:04:21 <witek> I think US west coast is most affected
15:04:49 <rhochmuth> Do we have anyone attending from West Coast?
15:04:52 <witek> +1 from me
15:04:54 <sc> +1 (I read)
15:04:59 <cbellucci> +1
15:05:09 <rhochmuth> jgu: ?
15:05:09 <shinya_kwbt> +1
15:05:11 <witek> we also have to check if there is an empty slot
15:05:21 <rhochmuth> yeah, that might be problematic
15:05:32 <haruki> +1
15:05:41 <jgu> +1
15:05:46 <rhochmuth> ok, i'll take a look and see if there is an open openstack-meeting slot
15:05:49 <rhochmuth> thanks jgu
15:05:54 <kornica> publiccloud_wg is before monasca
15:05:56 <rhochmuth> are u west coast
15:06:16 <jgu> rolland: yes I am west coast
15:06:21 <jgu> 7am is fine
15:06:36 <rhochmuth> the early developer gets the bug
15:06:43 <witek> :)
15:06:50 <jgu> lol
15:07:12 <rhochmuth> ok, i'll look into it and try and send out to openstack-dev for next week
15:08:07 <rhochmuth> #topic https://storyboard.openstack.org/#!/story/2001037
15:08:16 <kornica> ok, that's mine
15:08:28 <kornica> detected today, really fresh
15:08:37 <kornica> <rotfl>
15:08:47 <witek> there is also another one, related:
15:08:50 <kornica> apart from what's written in the story there's pretty nothing much more to add
15:08:50 <witek> https://storyboard.openstack.org/#!/story/2001036
15:08:54 <kornica> oh..thx witek
15:09:19 <kornica> yeah, but that one kind of duplicates, or the one I created duplicates yours
15:09:39 <kornica> both comes from the very different APIs kafka-python library offers in different versions
15:10:00 <witek> would it be enough to use the legacy SimpleClient?
15:10:14 <kornica> well, I think it is used now
15:10:23 <kornica> PyCharm pointed that to me as deprecated
15:10:24 <rbrndt__> probably not, some basic philosophy changed in the newer versions
15:10:53 <kornica> this is pretty much the same story as we had with psutil
15:11:10 <rbrndt__> it's a bit more complicated, but similar for sure
15:11:12 <kornica> little complicated by the fact that monasca pipeline is baed on older kafka
15:11:29 <kornica> *based
15:11:42 <kornica> so we had to support both of 'em actually
15:11:48 <kornica> *have
15:11:56 <kornica> jesus...should've gone sleep earlier...
15:12:39 <kornica> what's your take on this ?
15:13:20 <rhochmuth> so, the upstream openstack requires the newer kafka library
15:13:22 <rhochmuth> correct?
15:13:42 <witek> right
15:14:08 <rhochmuth> From an official stand-point we should support the newer library, but not necessarily the old library
15:14:18 <rhochmuth> but, simialr to psutil, we might want to support both
15:14:19 <sc> is it possible to update pipeline? I think supporting both version is nightmare
15:14:28 <witek> what about monitoring Monasca itself?
15:14:52 <kornica> as I mentioned before monasca is based on kafka 0.9.x so we need to have older library support
15:15:03 <kornica> otherwise we don't get metrics from monasca's topics
15:15:25 <rhochmuth> didn't we copy everything into monasca-common and create our own fork
15:15:46 <rbrndt__> yes, so that we could avoid using the new library
15:15:59 <kornica> we did, but I bet that it does not help for the core of the bug - newer library
15:16:45 <rhochmuth> so, should the agent use monasca-common?
15:17:03 <rhochmuth> does that help?
15:17:23 <kornica> extracted code works with older kafka brokers
15:17:41 <kornica> witek: can you take a look at priv from me ?
15:18:01 <rhochmuth> i was hoping the older kafka worked with the newer brokers
15:20:30 <rhochmuth> maybe i don't understand the problem, but if we converted to kafka plugin to use monasca-common and the old kafka library works with the latest kafka broker, would that work?
15:20:31 <witek> rhochmuth: I think we could give it a try and add monasca-common requirement to monasca-agent
15:20:44 <rhochmuth> ok, that sounds reasonable
15:21:01 <witek> not very elegant though
15:21:01 <rhochmuth> rbrndt__: u still there?
15:21:04 <rbrndt__> yeah
15:21:22 <rhochmuth> i thought you were testing the latest kafka broker
15:21:26 <rbrndt__> I found some claims online that the 0.9 client should be compatible with the 0.10 broker
15:21:42 <rhochmuth> that is what i thought too
15:21:55 <rbrndt__> I have partially confirmed that they work together, while testing something else. But I didn't check in detail that everything was correct
15:22:13 <rhochmuth> thx
15:22:20 <kornica> we need just a chunk of funtionality to work to get offsets
15:22:25 <kornica> hopefully that will work
15:22:43 <kornica> guess we'll see in future once we get a slot to work with this bug
15:23:16 <rhochmuth> #topic https://review.openstack.org/#/q/status:open+topic:story/2000995
15:23:21 <rhochmuth> moving on then
15:23:38 <rhochmuth> https://review.openstack.org/#/c/461142/
15:23:42 <kornica> us, fujitsu, again...
15:23:47 <rhochmuth> that is too much code to review for me
15:24:15 <kornica> was hard to lower it down
15:24:26 <kornica> but mostly that is deletion
15:24:32 <kornica> *deleting
15:24:44 <rhochmuth> the review looks great to me
15:24:50 <rhochmuth> thanks for doing that
15:24:59 <rhochmuth> a lot of code is removed
15:25:23 <kornica> well, the osc-lib is the library that is meant for openstack clients
15:25:30 <rhochmuth> i'll take a closer look, but based on comments, it looks like it is mostly ready to go
15:25:41 <witek> all these changes are dependent, right?
15:26:08 <kornica> tht topic story/2000995 provides unified handling of keystone communication
15:26:21 <kornica> for client little more but that was neccessary and couldn't really be avoided
15:26:50 <kornica> the topic new_client is follow up that puts dependent components on top of https://review.openstack.org/#/c/461142/
15:27:02 <kornica> I tried to make sure to connect all changes with Depends-On directive
15:27:56 <witek> right, we should try not to break devstack
15:28:05 <rhochmuth> thanks kornica
15:28:42 <kornica> I can tell you that story/2000995 is the first one to go in, later we have intergration with newer client in agent and ui
15:29:00 <kornica> aaah....one important note from using osc-lib
15:29:06 <kornica> --timing (guess that's the flag)
15:29:35 <kornica> try it out, you'll get a set of times it took to actually process the command, keystone calls, API calls
15:29:47 <kornica> liked that so much I had to say it outloud :P
15:30:07 <kornica> guess there's even support for osprofiler that Witek mentioned was discussed in Boston
15:30:25 <rhochmuth> nice
15:30:28 <kornica> + all sorts of auth methods that keystone supports
15:30:58 <rhochmuth> Should we move on?
15:31:02 <kornica> yeah
15:31:08 <rhochmuth> #topic https://review.openstack.org/#/c/459051/
15:31:11 <kornica> let's skip topic new_client, we discussed that already
15:31:24 <rhochmuth> https://review.openstack.org/#/c/467482
15:31:44 <kornica> ahm, actually bump to 1.1.5 was a test to see if everything still works
15:31:50 <kornica> I wanted to include Dirk's change first
15:32:01 <rhochmuth> Oh, didn't realize that
15:32:07 <rhochmuth> It is fine with me
15:32:14 <rhochmuth> Dirk changed the port numbers
15:32:19 <rhochmuth> you had asked a question about that
15:32:24 <rhochmuth> but no response
15:32:25 <rhochmuth> yet
15:32:58 <kornica> yeah, he did but that's non-invasive, plus seems correct from the POV that previously client (an outsider so to speak) was talking with admin API of keystone
15:32:58 <rhochmuth> Do you want that change merged anyway?
15:33:06 <kornica> logically that seems a bit too much
15:33:14 <kornica> and public API (under 5000) is sufficient
15:33:42 <kornica> well, to be honest devstack/files/env.sh is a bit redundant in the way that is explictly exports OS_ variables
15:33:46 <rhochmuth> So, we should merge Dirk's review
15:33:50 <kornica> I'd say so
15:34:02 <kornica> FYI: there's devstack/openrc file
15:34:09 <rhochmuth> I just +1'd it
15:34:19 <kornica> that exports more variables and it is died up to devstack based deployment
15:34:22 <rhochmuth> if you want to merge that would be great
15:34:29 <kornica> I'll take care of that
15:34:30 <kornica> np
15:34:48 <kornica> one way or another 1.1.5 will be at the end of the process available in upstream
15:35:01 <rhochmuth> sounds good to me
15:35:20 <rhochmuth> btw, you had some reviews for influxdb relay
15:35:24 <rhochmuth> or someone did
15:35:59 <rhochmuth> found it, so i see that one isn't ready yet
15:36:11 <kornica> which review exactly
15:36:21 <rhochmuth> https://review.openstack.org/#/c/465397/
15:36:47 <rhochmuth> Koji had submitted it
15:36:58 <kornica> ah that one - yeah, a bit similar to https://review.openstack.org/#/c/466272/
15:37:21 <kornica> the point is to have better, more readable dimensions to clasiffy influxdb or nodes
15:37:32 <kornica> but in the Koji's change there's part of the code that is not unit-tested
15:37:35 <rhochmuth> I +1'd https://review.openstack.org/#/c/466272/
15:37:36 <kornica> the extra arg
15:38:06 <kornica> since coverage is already low, I think putting focus on unit-tests is good approach and leaving uncovered lines not such a great idea in the same time
15:38:16 <witek> +1
15:38:21 <rhochmuth> +1
15:38:40 <rhochmuth> #topic Reevaulating stevedore ?
15:38:56 <rhochmuth> moving on again
15:39:05 <kornica> I think Joe pointed to me that you've been having a discussion around stevedore
15:39:18 <kornica> back in time, guess even before Fujitsu's joined monasca
15:39:30 <rhochmuth> i'm not aware of any discussions going now
15:39:42 <kornica> well now not, might be longer time ago
15:39:44 <rhochmuth> but yes, we had a difficult time with stevedore
15:39:54 <kornica> hmm...that surprises me a lot
15:39:55 <rhochmuth> so we used simport
15:40:23 <kornica> I've been playing a lot with it recently and it much more flexible alternative providing some nice abstraction layer on the process of loading the checks
15:40:50 <kornica> + I see it prettty much everwyhere in openstack (at least where I look there's a stevedore)
15:41:13 <kornica> seemed like a nice idea to propose that for monasca notification
15:41:24 <rhochmuth> it is more flexible, i agree
15:41:53 <rhochmuth> but, we had difficulties understanding what it was doing and where it was looking for modules to load, ...
15:42:30 <rhochmuth> simport was straight-forward
15:42:51 <kornica> ahm...virtualenv, system but in general entry-points under namespace you're interested in
15:43:00 <kornica> which is again pretty verbose
15:43:00 <rhochmuth> so, i think the issue was just basic understanding of stevedore and how to use it correctly and avoid the side-effects
15:43:29 <rhochmuth> yeah, in the early days of monasca development, we weren't using virtualenvs yet
15:43:50 <rhochmuth> i think our python knowledge might have been a little weak in that area
15:43:53 <kornica> it can get from system as well....system is actually one big virtualenv
15:44:13 <rhochmuth> so, is there a reason to more from simport to stevedore
15:44:21 <rhochmuth> i'm just wondering what the motivation is
15:44:53 <rhochmuth> other than it would be nice to be more compatible
15:45:10 <rhochmuth> and it provides more features, although i'm not sure what feature i would use
15:45:44 <kornica> just that, it was just a question - if monasca is happy with simport, there's no point in dragging this on
15:45:59 <rhochmuth> i'm happy
15:46:02 <rhochmuth> :-)
15:46:12 <kornica> ahm, there are different types of loaders and so on - but really that's off the scope of a meeting
15:46:34 <kornica> we can chat over mail if you're interested  though ;-)
15:46:35 <rhochmuth> #topic reviews
15:46:42 <rhochmuth> have we covered enough reviews?
15:46:52 <rhochmuth> or are there others to look at
15:47:07 <kornica> https://review.openstack.org/#/c/467612/
15:47:25 <kornica> might be nice to mention what Dobek (my buddy) started to work on
15:47:56 <rhochmuth> ok, i'll look at that one too
15:48:14 <rhochmuth> i was going to mention that silence, inhibit and group have been combined into three reviews
15:48:21 <rhochmuth> one for api, notificatino and client
15:48:35 <rhochmuth> but, we are in the process of changing things around a bit
15:48:44 <rhochmuth> so, i would hold off another week
15:48:47 <kornica> guess Artur's been most active for now from our side in abandoned reviews
15:50:32 <rhochmuth> #topic Should we use 'project' and deprecate using 'tenant' term?
15:50:51 <rhochmuth> my guess is that would break a lot of folks
15:50:57 <witek> that's mine, wanted to ask for your opinion on that
15:51:14 <rhochmuth> well, we were in the process of adding MQL
15:51:27 <rhochmuth> which would have forced a v3 API
15:51:37 <rhochmuth> if we did that, then i think we would be ok
15:51:39 <kornica> witek: might be nice to add this review as reference
15:51:39 <kornica> https://review.openstack.org/#/c/456228/
15:51:48 <kornica> *to mention
15:52:19 <witek> kornica: thanks
15:52:56 <kornica> basically I am for depreacting tenant_id mainly because, I guess it was Mitaka, that depreacated keystone v2 which used term tenant
15:53:45 <witek> as rhochmuth mentioned, we would have to move to new API version
15:53:46 <rhochmuth> i guess i like the API to be consistent with itself
15:54:08 <witek> +1 for consistency
15:54:23 <kornica> I am really sure what consistency we have in mind :D
15:54:37 <kornica> *not really sure
15:54:39 <witek> naming consistency
15:54:49 <rhochmuth> so, we have tenant everywhere in the monasca api
15:55:04 <rhochmuth> so, if we start using project, then that is inconsistent
15:55:16 <rhochmuth> although it is consistent with keystone
15:55:22 <witek> :)
15:55:28 <rhochmuth> i'm not sure what other projects have done
15:55:30 <rhochmuth> like nova
15:55:37 <witek> e.g. nova uses both term
15:55:42 <rhochmuth> but i thoguht use of tenant was still done
15:55:50 <rhochmuth> ahhh, got it
15:56:13 <kornica> witek: but in the front of APIs (I mean, is it like tenant and project are mentioned are possible parameters you can send to nova over HTTP)
15:56:24 <witek> yes
15:56:50 <kornica> well...that is...hmm...have no word :P
15:57:11 <rhochmuth> projant
15:57:20 <kornica> ;p
15:57:23 <rhochmuth> tenect
15:57:29 <sc> ROTFL
15:57:33 <kornica> maybe, let's go with
15:57:35 <kornica> buddy, dude
15:57:40 <kornica> seems like it fits
15:57:42 <witek> https://developer.openstack.org/api-ref/compute/
15:58:17 <witek> tenant:238 project:162
15:59:02 <kornica> witek, U gess tenant_id is mentioed once and that's response body
15:59:19 <rhochmuth> i think we'll need to continue this discussion another time
15:59:41 <kornica> np
15:59:47 <rhochmuth> i'll look into another meeting time for next week
15:59:58 <rhochmuth> bye everyone
16:00:14 <witek> bye
16:00:18 <kornica> bye
16:00:26 <rhochmuth> #endmeeting