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