15:00:52 #startmeeting monasca 15:00:53 Meeting started Wed May 25 15:00:52 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:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:57 The meeting name has been set to 'monasca' 15:01:14 o/ 15:01:17 o/ 15:01:18 o/ 15:01:20 hi \o 15:01:20 o/ 15:01:22 o/ 15:01:22 o/ 15:01:24 o/ 15:01:24 o/ 15:01:25 o/ 15:01:25 o/ 15:01:25 o/ 15:01:26 o/ 15:01:36 o/ 15:01:37 impressive 15:01:40 o/ 15:02:06 agenda is at, https://etherpad.openstack.org/p/monasca-team-meeting-agenda 15:02:14 1. Discuss mid-cycle 15:02:14 2. Discuss adding the ability to publish logs to Kafka topics based on a list of dimension filters and keystone roles. For example, if operational logs and audit logs need to be stored in separate Kafka topics (TSV - HPE) 15:02:14 3. Reviews: 15:02:14 https://review.openstack.org/#/c/301355/ (agent hang fix) 15:02:14 https://review.openstack.org/#/c/286281/ (kv hint) 15:02:14 4. Deterministic alarms 15:02:14 5. Periodic notifications 15:02:43 So, it looks like i can travel to wherever we decide to host 15:02:49 the mid-cycle 15:03:09 but, from last week, it looks like we can't all travel to the same location at the same time 15:03:27 and for the most part it was split down the center 15:03:31 will probably need to allow virtual either way 15:04:09 i think my preference is to run it all remote this time around 15:04:28 inclusivity is more important to me 15:04:31 works for me 15:04:35 ok with me too 15:04:38 and it is hard to justify travel for just half the team 15:05:05 after the barcelona summit the mid-cycles will be predefined 15:05:13 by the openstack organization 15:05:32 and i think at that point everyone should push hard to make the design summits 15:05:39 I was against travel, but now that the TSA has vastly been improved.... 15:05:43 i think the date is sometime in february 15:05:48 and forgot where 15:06:09 glad to hear TSA has been improved. 15:06:18 so, unless anyone objects, let's do another remote mid-cycle in july 15:06:24 we just need to decide on the week 15:06:51 let's fight against time zone :-) 15:07:16 well, we can also mixup the mid-cycles to do half morning 15:07:18 half night 15:07:35 so folks in Asia time-zone are taken care of too 15:07:56 thanks! 15:08:00 great! 15:08:00 np 15:08:32 are any of the weeks preferable? 15:08:59 either works for me -- 7/18 or 7/25 15:09:29 well, let's wrap up on the date next week 15:09:36 not everyone is here 15:09:56 and maybe we can modify the doodle 15:10:02 good idea 15:10:28 ok, so i'll close on this for now, and move on to agenda 15:10:40 tsv: are u here? 15:11:02 yes 15:11:16 #topic logging api 15:11:21 the floor is yours 15:11:28 thanks 15:12:06 i wanted to discuss adding support for publish logs to specific kafka topics based on filter criteria (using dimensions) 15:12:46 this is to differentiate audit logs from operational logs, for example, where the topic retention could be different for audit logs 15:13:19 so instead of single topic in api - rather multiple topics detected from logs or fallback to default ? 15:13:36 correct 15:13:49 so, basically we could use a diemsion such as log_type = log or audit 15:13:51 sdake, i see we already have support for multiple topics, but cannot filter 15:13:59 yes 15:14:02 and audit logs would end-up on a separate topic 15:14:17 yes - there are multiple topics supported but all messages goes for all topics 15:14:28 as you mentioned - that's not selective 15:14:30 audit topic would potentailly have a different retention period 15:14:55 sounds like a nice idea 15:14:57 so, i think the idea is pretty simple, and justification and pretty clear 15:15:01 +1 15:15:14 thanks tomasztrebski 15:15:17 +1 15:15:27 and who will consume this new topics? 15:16:07 kamil, in our implementation, logstash filter would read from this topic and forward to a different Elasticsearch index 15:17:29 could you not filter directly in kibana? 15:17:30 you mean that the difference between the audit log and current log is only the retention, right? 15:17:48 I think thay could but that does not resolve problem of retention 15:17:57 koji, if Kafka security is enabled, the ACLs could be different too 15:18:35 i think there are multiple differences, with retention being probably the main motification 15:18:42 motiivation 15:18:44 tomasztrebski, yeah that's true 15:18:46 at first, i thought that you propose the feature for the customer, like cloud trail of AWS 15:19:00 no, this is all internal 15:19:10 ok, thank you 15:19:28 tomasztrebski, why do you say that ? kafka supports per topic retention settings right ? 15:20:30 tsv: tomasztrebski was answering my question 15:20:55 I am just thinking on using dimensions for that 15:20:59 kamil, got it thanks 15:21:19 if that's the routing - perhaps more verbose approach and simple add routing property into the log 15:22:00 also Kamil - there's a question of an idea of log-metrics where logs needs to go through particular topic in order to be transformed into metrics if certain severity happens 15:23:01 tomasztrebski: are you proposing that we add a spefic field, or just use dimensions 15:24:02 a think a field is easier to analyze in logstash 15:24:27 almost seems like it might be a better thing as a field 15:25:02 but only because when I think of dimensions, I think of metadata about my metric, not details about how it is handled 15:25:12 slogan: agree 15:25:16 i agree on that, might be better as a field. 15:25:24 the dimensions have been really about identity 15:25:39 if we find the need for more control data, perhaps there is some other thing that is a sibling to dimensions for that 15:25:56 so, a "type" field might be preferred 15:26:07 in metrics there is value_meta, but I don't think that's suitable 15:26:18 tomasztrebski: agree 15:26:47 or "handling": { "type": xyz, "retention": abc, ...} 15:27:01 something like that 15:28:18 in addition to the field (or dimension), don't we also need a keystone role ? for example, if we want to restrict write access to the audit topic ? 15:29:15 not sure we need a role, but that could be a separate discussion 15:29:25 so, i would like to get to rest of agenda 15:29:30 rhochmuth, ok 15:29:37 tsv: can you submite blueprint 15:29:45 thanks, sure will do 15:29:49 also I think that that might suit monasa-common quite nice, if you don't see any objections 15:29:49 then we can discuss, comment further 15:30:07 oh...ok sorry, I didn't see that we are done with this for now...sry 15:30:15 np 15:30:20 tomasztrebski: sure, thanks all for the support 15:30:27 i'm rushing us through 15:30:40 please distribute the blueprint to us. thx 15:30:40 i think a field is the general concensus 15:30:58 then slogan's idea is a good one too 15:31:10 rhochmuth: ok 15:31:12 possibly making it a dictionary to allow for additional attributes 15:31:40 although, i would prefer calling the new field something like attributes, rather than handling 15:31:47 yep 15:31:57 or just "meta" 15:32:03 but, in gneral, i think we hace some concensus/direction 15:32:17 meta, also might be nice 15:32:27 ok, need to move on 15:32:41 #topic reviews 15:32:48 https://review.openstack.org/#/c/301355/ (agent hang fix) 15:33:03 that's me -- how do you guys think that's looking? 15:33:03 so, i think this is ready for merging 15:33:19 there are several +1's from the hpe tam 15:33:22 team 15:33:22 tested it over the weekend, didn't see any errors or missing metrics 15:33:34 tomasz: you had looked at earlier 15:33:41 are you ok with a merge? 15:33:48 good to hear, we are hitting that bug a bunch, but we deployed that fix on a staging node, no hangs yet 15:33:50 thanks rbrndt 15:34:09 I've had it running for 3 days and never saw anything that would suggest that agent has stopped 15:34:26 tomasztrebski: thx for all the testing 15:34:32 +1 15:35:07 tomasztrebski: if you +1, i'll merge it 15:35:50 so, related to that review, we had talked about multi-processing/threading the plugins 15:36:04 so all plugins would run as their own thread/process 15:36:24 bklei: are you planning on continuing with that development 15:36:52 or is this an area where the joe/michael would work on? 15:36:56 i'm not sure about that rhochmuth -- i thought that was joe 15:36:58 yeah 15:37:07 I think that the idea is in overall very good - to sandbox each plugin 15:37:20 Yeah, I think the plan was for Joe to take over from here 15:37:33 joe ok with that? 15:37:43 ok, i don't think joe is here, but will follow-up with him and hoppal 15:37:49 cool 15:37:58 i think he is ok, just the time thing 15:38:05 sure 15:38:17 tomasztrebski: agree 15:38:42 ok, so will close on this topic, merge current code, and hoe/hoppal to follow-up 15:38:45 joe 15:38:51 cool, thx 15:39:04 https://review.openstack.org/#/c/286281/ (kv hint) 15:39:20 me again -- i think this one's been sitting a while 15:39:24 so, i'll need to take another look, but it sounds like you think it is ready for a merge 15:39:36 will try and review again today 15:39:49 yeah -- ryanb did some testing, didn't see any improvement, but didn't hurt either 15:39:59 right 15:40:05 yup 15:40:06 sorta taking vertica support at their word 15:40:13 but it is hard to test know in this case 15:40:22 yeah 15:40:27 so, agree, if vertica recommends, then we should enable 15:40:36 hopefully you'll see an improvemnt if prod 15:40:39 that's what i'm operating on 15:40:44 #topic Deterministic alarms 15:41:16 tomasztrebski: looks like some code is ready for merging 15:41:48 monasca-common here is ready to merge IMHO and without it I cannot proceed with thresh and api 15:41:55 https://review.openstack.org/#/c/292753/ 15:42:11 I notice thresh failed with the current common changes 15:42:21 and I tried building locally with the same result 15:42:54 for api - I've just fixed one last issue with tempests so that should be fine as well, thresh and ui are finished for me as well 15:42:55 don't know if the error is in the thresh or common change though 15:43:15 hmm...I haven't looked at thresh that much assuming that lack of certain fields in model is causing that issue 15:43:50 and looking at log from gate right now it looks like that actually the problem 15:44:06 for instance: cannot find symbol 2016-05-20 13:01:00.659 | [INFO] symbol: method isDeterministic() 15:45:03 so, if common is merged, gate should pass 15:45:32 as your review for common i'm assuming adds isDeterminstic 15:45:49 is that correct" 15:46:26 that and couple other things like grammar 15:46:57 rbrndt: is it possible your local build didn't get installed into maven repo? 15:47:19 i can try building again, perhaps it was misaligned 15:47:29 i think you need to pull monasa-common, and then mvn install 15:47:37 yeah, I did that 15:48:15 so, i'll let you reverify and then see if we can resolve 15:48:26 if resolved, then will merge 15:48:42 tomasztrebski: sound good? 15:48:55 so, will wait for all clear from rbrndt 15:50:38 should we move on 15:51:07 sorry, just checking if we can close for now, and move on next topic 15:51:39 i have nothing to add, will reverify that my self as well and post a comment with my results 15:51:53 tomasztrebski: thx 15:52:04 #topic Periodic notifications 15:52:28 so, mhoppal, what is status 15:52:40 and is this ready for merging, presumably 15:52:46 the api review 15:52:49 is ready for reviews 15:52:50 or more development required 15:52:51 and merging 15:52:58 the client, ui and notification 15:53:03 have some comments to address 15:53:12 ok, thanks 15:53:16 client should be ready today 15:53:32 thx 15:53:55 will move on, just wanted to give folks a heads-up on that bit of work since it is a new feature too 15:54:08 #topic open 15:54:25 we have about 5 minutes left 15:54:29 may I put in a quick shameless plug for the Monasca-Transform review (https://review.openstack.org/#/c/315245)? ;-) 15:54:41 FlintHPE: thansk for reminder 15:54:48 turns out i didnt' have +2 privs 15:54:54 will get that today and merge 15:55:01 cool...thanks! 15:55:02 sorry about delay 15:55:13 no worries 15:55:48 I wrote blue print about monasca-ui pagination style. https://blueprints.launchpad.net/monasca/+spec/horizon-pagination-style 15:56:12 thanks shinya_kwbt 15:56:48 To adopt horizon pagination style needs to api sort option. 15:57:09 needs to chanage sort option or add new option. 15:57:34 so sorry, i didn't review, but i'll review, and we should discuss next week 15:57:42 does that sound ok 15:57:52 Thanks. 15:58:02 so, this can be first topic next week 15:58:43 rbrndt: you''ll want to review this one too 15:58:56 alright 15:59:21 so, time has almost up again 15:59:40 any last gasp topoics 16:00:00 i keep thinking we need more time 16:00:25 i have a meeting after this, but i'll be in the monasca room 16:00:30 going to close down the meeting 16:00:34 thanks everyone 16:00:42 thanks & bye 16:00:50 thanks 16:00:58 bye hosanai, koji 16:01:12 #endmeeting