15:01:12 <rhochmuth> #startmeeting monasca
15:01:13 <openstack> Meeting started Wed May 18 15:01:12 2016 UTC and is due to finish in 60 minutes.  The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:17 <openstack> The meeting name has been set to 'monasca'
15:01:26 <rhochmuth> o/
15:01:28 <rbak> o/
15:01:29 <tomasztrebski> o/
15:01:30 <rhochmuth> hi everyone
15:01:32 <fabiog> o/
15:01:33 <hosanai> o/
15:01:33 <koji> o/
15:01:35 <FlintHPE> o/
15:01:38 <shinya_kwbt> o/
15:01:39 <Kamil_> o/
15:01:41 <rhochmuth> agenda is at, https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:01:42 <bklei> o/
15:01:51 <rhochmuth> Agenda for Wednesday May 18, 2016 (15:00 UTC)
15:01:53 <rhochmuth> 1. Using Severity#CRITICAL for so called "latched" alarms instead of extending data model
15:01:53 <rhochmuth> 2. Mid-cycle meetup
15:01:53 <rhochmuth> 3. Vitrage update (Syd)
15:01:53 <rhochmuth> 4. monasca-transform update
15:01:53 <rhochmuth> 5. monasca-analytics update
15:01:54 <rhochmuth> 6. State of the gate?
15:01:54 <rhochmuth> 7. Update on dimensions resource?
15:01:55 <rhochmuth> 8. Update on api caching?
15:01:58 <fabiog> is FlintHPE the Flint I know?
15:02:09 <rhochmuth> before we get started, is there anything left over from last weeek
15:02:17 <FlintHPE> fabiog, yep!
15:02:18 <iurygregory> hi
15:02:20 <rhochmuth> the last i recall i frantically ended the meeting
15:02:55 <rhochmuth> ok, then let's work through the agenda
15:03:05 <rhochmuth> and maybe we'll have time left over this week
15:03:18 <rhochmuth> #topic 1. Using Severity#CRITICAL for so called "latched" alarms instead of extending data model
15:03:39 <rhochmuth> tomasz: is that from you?
15:04:19 <tomasztrebski> yes, it's mine
15:04:43 <tomasztrebski> I've been thinking how to implement that and such suggestion came up - instead of extending alarm definition model
15:05:04 <rhochmuth> hmmm, can't say i'm in favor of it
15:05:17 <rhochmuth> seems like we are overriding a parameter
15:05:43 <tomasztrebski> why ? it's more like add some meaning to CRITICAL alarms
15:06:12 <tomasztrebski> the main idea is to have alarms that require operator attention to leave ALARM state
15:06:41 <tomasztrebski> attention is likely needed if something so bad happened that it'd be best to check and double check
15:07:14 <tomasztrebski> thus CRITICAL severity
15:07:36 <rhochmuth> there are two things, the severity of an alarm, and whether it should stay in the ALARM state, after it has transitioned to it
15:07:37 <tomasztrebski> anyway that's a suggestion that would follow severity quite nice
15:07:47 <rhochmuth> seems like two different things that shouldn't be connected
15:08:27 <rhochmuth> and break compatibilty, unless we added a CRITICLA_AND_LATCHED severity
15:09:33 <rhochmuth> does anyone else want to comment?
15:09:49 <rhochmuth> or have any quesions?
15:11:13 <tomasztrebski> guess not, ok I will think on this a bit more - anyway idea of using severity here seems a nice one, thanks to recent schema changes it'd be easy to add new severity
15:11:34 <tomasztrebski> if that one is rejected, we will go with extending model directly
15:12:17 <jayahn> for me, i would like have severity of an alarm as it is. IMHO, to decide it should be latched to get more attention up to operators to decide. it is not directly related to the severity. we have different process to do that outside of monasca.
15:12:18 <rhochmuth> tomasz: i think we should extend the alarm definition with the "latched" field
15:12:32 <jayahn> a bit late.. sorry. i just joined. got some time to follow-up
15:12:50 <rhochmuth> jayahn: i agree
15:12:53 <tomasztrebski> np, thx for comment
15:13:18 <rhochmuth> although, i'm not sure "latched" is a great name, but it is certainly better than existentialist
15:13:26 <tomasztrebski> ok, so I guess that is settled - I am still learning what particular pieces means so this is nice comment about correct usage of specific properties
15:13:34 <tomasztrebski> yes, latched isn't that great
15:13:39 <tomasztrebski> I will come up with better one :)
15:13:52 <jayahn> get "right name" is always the most difficult thing. :)
15:14:07 <rhochmuth> tomasz: i'm still trying to get used to deterministic
15:14:32 <rhochmuth> just check with us before making all the code changes, it is a bit easier that way
15:14:46 <tomasztrebski> kk, I will discuss that
15:14:54 <rhochmuth> thanks
15:15:08 <rhochmuth> #agenda Mid-cycle meetup
15:15:21 <rhochmuth> i haven't heard back yet
15:15:32 <rhochmuth> i'll need to ping my mgmt again on travel approval
15:15:41 <fabiog> http://doodle.com/poll/x6bf8ev6wvenfkdy
15:15:57 <rhochmuth> thank you doodle master
15:16:00 <fabiog> right now we have 5 people good to attend SJC and 5 good to attend Munich
15:16:03 <fabiog> so we are in deadlockj
15:16:06 <jayahn> :) we need tie braker.
15:16:07 <bklei> :(
15:16:09 <slogan> nice
15:16:26 <slogan> my manager said I can travel as long as I can get there by bicycle
15:16:41 <hosanai> lol
15:16:44 <fabiog> so slogan SJC is your only option :-)
15:16:56 <slogan> I could do that
15:17:06 <fabiog> you can always hold to a truck on Interstate 5 :-)
15:17:17 <rhochmuth> that's a long bike ride from san diego
15:17:43 <slogan> https://www.strava.com/athletes/878949
15:17:59 <fabiog> slogan: I'll give you a yellow shirt if you do it :-)
15:18:04 <slogan> ha
15:18:53 <rhochmuth> very difficult to plan the mid-cycles
15:18:59 <rhochmuth> we don't have a huge eco-system
15:19:26 <rhochmuth> so if we can't all get there, it becomes a relatively small meetup without enoguh representation
15:19:26 * claudiub sneaks in and waves
15:19:35 <Kamil_> i don't think that we (fujitsu) will get an approval to travel to SJC
15:19:57 <fabiog> rhochmuth: the other option is to do virtual again
15:20:09 <slogan> with something like webex?
15:20:14 <fabiog> yes
15:20:17 <fabiog> I can host it
15:20:19 <rhochmuth> yes, i would lean towards that as i think inclusion is more important
15:20:20 <jayahn> I have to find three reasons to travel to SJC. I managed to find two till now. :)
15:20:51 <rhochmuth> the beer is better in munich
15:21:15 <Kamil_> and bigger
15:21:44 <hosanai> and reasonable
15:21:47 <fabiog> let's give a deadline
15:21:52 <rhochmuth> so, after teh barcelona summit we won't have to plan on mid-cycles
15:21:54 <fabiog> end of month to cast your preferences
15:21:58 <rhochmuth> it will all be planned
15:22:10 <rhochmuth> fabiog: sounds good
15:22:16 <fabiog> and then we decide where to happen. SJC, Munich or virtual
15:22:29 <rhochmuth> another two weeks to figure out, but it is looking like virtual at this point
15:23:02 <rhochmuth> #agenda 3. Vitrage update (Syd)
15:23:06 <fabiog> what about we do it in SJC and we have morning sessions that are virtual
15:23:07 <fabiog> ?
15:23:15 <fabiog> I can get a Telepresence room
15:23:16 <slogan> had an information exchange meeting with nokia/vitrage yesterday morning
15:23:22 <bklei> +1 on that
15:23:29 <slogan> what they seem to be about is graphically rendering actual topologies of the network (down to the port level)
15:23:29 <rhochmuth> sorry, changed topic too soon
15:23:41 <rhochmuth> fabiog: that might be a good option too
15:23:42 <slogan> ok
15:24:04 <fabiog> rhochmuth: let's plan for that if Munich does not materialize
15:24:08 <fabiog> :-)
15:24:15 <rhochmuth> ok, thanks fabiog
15:24:19 <rhochmuth> will change topic now
15:24:20 <fabiog> rhochmuth: np
15:24:28 <rhochmuth> back to you slogan
15:24:36 <rhochmuth> sorry for interrupt
15:24:38 <slogan> had an information exchange meeting with nokia/vitrage yesterday morning
15:24:45 <slogan> what they seem to be about is graphically rendering actual topologies of the network (down to the port level)
15:24:53 <slogan> and showing state (up, down, critical, etc) using colors
15:24:59 <slogan> there is a yaml language for defining rules/policy that leads to these state changes
15:25:06 <slogan> they have an API that is of yet undocumented for pushing data into vitrage
15:25:12 <slogan> my idea - broadview-collector pushes raw data to monasca, and a second broadview-collector plugin pushes to vitrage
15:25:21 <slogan> vitrage yaml logic is used to define policy that is based on specific network deployments (hyper-converged, data storage network, tenant network) as needed to get a "color"
15:25:28 <slogan> vitrage user sees a network switch go "yellow" and then refers to monasca-based grafana UI to get more details
15:25:38 <slogan> that's it
15:25:40 <slogan> comments?
15:25:55 <rhochmuth> so, you don't end up pushing metrics to vitrage, just alarms, correct?
15:26:25 <slogan> possibly I do some pre-preocessing in broadview-collector and just send an alarm, yes
15:26:37 <slogan> or, the yaml logic is used to determine that alarm
15:26:39 <slogan> not sure yet
15:26:50 <rhochmuth> i don't see a problem with broadview sending metrics to monasca
15:26:56 <rhochmuth> monasca evaluating an alarm
15:27:02 <rhochmuth> and then notifying vitrage
15:27:07 <slogan> and then that goes to vitrage?
15:27:12 <slogan> I see, yes
15:27:17 <rhochmuth> then vitrage evaluates rules
15:27:24 <slogan> that would work too
15:27:49 <slogan> what's interesting is their docuemntation page features networking, they are clearly interested in that ascpect ofg things
15:27:59 <rhochmuth> so, i think it all would work well
15:28:23 <slogan> I'm waiting for the documentation
15:28:29 <slogan> they are pending on that
15:28:34 <rhochmuth> how do you specify to vitrage that this VM is somehow associated with a switch
15:28:53 <slogan> they have a way to specify graphs and relate things
15:28:53 <rhochmuth> physical switch that is
15:29:15 <slogan> yeah, there is a topology language, yaml I think for doing that
15:29:32 <slogan> you define nodes/vertices and then dependencies/edges
15:29:40 <slogan> I've only just glanced at it all
15:30:35 <rhochmuth> it sounds like an interesting use case
15:30:50 <rhochmuth> but getting all the data into vitrage i'm wondering about
15:30:59 <slogan> so, I think next step is for me to look deeper, but let's continue to feature monasca in my work, if monasca has the raw data, and an alarm to trigger a push to vitrage, I'm great with that
15:31:28 <slogan> I'll take the lead to lean more about all of it
15:31:41 <slogan> help them understand monasca as needed
15:31:52 <rhochmuth> i'll try and start taking a closer look, as soon as i complete some reviews
15:31:56 <slogan> they're smart people, hopefully this isn't a big deal
15:32:12 <slogan> I mentioned it would be nice to have something for barcelona
15:32:17 <rhochmuth> if they are smart, i don't want to work with them
15:32:28 <rhochmuth> :-)
15:32:43 <rhochmuth> sorry, i don't think that is what you meant
15:32:47 <slogan> I like very much the idea of a three-headed presentation that shows end to end what can be done
15:33:04 <slogan> what they are not about is doing any actions
15:33:12 <slogan> it's just rendering the state
15:33:32 <slogan> maybe there is a fourth project like congress that plays a further role
15:33:41 <rhochmuth> we had talked about vitrage creatign alarms back in monasca
15:33:54 <slogan> how did they receive it?
15:34:08 <rhochmuth> it seems like a general capability that we want/should have in monasca
15:34:16 <rhochmuth> they were pushing for the change
15:34:26 <slogan> the thing that seemed interesting about their yaml code was it might be a way to express various use cases for networking
15:34:54 <rhochmuth> so, besides slogan and me, is anyone else interested in this topic?
15:34:57 <slogan> like, I could have yaml that is tuned to a specific networking use case like storage in a leaf spine CLOS network
15:35:16 <slogan> zzzzzzzz :-)
15:35:30 <rhochmuth> just checking
15:35:37 <slogan> okay, enough I suppose for now
15:35:38 <rhochmuth> ok, probably should wrap-up
15:35:48 <rhochmuth> probably
15:35:54 <jayahn> probably us. we are developing an anlaytics platform to gether all the network related data (packet, flow, etc). we have a plan to push that data into monsca.
15:35:55 <rhochmuth> thanks slogan
15:36:07 <jayahn> it sounds very similar to what virtage does.
15:36:31 <claudiub> hi. I also have a request / set of questions.
15:36:32 <slogan> jayahn: what is this platform, and where are you from?
15:36:42 <jayahn> hi, i am from sk telecom.
15:36:43 <slogan> hi :-)
15:36:50 <jayahn> platform is in-house development
15:37:43 <rhochmuth> cladiub: just trying to get through some topics first
15:37:45 <slogan> search broadview in github if you want a background in what we are pushing off switch about our switching silicon
15:38:06 <jayahn> all the network data - alnaytics platform - (push data) - monasca - (consum data) - visual app to show network statues in 3D.
15:38:25 <slogan> nice
15:38:25 <jayahn> i know. we are looking into broadview in github. :)
15:38:42 <claudiub> rhochmuth: sure, i thought that you were going to end the meeting. :)
15:38:56 <rhochmuth> jayahn: slogan is the developer on broadview
15:39:36 <rhochmuth> i'm going to switch topics if that is ok?
15:39:41 <slogan> yep
15:39:41 <jayahn> okay. that is great. I will contact you if we have any question on broadview-collector, or anyting related to that :)
15:39:44 <jayahn> yeap
15:39:50 <rhochmuth> #topic monasca-transform
15:39:56 <hosanai> jayahn: why you push analyzed data to monasca?
15:39:57 <rhochmuth> thx jayahn
15:40:43 <rhochmuth> has anyone looked at monasca-transform
15:40:48 <rhochmuth> i'm jsut getting started
15:41:06 <FlintHPE> hi all, Ashwin couldn't make the meeting today.  We have a Monasca-Transform review up, but it's currently set to "work in progress" while we wrap up a few things.
15:41:32 <rhochmuth> thanks FlintHPE
15:41:53 <rhochmuth> i will hopeflly get this reviewed and running over today, tomorrow, friday
15:42:48 <rhochmuth> if there are no questions and/or comments, then we should move on
15:43:14 <rhochmuth> note, review is at, https://review.openstack.org/#/c/315245/
15:43:28 <rhochmuth> #topic monasca-analytics
15:43:39 <rhochmuth> monasca-analytics is in a similar state
15:43:52 <rhochmuth> i don't think any of the hpe labs folks are here
15:44:07 <rhochmuth> thanks for reviewing hosanai
15:44:24 <rhochmuth> it sounds like in general you are positive about the initial commit
15:44:36 <hosanai> yep.
15:44:42 <rhochmuth> have you tried running it
15:45:04 <hosanai> unittest worked but
15:45:27 <hosanai> spark didn't start in my env now.
15:45:43 <rhochmuth> that sounds like fun to debuf
15:45:51 <hosanai> I wrote a question on the comment to you.
15:46:03 <rhochmuth> you might be able to use the devstack plugin that monasca-transform has created as that install spark
15:46:38 <rhochmuth> FlintHPE: does that sound correct
15:46:52 <FlintHPE> seems like that might work
15:46:55 <hosanai> i don't have a problem for installing spark
15:47:10 <hosanai> it seems to be setting of port...
15:48:15 <hosanai> i would like to know conditions for merging initial code.
15:49:23 <rhochmuth> not sure i've discussed, but i would like to see if few logitical issues addressed
15:49:33 <rhochmuth> also, i would like to have run it to see what it does
15:49:39 <rhochmuth> and if it works
15:49:39 <hosanai> i asked it in gerrit please check it.
15:49:53 <rhochmuth> hosanai: ok
15:50:02 <hosanai> thnaks!
15:50:22 <rhochmuth> hosanai, are you in favor of mergingin now then?
15:50:53 <rhochmuth> or are you interested in seeing other areas addressed?
15:51:05 <hosanai> rhochmuth: if possible, but i think some comments need to fix before merging.
15:51:30 <rhochmuth> ok, thanks, i'll look at your comments today
15:51:46 <hosanai> thanks in advance :-)
15:51:48 <rhochmuth> going to move on now
15:51:54 <rhochmuth> #topic State of the gate?
15:52:03 <rhochmuth> Does anyone know the state of the gate
15:52:15 <rhochmuth> we had several issues impact us over the last few days
15:52:35 <rhochmuth> global requirements moved the kafka-python and falcon libraries
15:52:51 <rhochmuth> also, we had an issue in DevStack with installing Kafka
15:53:01 <rhochmuth> so, upstream gate was down
15:53:08 <rhochmuth> i'm not sure if it is up yet
15:53:11 <tomasztrebski> my idea for fixing falcon was taken by Ryan I guess
15:53:16 <tomasztrebski> so that one is fixed
15:53:46 <rhochmuth> tomasz: i think joe, but he had to combine two reviews together to get gate to pass
15:54:01 <rhochmuth> he was able to get the combined review in
15:54:16 <tomasztrebski> yes, Joe :), anyway good thing that it passed
15:54:32 <rhochmuth> however, it looked like there were still issues
15:54:51 <rhochmuth> anyway, hoping it all gets fixed this morning
15:55:13 <bklei> hoping so
15:55:13 <rhochmuth> #topic Update on dimensions resource?
15:55:39 <rhochmuth> i'm not aware of anyone woriing on the dimensions resource yet
15:55:41 <bklei> that's me -- curious if anyone has started that?
15:55:47 <rhochmuth> not yet
15:56:08 <rhochmuth> #topic Update on api caching?
15:56:10 <bklei> still plans for that?
15:56:30 <rhochmuth> there are plans for dimensions resource, but no commitments yet
15:56:39 <bklei> ok
15:56:45 <rhochmuth> have you tried multipel metrics
15:57:18 <bklei> yes -- but holding off on calling it for the concurrent exception fix
15:57:26 <bklei> (gate)
15:57:32 <rhochmuth> i was hoping to get multiple metrics done and tested before looking at anythign like api caching
15:57:39 <rhochmuth> ahh yes, gate
15:57:42 <bklei> :)
15:57:52 <rhochmuth> we can't get that bug resolved unless gate is fixed
15:58:06 <bklei> yup
15:58:31 <rhochmuth> claudiub: you still there?
15:58:36 <rhochmuth> we're going to run out of time
15:58:39 <claudiub> yep
15:58:59 <rhochmuth> we might need to move to openstack-monasca
15:59:03 <rhochmuth> but please proceed
15:59:09 <claudiub> we've talked brifly during the Summit about adding WIndows support for monasca-agent. I've submitted a blueprint: https://blueprints.launchpad.net/monasca/+spec/add-windows-support
15:59:16 <rhochmuth> thanks
15:59:47 <claudiub> basically, it's about solving differences between WIndows  and Linux, e.g. using stuff that doesn't exist on Windows that causes the services to die.
15:59:53 <rhochmuth> i'll review and also get several more from hpe to take a look that work on the agent a lot
15:59:57 <claudiub> e.g. signal.SIGUSR1
16:00:05 <claudiub> sure
16:00:12 <claudiub> but I do have a couple of questions
16:00:21 <claudiub> on a few things
16:00:25 <rhochmuth> so, i', going to have to end the meeting
16:00:29 <rhochmuth> only one hour
16:00:30 <claudiub> but we can talk about them in the #openstack-monasca chanel
16:00:39 <rhochmuth> but i'll move to #openstack-monasca
16:00:52 <rhochmuth> ok everyone, have to shut it down
16:00:55 <rhochmuth> bye
16:00:56 <bklei> thx
16:00:57 <slogan> bye!
16:01:04 <hosanai> thanks bye!
16:01:05 <rhochmuth> #endmeeting