15:00:35 <rhochmuth> #startmeeting monasca
15:00:35 <openstack> Meeting started Wed Jun  8 15:00:35 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:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:40 <openstack> The meeting name has been set to 'monasca'
15:00:46 <rhochmuth> o/
15:00:50 <koji> o/
15:00:51 <Kamil__> o/
15:00:52 <rhochmuth> https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:00:52 <bklei> o/
15:00:54 <arturbasiak> o/
15:00:57 <tomasztrebski> o/
15:01:00 <hosanai> o/
15:01:00 <rhochmuth> Agenda for Wednesday June 8, 2016 (15:00 UTC)
15:01:00 <rhochmuth> 1.	Mid-cycle planning
15:01:00 <rhochmuth> 2.	Summit proposals
15:01:00 <rhochmuth> 3.	Reviews
15:01:00 <rhochmuth> 1.	https://review.openstack.org/#/c/286281/
15:01:01 <rhochmuth> 2.	https://review.openstack.org/#/c/319887/
15:01:01 <rhochmuth> 3.	https://review.openstack.org/#/c/325226/
15:01:02 <rhochmuth> 4.	https://review.openstack.org/#/c/254643
15:01:02 <rhochmuth> 4.	Self-monitoring for log-api => https://review.openstack.org/#/c/327000/
15:01:11 <rbak> o/
15:01:18 <tsv> 0/
15:01:20 <thatsdone> o/
15:01:22 <rhochmuth> hi everyone, this is monasca
15:01:22 <shinya_kwbt> o/
15:01:33 <slogan> o/
15:01:34 <ericksonsantos> \o
15:01:40 <tgraichen> o/
15:01:44 <rhochmuth> i've posted the agenda
15:02:09 <rhochmuth> i think we should get through some logistical issues first, then cover the reviews and other topics
15:02:14 <iurygregory> o/
15:02:24 <rhochmuth> #topic mid-cycle planning
15:02:31 <tomasztrebski> instantly I remembered the pit scene in 300... 'this is monascaaaa' :D
15:02:56 <rhochmuth> tomasztrebski: i was hoping someone would get it
15:03:02 <arturbasiak> :D
15:03:26 <rhochmuth> so, we decided to do a remote mid-cycle
15:03:40 <rhochmuth> what we need to decide is the week, days and time
15:03:58 <rhochmuth> also, i said i would split the time to take care of folks in other time-zones
15:04:06 <fabiog> o/
15:04:09 <rhochmuth> so, they don't have to pull 2 or 3 all nighters in a row
15:04:45 <rhochmuth> fabiog: should we create yet another doodle to vote on the week
15:04:55 <rhochmuth> days and times
15:05:17 <fabiog> sure we can, but if everybody can attend the week we selected for SJC, then we can run sessions in the morning
15:06:01 <rhochmuth> so, is the SJC week a problem for anyone?
15:06:06 <rhochmuth> i don't have the days
15:06:27 <bklei> we'd said 7/19 and 7/20
15:06:35 <bklei> for SJC
15:06:45 <rhochmuth> that works for me
15:06:48 <bklei> ditto
15:06:51 <fabiog> bklei: yes those were the dates
15:07:08 <fabiog> we could have sessions in the morning
15:07:15 <rhochmuth> then, do we want to split the times
15:07:55 <rhochmuth> i'm just trying to accomdate folks in different timezones better
15:08:06 <rhochmuth> or do we want to just tough it out for two days
15:08:10 <rhochmuth> at the same time
15:08:19 <rhochmuth> this is monascaaaa
15:08:31 <slogan> probably no good answer, pick one :-)
15:08:40 <fabiog> rhochmuth: if you want to accomodate Japan and Europe I think only early morning Pacific would do it
15:09:17 <rhochmuth> is that really the best time overall then
15:09:54 <bklei> works for me -- any objections?
15:10:28 <rhochmuth> i'm more worried about folks in europe and japan
15:10:45 <rhochmuth> are you ok with the proposal
15:11:46 <hosanai> i'm checking our local time (early morning Pacific)
15:11:53 <koji> what time will it start on your time?
15:12:08 <tgraichen> dates should be fine and early morning pacific would be best for us europeans :)
15:12:26 <mrhillsman> o/
15:12:27 <rhochmuth> 7 or 8 AM PST, i believe
15:13:10 <shinya_kwbt> Any time OK for me. Because I will be off to go company :-)
15:13:29 <koji> thank you, that's good for me
15:13:42 <hosanai> it's works for me!
15:13:49 <rhochmuth> ok, thanks, let's move on, but if anyone has any issues, please let me know
15:13:59 <rhochmuth> sounds like it is going to work out
15:14:26 <rhochmuth> fabiog: are we going to use your webex again?
15:14:54 <fabiog> rhochmuth: yes
15:15:00 <rhochmuth> fabiog: thx!
15:15:08 <fabiog> rhochmuth: np
15:15:22 <rhochmuth> we'll do somethign similar to the last one with announcments, etherpad, …
15:15:36 <rhochmuth> #topic: summit proposals
15:15:41 <fabiog> rhochmuth: should be do 7am to noon PDT for the two days?
15:15:48 <rhochmuth> sounds good
15:16:12 <rhochmuth> i just wanted to let folks know that session proposals for the barcelona summit are open
15:16:31 <fabiog> rhochmuth: I will set-up the webex later today and post it in the mailing list
15:16:38 <rhochmuth> fabiog: thx
15:17:19 <rhochmuth> i believe the summit proposal session closes around mid july, but just check on dates to be sure and if you are planning on proposing anything
15:17:31 <rhochmuth> good summit to possibly watch messi play
15:17:56 <hosanai> oh, nice :-)
15:18:24 <rhochmuth> so, are there any other logistic topics, before we get into reviews
15:18:42 <rhochmuth> any noteworthy items to note
15:19:18 <rhochmuth> maybe just a reminder, but there are still a lot of reviews in progress
15:19:38 <rhochmuth> the hpe team is doing more than our fair share of them
15:20:33 <rhochmuth> #topic reviews
15:20:42 <rhochmuth> https://review.openstack.org/#/c/286281/
15:20:56 <bklei> that's me -- been sitting a while
15:21:01 <rhochmuth> i reviewed this morning, everything seems to be fine
15:21:11 <bklei> yeah -- should be benign
15:21:15 <rhochmuth> yes, there are a lot of reviews sitting for a while
15:21:39 <bklei> i guess anyone object to merging ^^?
15:21:54 <rhochmuth> i +1'd that review, so i think it is ready for merging
15:22:08 <bklei> bueno
15:22:15 <rhochmuth> i agree it is a benigs growth
15:22:22 <bklei> :)
15:22:33 <bklei> have to wait for the lab results
15:23:28 <rhochmuth> yes, hopefully the proctologist will concur
15:23:38 <rhochmuth> took me a while to come up with that one
15:23:41 <bklei> oh man
15:23:42 <rhochmuth> i hope you appreciate it
15:23:53 <bklei> i do
15:24:11 <rhochmuth> so, i'll merge it
15:24:28 <rhochmuth> done
15:24:29 <bklei> that analogy indicates pretty clearly where the code came from
15:24:31 <bklei> thx
15:24:39 <rhochmuth> lol
15:24:57 <rhochmuth> this will be the crudest monasca meeting on record
15:25:07 <bklei> shaping up that way
15:25:11 <rhochmuth> https://review.openstack.org/#/c/319887/
15:25:23 <rhochmuth> i'm still catching up on this one
15:25:43 <rhochmuth> looks like no +1's yet
15:25:46 <tomasztrebski> ah..ok :)
15:25:57 <tomasztrebski> it's been rebease recently, Artur's been testing this
15:26:31 <rhochmuth> ok, sounds good
15:26:50 <rhochmuth> so, a while ago i recall we had a discussion on if log messages dont' fit what shoudl happen
15:27:07 <rhochmuth> shoudl we return an error, or try to handle as many as possible
15:27:14 <rhochmuth> so, you end-up truncating
15:27:22 <rhochmuth> how will the client know that there is a problem
15:27:42 <tomasztrebski> truncated property is added to the log object
15:28:10 <tomasztrebski> so tenant will see which logs were truncated
15:28:16 <rhochmuth> so, if truncated, then do they get the offset on the number that were processesed/accepted
15:28:37 <tomasztrebski> I am not sure I follow
15:29:11 <rhochmuth> if the logs are truncated, and only some are accepted
15:29:25 <rhochmuth> can they get enough info to process the one's that weren't accepted
15:29:59 <rhochmuth> maybe i should have reviewed closer, so my questions are not correct
15:30:10 <rhochmuth> or they dont' make any sense
15:30:40 <tomasztrebski> I think that would depend on data user puts into log object, dimensions are one thing that can be added
15:30:46 <tomasztrebski> another thing is message
15:31:07 <rhochmuth> so, you return truncated=true if message is truncated
15:31:15 <rhochmuth> i'm just wondering how the client can recover
15:31:21 <tomasztrebski> yes that is added as a property to the log itself
15:31:36 <rhochmuth> it doesnt' look like there is an offset of the logs that were sent
15:31:47 <rhochmuth> so the client doesnt' know the logs that didn't make it
15:32:06 <rhochmuth> again, maybe silly questions do to lack of understanding
15:32:15 <tomasztrebski> that depends on the case...truncating can means that there is either loop in logs or something was logged that sholdn't be logged
15:32:25 <tomasztrebski> anyway our use cases estimate large log records
15:32:44 <tsv> rhochmuth: i see value in your question. Would that be an issue for say audit logs ? would there be compliance concerns in truncating audit messages ?
15:32:52 <tomasztrebski> don't ask me how, but I've been told 1 mb o.O
15:33:23 <tomasztrebski> there's no offset that client is sending, but I believe he could have done that and append it to log object
15:34:00 <tomasztrebski> hower such log can be later on filtered in kibana and examined
15:34:07 <tomasztrebski> for instance
15:34:13 <tomasztrebski> or any other database for that matter
15:34:44 <rhochmuth> i guess my concern/question is that if you truncate and return true, other than notification to the client, is there any other recovery that can be done
15:34:58 <rhochmuth> any actions that the client can take to fix
15:35:36 <tomasztrebski> I've been thinking on returning processing result -> {ok: x, truncated: y, rejected: z, lost: w}
15:35:38 <tomasztrebski> to the client
15:35:39 <tomasztrebski> from v3
15:36:01 <tomasztrebski> but that is rather top level idea without any specifics right now
15:36:35 <rhochmuth> ok, i'll try and catch-up on this review today as well
15:36:49 <rhochmuth> and leave comments if any
15:36:58 <tomasztrebski> will be happy to discuss that
15:36:59 <tomasztrebski> :)
15:37:06 <rhochmuth> sounds good
15:37:16 <rhochmuth> https://review.openstack.org/#/c/325226/
15:37:46 <tomasztrebski> yes, another one that we've been working with Artur in agent
15:38:03 <tomasztrebski> I got only that, basically agent allows to pass on user that it will run under
15:38:10 <tomasztrebski> that user's group is used during monasca-setup
15:38:13 <tomasztrebski> but only group
15:39:06 <rhochmuth> sounds ok to me
15:39:28 <rhochmuth> will tag a couple from hpe to review
15:39:36 <rhochmuth> bklei: does that sound ok to you?
15:39:58 <bklei> sorry, looked away
15:40:29 <bklei> yeah, that should be ok for us
15:40:53 <rhochmuth> so, if we get you and someone else from hpe to +1, should get merged
15:41:03 <tomasztrebski> thx
15:41:08 <bklei> ok, will take a closer look
15:41:13 <rhochmuth> https://review.openstack.org/#/c/254643
15:41:30 <rhochmuth> oh no, not this one again:-)
15:41:42 <tomasztrebski> that's old :D
15:41:51 <rhochmuth> it has only been in progress since dec 8th
15:41:58 <rhochmuth> i was checking on licensing
15:42:15 <rhochmuth> unfortunately, the individual doing the checking left
15:42:31 <rhochmuth> i reread the license
15:42:53 <rhochmuth> http://openjdk.java.net/legal/gplv2+ce.html
15:43:05 <rhochmuth> GNU General Public License, version 2,
15:43:05 <rhochmuth> with the Classpath Exception
15:43:20 <rhochmuth> "CLASSPATH" EXCEPTION TO THE GPL
15:43:20 <rhochmuth> Certain source files distributed by Oracle America and/or its affiliates are
15:43:20 <rhochmuth> subject to the following clarification and special exception to the GPL, but
15:43:20 <rhochmuth> only where Oracle has expressly included in the particular source file's header
15:43:21 <rhochmuth> the words "Oracle designates this particular file as subject to the "Classpath"
15:43:21 <rhochmuth> exception as provided by Oracle in the LICENSE file that accompanied this code."
15:43:22 <rhochmuth> Linking this library statically or dynamically with other modules is making
15:43:23 <rhochmuth> a combined work based on this library.  Thus, the terms and conditions of
15:43:23 <rhochmuth> the GNU General Public License cover the whole combination.
15:43:24 <rhochmuth> As a special exception, the copyright holders of this library give you
15:43:25 <rhochmuth> permission to link this library with independent modules to produce an
15:43:25 <rhochmuth> executable, regardless of the license terms of these independent modules,
15:43:26 <rhochmuth> and to copy and distribute the resulting executable under terms of your
15:43:26 <rhochmuth> choice, provided that you also meet, for each linked independent module,
15:43:27 <rhochmuth> the terms and conditions of the license of that module.  An independent
15:43:27 <rhochmuth> module is a module which is not derived from or based on this library.  If
15:43:56 <rhochmuth> So, basically this type of license means that we would have to examine every source file to ensure that the CLASSPATH exception to the GPL has been added
15:44:19 <tomasztrebski> I am not an expert but that sounds like a lot of work
15:45:00 <rhochmuth> I know GPLv2 is not allowed in OpenStack
15:45:21 <rhochmuth> it also isn't allowed by HPE or usually any company building a distribution
15:45:57 <tomasztrebski> I don't recall any issues with mail validation till now, so maybe it can be safely abandoned ?
15:46:07 <rhochmuth> so, the only way to take this is examine each source file
15:46:26 <jobrs> hi, I am the one who submitted this one
15:46:47 <jobrs> so there are problems with the validation (see description)
15:47:04 <rhochmuth> jobrs: is there another library or another way to resolve this
15:47:32 <rhochmuth> based on the above, hopefully the concerns are reasonable
15:47:42 <rhochmuth> or understood
15:48:07 <jobrs> but there is not just GPLv2, there is also CDDL
15:48:25 <jobrs> there is another way: use the python api implementation
15:48:31 <rhochmuth> yeah, i know, and oracle says
15:48:52 <rhochmuth> GNU General Public License, version 2,
15:48:52 <rhochmuth> with the Classpath Exception
15:48:52 <rhochmuth> 9:43
15:48:52 <rhochmuth> "CLASSPATH" EXCEPTION TO THE GPL
15:49:02 <jobrs> but it supports only a single kafka node
15:49:23 <rhochmuth> so, the only way to know if the CLASSPATH exception is applicable is to look at each source file for a disclaimer that was put there by Oracle
15:49:24 <jobrs> good point, so goodbye merge
15:49:41 <rhochmuth> unfortunately, it looks that way
15:49:53 <rhochmuth> i think examining source is an option
15:49:57 <rhochmuth> but painful one
15:50:13 <rhochmuth> and then Oracle is the only company that woudl be allowed to add that exception
15:50:34 <rhochmuth> so if someone else decided to add the exception, that would not be considered acceptable either
15:50:40 <rhochmuth> it is a mess
15:50:43 <fabiog> rhochmuth: we should stay away from GPL in general, Apache and MIT licenses are friendly
15:51:11 <rhochmuth> if there is another library to look at it i would like to see the change addressed
15:51:12 <jobrs> where is the Python API heading? can we expect support for multiple ZK/Kafka nodes soon?
15:51:43 <rhochmuth> as far as i know, multiple zk/kafka nodes are supported
15:51:52 <rhochmuth> what are you missing?
15:53:16 <jobrs> is think there is only a single-valued uri attribute in the config
15:53:25 <rhochmuth> tomasz: https://review.openstack.org/#/c/327000/
15:54:21 <tomasztrebski> yes, that's something new I had in mind for couple of months, just recently found time to work on it
15:54:29 <rhochmuth> jobrs: that sounds like an oversight
15:54:33 <rhochmuth> if it isn't supported
15:54:48 <rhochmuth> jobrs: do you have time to resolve
15:55:17 <rhochmuth> basically if kafka node 1 is down in a cluster of 3, you want the client to switch to another node?
15:55:31 <rhochmuth> tomasztrebski: looks good
15:55:47 <jobrs> yes, like in the java implementation where the configuration field holds a list of values
15:56:33 <rhochmuth> jobrs: i guess we didn't add that
15:56:34 <tomasztrebski> in python you can pass list of IPS that points to your nodes (comma delimited)
15:56:52 <tomasztrebski> internally kafka-python resolves that string into list of hosts
15:57:02 <rhochmuth> maybe we did add it?
15:57:17 <rhochmuth> sorry, havent' been in that code for a while
15:57:35 <tomasztrebski> we've been using 3 nodes kafka/zookeeper setup and that is how ips of those nodes were passed to configuration
15:57:49 <rhochmuth> tomasz: basically you are adding support for statsd to the log api, right?
15:58:08 <tomasztrebski> roland: yes, easiest and quickest way to post metrics from log processing into metric database
15:58:31 <rhochmuth> tomasz: looks good, i'll start reviewing is my canned response these days
15:58:45 <jobrs> ok, I will double check. the persister seems to support it.
15:58:48 <rhochmuth> but in general, it looks like the right approach
15:59:17 <rhochmuth> tomasz: so it sounds like you are saying the the python code already supports a kafka/zk cluster?
15:59:30 <rhochmuth> back to the other conversation
15:59:33 <jobrs> switching to statsd - I created some stated-instrumentation for the python-persister. I could submit it for review if there is interest
15:59:57 <tomasztrebski> If i understand what is kafka/zookeeper cluster - yes it does
16:00:01 <rhochmuth> so, e're going to have to wrap-up
16:00:02 <tomasztrebski> here's the code I mentioned => https://github.com/dpkp/kafka-python/blob/644a1141b0dd22e618277afe7b171b2f3fb8ca2d/kafka/conn.py#L718
16:00:14 <rhochmuth> i'll head over to #openstack-moansca for follow-up
16:00:16 <tomasztrebski> for resolving hosts for kafka connection
16:00:27 <rhochmuth> #endmeeting