15:03:56 #startmeeting monasca 15:03:58 Meeting started Wed Sep 21 15:03:56 2016 UTC and is due to finish in 60 minutes. The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:04:01 The meeting name has been set to 'monasca' 15:04:01 lags...lags everywhere.... 15:04:06 there it is 15:04:28 agenda Agenda for Wednesday September 21, 2016 (15:00 UTC) 15:04:28 1. Cooperation with ELK => https://discuss.elastic.co/t/multitenancy-for-openstack-cloud-with-keystone/60577 15:04:28 1. Moving kibana plugin into openstack namespace 15:04:28 2. Reviews 15:04:28 1. Are merges permitted/allowed for regular fixes - or just bug-fixing ? 15:04:29 2. Plugins for monasca-notification => status ? 15:04:29 3. https://review.openstack.org/350470 15:04:30 4. https://review.openstack.org/#/c/343818/ => Question from Igor @ PS_4 15:04:30 3. Question: Is anyone using OAuth with Keystone ? 15:04:48 sorry about the delay 15:04:52 let's get into the agenda 15:05:01 #topic Cooperation with ELK => https://discuss.elastic.co/t/multitenancy-for-openstack-cloud-with-keystone/60577 15:05:24 not much to add, apart from they seem very "eager" to discuss anything... 15:05:59 question is, do we want to try more and write to them or are we looking for something different IMHO 15:06:57 that wasn't a very informative answer 15:07:07 i think we should follow-up 15:07:41 i don't think they understand what we are trying to do 15:07:52 seems to think that Shield is there solution 15:08:12 but, i don't think they understand OS and what we are trying to do with MOnasca Log API 15:08:40 the other option is to hop on their IRC channel 15:08:53 well it's there product...seems a fair reason to say Shield all the time... 15:09:13 i'm not sure they are trying to be close-minded about this 15:09:21 i know the response seems harsh 15:09:40 i'll try to get in touch with them 15:09:43 but, they might have misunderstood what we are doing 15:09:57 witek: thanks 15:10:14 can you cc me if you send email 15:10:19 sure 15:10:22 or arrange a meeting time if that occurs 15:10:43 ok, let's hope that will work 15:11:18 or, we could try their forum 15:11:22 i'm assuming they have one 15:11:32 the post there is their forum 15:11:34 actually 15:12:29 ohh, i missed that 15:12:44 i guess that rules out that possiblity 15:12:51 on to plan B 15:13:25 #topic reviews 15:13:37 Are merges permitted/allowed for regular fixes - or just bug-fixing ? 15:13:50 we are trying to lock-down 15:14:10 i don't think we should be adding any significant new features right now 15:14:17 it's not clear what can be merged or not at least for me 15:14:20 i need to update/tag it sounds like 15:14:43 so, prior to this morning, i thought that the branches for monasca had already occured 15:14:54 they had occured for the python-monascaclient 15:15:05 but, they weren't done for all the other libraries 15:15:29 so, based on email from witek, it looks like i can apply tags for the newton release still 15:15:40 the branches won't occur until sometime in oct 15:15:44 i believe the 6th 15:15:59 of october 15:16:19 so, after the tags are done, then i think master could open up again 15:16:33 does that make sense? 15:16:48 yes 15:17:01 so, i'll get tags setup in newton 15:17:35 i can push the changes in python-monascaclient to stable/newton 15:17:44 thanks witek 15:18:12 so after the tags are done, then i'm not sure we want to open the flood gates on master 15:18:36 but we might be able to start getting new features in on master 15:18:59 the only issue i have is if we fix a bug prior to branches being created 15:19:16 not having to worry about new features would be nice 15:19:23 that had already gotten merged 15:19:47 i'm guessing from a pure openstack viewpoint though, if you look at other projects 15:19:50 master is locked down 15:20:16 can we move on? 15:20:22 so in other words only those changes that are marked with bug-fix could be merged 15:20:32 right now we have code-freeze until lifted ? 15:20:40 correct 15:21:03 and code-freeze is lifter after stable/newton branches will be created ? 15:21:27 i'm not 100% positive 15:21:29 on that 15:21:55 as i think we could start getting new features merged again, but it would be nice to not worry about that until the branches are created 15:22:09 so i think the openstack answer/way is to lock-down until branches are done 15:22:35 ok, no further questions 15:22:49 the defense rests 15:23:00 ;-) 15:23:03 your honor 15:23:34 #topic Plugins for monasca-notification => status ? 15:23:55 these are still in progress, at least the reviews that are posted 15:24:10 looks like i can't merge right now either based on the previous discussion 15:24:27 haneet is going to add custom formatting to the email plugin 15:24:40 he might have published a review yesterday that addresses that 15:24:54 the jira plugin potentially needs a lot more work 15:24:59 we did a review last week 15:25:11 and there were several important points raised 15:25:17 that need to be resolved prior to merging 15:25:47 does that description help? 15:25:54 or should i supply more 15:26:09 nope, that is very informative, thx 15:26:48 here are the notes/questions that haneef wrote down 15:26:49 1)      [endif]We are currently opening the ISSUE when the problem re-occurs if it is already in CLOSED or RESOLVED state.  There is an opinion that we should not be doing that, instead  we should create a new one.   How about going with config option to  either create new one or to open the resolved one? 15:26:49 [if !supportLists]2)      [endif]Flooding issue. How are we going to deal with the flooding?  Monasca doesn’t have way to deal with flooding.   In case of EMAIL, we can just select and delete all the mails, but if so many issues are created  how are we going to clean this out? 15:26:49 [if !supportLists]3)      [endif]Monasca creates  notification when state = ( ALARM, OK, UNDETERMINED).   The problem is UNDETERMINED state.  Undetermined state  has a potential to create lot of notification.  (e.g during upgrade or reconfigure when services are stopped and restarted).   Are we going to restrict the plugin only to “ALARM” state? 15:26:49 [if !supportLists]4)      [endif]Do we need to close the issue when  ALARM  state = OK? 15:26:49 [if !supportLists]5)      [endif]We are creating  issues with the title “Helion OpenStack Alarm:  Alarm raised for with severity. For predefined  generic alarm definition such has “httpcheck” we will be getting many alarms with the same title.  How useful is this from customer perspective?    There should be a way for  customer to know that “httpcheck or processcheck” failed for nova, key 15:26:50 [if !supportLists]6)      [endif]If we created an issue, then we need to have well known search criteria.  Where are we going to include that search criteria?   Will the customers be using “Dimension” for search criteria? 15:26:50 [if !supportLists]7)      [endif]How about JIRA performance?  If  many issues are created, how is JIRA going to perform? 15:27:15 that didn't copy/paste well, but hopefully it is parsable 15:28:04 whoa...that's a lot of open questions.... 15:28:09 also, see the blueprint 15:28:34 if you need more context let me know 15:28:53 #topic https://review.openstack.org/350470 15:29:21 i guess we talked about that one last week 15:29:34 craig added a minor comment that was resolved 15:29:46 that's me... guess I am very stubborn about that ;-) 15:29:49 i think it is ready to merge 15:29:58 i'll ping craig again 15:30:22 and also joe 15:30:29 sorry about the delay 15:30:49 #topic https://review.openstack.org/#/c/343818/ 15:31:10 i agree with witek's last comment 15:31:38 also, needs a lot more reviews 15:31:49 me too, but the item in question goes to one of the Igor's comment 15:31:54 and only python code 15:31:56 no java 15:32:11 and only influxdb 15:32:13 wasn't sure what was the correct answer 15:32:16 … 15:32:19 my question was about sporadic be part of the 15:32:29 identity of the metric 15:32:45 The way that it is done now, sporadic is just a flag and nothing more and after the first time that the metric is published using sporadic=True, this metric will never be non-sporadic again. 15:33:35 If sporadic is part of the metric identity, we can have two different metrics with the same name and dimensions, but one sporadic and the other non-sporadic. 15:34:15 I'd like to know your opinion about it, rhochmuth 15:34:36 we havent' discussed this feature in a while 15:34:47 so i'm trying to recall all the relevant topics 15:34:59 kind of blurred all that is now...that;s why bringing it up here 15:35:32 i don't think that sporadic shoudl be treated as identity 15:35:49 like dimensions are treated 15:36:08 in general, this is information about the metric 15:36:13 not it's identity 15:36:23 monasca-thresh would have to be changed as well 15:36:35 in the logging api, we also had a blueprint to add properties or attributes 15:36:40 igorn: perhaps it'd be useful to make a blueprint for sporadic stuff where all that's relevant would be kept 15:36:41 tsv created a blueprint for that 15:36:57 and i was wondering, to be consistent, if we should do something simialr for metrics too 15:37:27 in the case of the logging api, we wanted to supply additional information with the log message that could be used for routing opurposes 15:37:39 ok. Sounds better to me. 15:37:41 basically, whether the log messages was an audit log or not 15:38:01 that information would be used for publishing to a different topic 15:38:11 becuase audit logs should be treated differently 15:38:17 they might have different retention periods 15:38:21 for example 15:38:30 but, we also discussed a lot of other possiblities 15:38:43 in addition, we discussed the metrics 15:38:58 so, sporadic fits in that same category 15:39:12 other ideas were to specify a priority on a metric 15:39:35 for example, we now support the "last" function in the threshold engine which can be used to immedialty transition alarms 15:40:04 but, it might also be nice to specify that those metrics go through a topic in Kafka that has a higher priority 15:40:16 or isn't backed behind everything else 15:40:22 all the other metrics that is 15:40:49 so, i think we have to put some more serious thought into how to handle properties/attributes 15:40:59 and it would be nice to make that consisten betwen logging and metrics 15:41:13 which since we haven't committed anything yet should be possible 15:41:28 witek: yes, there has to be suport in monasca-thresh too 15:41:36 of course, I'll be waiting for. 15:41:46 my fingers are getting tired 15:41:52 i might have to stretch a bit 15:42:00 you kind of went with the flow... 15:42:01 ;-) 15:42:09 lol 15:42:19 i'm starting to cramp up 15:42:29 left index finger cramp 15:42:53 medic, medic 15:43:03 is there a doctor here ? 15:43:17 oh wait...wasn't it you who was called Dr. Monasca ? 15:43:31 i can't o9perate on myeself 15:43:42 lol 15:44:07 ok, back to reality, take deep breath 15:44:28 so, how about we get back to this topic in a couple of weeks 15:44:35 we can't merge it now 15:44:39 anyway 15:44:49 just to wrap all up 15:44:49 and i think it is going to take some more serious discussions 15:44:56 ok. Maybe we can discuss a bit more about it at the summit :- 15:45:02 :-) 15:45:05 igor will create a blueprint for sporadic putting everything important there 15:45:06 sure, that woudl be a good topic 15:45:15 ignor: are you going? 15:45:15 we will think on properties/atrributes 15:45:17 and routing in kafka 15:45:18 ? 15:45:31 yes, that woudl be another related topic 15:45:36 as we have the bp in place 15:45:57 tomasztrebski: ok, let me know when it is ready 15:46:22 rhochmuth: yes, I'll be there. 15:46:30 igorn: sounds good 15:46:35 we can discuss there 15:46:43 witek and tomaz will be there too 15:46:47 and others 15:46:52 sure 15:47:24 #topic Question: Is anyone using OAuth with Keystone ? 15:48:06 yeah, that's my I was trying to figure out using keystone's oauth for grafana , version 3.x I guess because there were generic_auth plugin is 15:48:07 i have never heard of that before 15:48:59 it's just not the important, since our PO decided that's too big an effort for now for us 15:49:07 I should've removed this topic from agenda 15:49:18 no problem 15:49:28 i guess that is the end of the topics 15:49:40 at this time i woudl like to open it up for discussions 15:50:00 does anyone have anymore topics 15:50:12 do you have some new info about design sessions? 15:50:18 just in case, i schedule another monasca/cassandra meeting for monday 15:50:28 i have six slots available 15:51:02 but i don't have a specific agenda yet 15:51:15 we had some items we discussed last week 15:51:17 and today 15:51:30 so, i think we'll cover all of them 15:52:04 the time is also not fixed yet, is it? 15:52:18 i think it is fixed 15:55:02 tomasz: you were waiting for a meeting for events 15:55:12 the problem is on my end again 15:55:34 i'm not sure what resources i can commit to this 15:56:08 so, everything was looking good for staffing this effort, but now it is on the back burner again 15:56:20 so, i didn't send an email 15:56:24 yeah, I guess we will just have it wait -) 15:56:25 ;-) 15:56:31 it also looks like cassandra will be more difficult 15:57:00 ddieterly has been looking at cassandra along with the rest of us at hpe 15:57:08 that is what we woudl like to discuss on monday 15:57:12 at the next update 15:57:22 if you would like to attend please let me know 15:57:33 that is a skype/lync session 15:58:50 i guess that is all for today 15:58:58 thanks everyone 15:59:04 thanks, see you and nice day 15:59:07 evenings too 15:59:08 ;-) 15:59:09 bye 15:59:13 bye 15:59:17 bye ;-) 15:59:34 #endmeeting