15:01:02 <rhochmuth> #startmeeting monasca
15:01:03 <openstack> Meeting started Wed Feb 24 15:01:02 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:04 <rhochmuth> o/
15:01:06 <openstack> The meeting name has been set to 'monasca'
15:01:08 <fabiog> o/
15:01:10 <rhochmuth> hi everyone
15:01:13 <Kamil> o/
15:01:16 <rbak> o/
15:01:18 <shinya_kwbt> o/
15:01:21 <rhochmuth> Agenda is posted at, https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:01:31 <rhochmuth> Agenda for Wednesday February 24, 2016 (15:00 UTC)
15:01:31 <rhochmuth> 1.	Log API
15:01:31 <rhochmuth> 1.	Resolve whether dimensions per log message or per http request body? https://review.openstack.org/#/c/273058/
15:01:31 <rhochmuth> 2.	Anything else
15:01:31 <rhochmuth> 2.	Potential discussion about Broadview.
15:01:31 <rhochmuth> 3.	Potential discussion on clustering and anomaly detection.
15:01:31 <rhochmuth> 4.	Re-organizing the directory layout of the API, Log API and monasca-common.
15:01:32 <rhochmuth> 5.	Reviews that need to be addressed.
15:01:32 <rhochmuth> 6.	Monasca/devstack may need to update.
15:01:33 <rhochmuth> 7.	sqlalchemy https://review.openstack.org/#/c/273058/
15:01:33 <rhochmuth> 8.	java tempest tests / hibernate support
15:01:33 <ho_away> o/
15:01:46 <bklei> o/
15:01:47 <rhochmuth> We can also discuss other topics too
15:01:54 <witek> hello
15:02:15 <rhochmuth> #topic log-api
15:02:25 <tgraichen> hi
15:02:47 <rhochmuth> So, I was wondering what we should do with the dimensions as well as any other items before getting the recent changes merged
15:02:52 <jobrs> hi
15:03:08 <rhochmuth> hi everyone, sorry, i'm not being so courteous today
15:03:28 <rhochmuth> anyway, witek, sounds like you want dimensions per log message
15:03:43 <rhochmuth> i can make that change
15:03:55 <witek> yes, I though it is a good idea to keep dimensions consistent for logs and metrics
15:04:17 <rhochmuth> well, i can't think of any downsides, other than a little extra data per log message
15:04:17 <witek> and so, agent could have different dimensions for every file monitored
15:04:28 <rhochmuth> my assumption was taht the dimensions woudl be constant per log
15:04:38 <rhochmuth> and the aganet would only be processing one log at a time
15:04:58 <rhochmuth> so, that doesn't sound like a valid assumption on my part
15:05:31 <witek> then we would need agent instance per log file
15:05:42 <witek> I don't think it's good
15:05:52 <rhochmuth> ok, i'll make the change
15:05:59 <rhochmuth> should go quick
15:06:13 <rhochmuth> is there anything else that come to mind that i might need to address right now
15:06:21 <witek> ok, thanks a lot
15:06:38 <rhochmuth> anything else related to log api we need to discuss?
15:06:41 <witek> i don't think
15:06:52 <rhochmuth> ok, moving on then, thanks witek
15:07:02 <rhochmuth> #topic broadview
15:07:08 <rhochmuth> this is a potential topic
15:07:19 <rhochmuth> not sure if syd is here or anyone else from broadview
15:07:20 <slogan_r_> yep :-)
15:07:24 <slogan_r_> here
15:07:25 <rhochmuth> hi
15:07:40 <slogan_r_> so, we are currently working on 3 projects
15:08:29 <rhochmuth> so there is broadview-lib, broadview-collector and broadview-ui
15:08:30 <slogan_r_> the basic idea is that there is interesting networking underlay data to push into monasca as metrics
15:08:37 <slogan_r_> right
15:08:41 <slogan_r_> lib has landed
15:08:56 <slogan_r_> collector is a service that will use lib to push metrics into monasca
15:09:07 <slogan_r_> ui is a panel in horizon to configure it all
15:09:17 <rhochmuth> so, i think if you have the metrics dump you sent me, that woudl be cool to post here
15:09:46 <slogan_r_> ah, unable to do that this meeting
15:09:52 <rhochmuth> np
15:09:53 <slogan_r_> not near the data
15:10:22 <rhochmuth> so, is there a list of vendors that we can get that broadview is applicaple too
15:10:29 <slogan_r_> but the short story is that network switches have buffers, and buffers have all sorts of iteresting data that can help detect issues that you normally don't see
15:10:42 <rhochmuth> i was hoping it worked for the hpe 5930 switch
15:10:54 <slogan_r_> the vendor list is hue, HP among them, but most switch vendors are using our silicon
15:11:13 <slogan_r_> I look into that, you mentioned it would be nice to have one of those switches, right?
15:11:22 <rhochmuth> absolutely
15:11:34 <slogan_r_> let me take that up
15:11:45 <rhochmuth> but i was hoping that hpe was planning on using a switch that had support for broadview
15:11:56 <slogan_r_> so in the coming week I should have a gerrit review up for the collector
15:12:06 <rhochmuth> cool
15:12:13 <slogan_r_> appreciate anyone who is interested in reviewing to look, particularly the monasca plugin part
15:12:39 <rhochmuth> please add me to the review
15:12:50 <rhochmuth> as well as anyone else that is interested
15:12:53 <slogan_r_> one issue I am facing is how to gain access to IP address and ports for talking to monasca from pthon API
15:13:28 <slogan_r_> there is a yaml file with all the data, but it is read only except for root and mon-api ?? group I think
15:13:42 <slogan_r_> that's an issue for the code review maybe
15:13:42 <rhochmuth> that is the default install
15:14:05 <slogan_r_> creating a monasca Client object takes some of that config as kwargs
15:14:15 <fabiog> slogan_r_: how lib access the data in the switch? is it using snmp traps?
15:14:41 <slogan_r_> fabiog: for our trident2 and later chips, there is an agent running switch side
15:14:58 <slogan_r_> that agent talks HTP 1.1 to our collector when thresholds are crossed
15:15:01 <fabiog> slogan_r_: so the agent is pushing the data out at a fixed interval?
15:15:12 <slogan_r_> it can, or as thresholds reached
15:15:18 <slogan_r_> it can be polled as well
15:15:58 <slogan_r_> longer tem, we want to see data that resolves what is happening in hardware with, say, a virtual network that is bound to tenant in neutron
15:17:14 <slogan_r_> that would be very useful, say, if an operator were to experience problems in his virtual network -- if we can see issues in the hardware, and we can tie the two together, then we can maybe isolate to a switch in a datacenter and it can be looked at
15:17:33 <rhochmuth> would virtual network include support for ovs
15:17:46 <slogan_r_> what I am doing now with these projects is just that start of it
15:17:50 <slogan_r_> yes, I mean OVS
15:17:58 <rhochmuth> awesome
15:18:14 <rhochmuth> i'm very interested in this area
15:18:32 <slogan_r_> me too :-)
15:18:42 <rhochmuth> as i've had a few requests over that last couple of weeks to start looking at support for vswitch
15:19:07 <bklei> slogan_r_: we were thinking about the same thing at twc -- a libvirt style plugin that would post virtual router bw
15:19:08 <slogan_r_> OVS is the obvious place to start
15:19:12 <rhochmuth> this is coming up as one of our big requests
15:19:22 <bklei> and cross post to the admin project, like libvirt plugin
15:19:31 <slogan_r_> but segementation IDs are a neutron/nova thing, so it is not limited to OVS
15:19:41 <slogan_r_> yep
15:20:14 <bklei> we've got ovs specific code here that does that -- i can put a monasca-agent patch up and see what you guys think
15:20:32 <slogan_r_> cool
15:20:41 <rhochmuth> bklei: thanks, interested too
15:20:57 <bklei> cool, will include you on the review -- any anyone else interested
15:21:06 <slogan_r_> again, what we have now for our part is early stage, we are not attempting to address this overlay/underlay resolution but that will come
15:21:42 <slogan_r_> the underlying agent has several boxes, so to speak, each covering a class of data that the switch might expose
15:22:10 <slogan_r_> the contrbution at this stage is about buffer threshold events that lead to packet drops in the silicon
15:22:34 <slogan_r_> the ability to even tie together underlay with a segmentation ID is work to be done
15:22:48 <slogan_r_> but it is obviously somewhat of a holy grail
15:22:57 <slogan_r_> important to set expectations
15:23:28 <slogan_r_> anyway, I think monasca rocks and it is why we are here
15:23:36 <rhochmuth> thx sysd
15:23:40 <rhochmuth> syd
15:23:42 <slogan_r_> looking forward to working with you all
15:23:42 <rhochmuth> sorry
15:23:57 <rhochmuth> i'm wondering about interest from folks on working on this
15:24:02 <rhochmuth> also, seeing how to best coordinate
15:24:13 <rhochmuth> might be best to have a broadview specific meeting
15:24:22 <slogan_r_> okay, we could do that
15:24:25 <rhochmuth> if there is enough interest
15:25:03 <slogan_r_> I was thinking it might be good as a pseudo PTL (what do you call people who lead unofficial projects?) to maybe be more present in irc on a channel at least
15:25:22 <slogan_r_> maybe #openstack-broadview or something
15:25:30 <rhochmuth> yes, i think that makes sense
15:25:55 <rhochmuth> ok, leet's wrap up on this topic
15:25:59 <slogan_r_> btw, monasca-api has been a big influence on my docs and currently, my devstack hacking
15:26:14 <slogan_r_> s/my/our/
15:26:22 <slogan_r_> yep, thanks for the time
15:26:32 <rhochmuth> thanks syd
15:26:37 <rhochmuth> let's discuss off-line
15:26:48 <slogan_r_> k
15:26:50 <rhochmuth> so options, and see what makes sense
15:27:03 <rhochmuth> #topic analytics
15:27:20 <rhochmuth> so, i just want to give and update
15:27:27 <rhochmuth> is anyone from bristol hpe here
15:28:32 <rhochmuth> anyway, it looks like we are getting some interest in alarm clustering and anomaly detection algorithms
15:28:45 <ho_away> cool :-)
15:29:05 <rhochmuth> ho_away: I would like to get some discussions with you and the team
15:29:10 <ho_away> what is the relationship b/w bristol hpe and this topic?
15:29:14 <rhochmuth> so i'll work on brokering that and keepign you in the loop
15:29:39 <rhochmuth> there is lab there that is doing some potential work in this area
15:29:59 <ho_away> i will be in bristol hpe next week.
15:30:23 <ho_away> to attend other meeting.
15:30:29 <rhochmuth> i can get you introduced
15:30:37 <ho_away> great!
15:30:57 <rhochmuth> so, since not everyone is here, i'll defer to another day
15:31:13 <rhochmuth> but we're going to have to start planning and coordinating in this area
15:31:16 <rhochmuth> i thihnk
15:31:19 <rhochmuth> think
15:31:35 <fabiog> rhochmuth: let's plan to have that as a topic for the summit
15:31:35 <rhochmuth> so, we might have to have some additional sessions on this topic
15:31:41 <rhochmuth> sounds good
15:31:49 <rhochmuth> and that isn't too far off at this point
15:31:49 <ho_away> sounds nice!
15:31:58 <rhochmuth> ho_away, will you be in austin
15:32:20 <ho_away> not decided yet but i will negociate it with my boss
15:32:36 <slogan_r_> :-)
15:32:39 <rhochmuth> i'll check with the other folks
15:32:48 <rhochmuth> good lock
15:33:02 <rhochmuth> ok, next topic, unles more to discuss?
15:33:25 <rhochmuth> #re-factoring
15:33:36 <rhochmuth> so, i was planning on a proposal, but i didn't get to it
15:34:01 <rhochmuth> in general, i just think our file organization for the python code could be improved a little
15:34:17 <rhochmuth> i'll try and get somethign written up for next time
15:34:27 <rhochmuth> sorry, i'm wasting folks time on this
15:34:49 <rhochmuth> #topic review
15:34:55 <rhochmuth> #tpoic reviews
15:35:11 <rhochmuth> so, if there are any reivews that need attending to please let me know
15:35:41 <rhochmuth> we are still a little backed up
15:35:47 <witek> I put sqlalchemy as a separate point
15:35:57 <rhochmuth> yes, I +1'd that review
15:36:14 <rhochmuth> THis one, https://review.openstack.org/#/c/266922/
15:36:23 <fabiog> rhochmuth: https://review.openstack.org/#/c/251674/ needs some love from Infra core
15:36:46 <fabiog> so we can finally get the client in the global reqs ...
15:37:11 <rhochmuth> So, relative to https://review.openstack.org/#/c/266922/, the ORM/SQLAlchemy, it would be good to have some more eyes and +1s. I hate holding up this review
15:37:24 <rhochmuth> In general, i'm ok switching over to sqlalchemy
15:37:30 <rhochmuth> and keeping mysql around jsut in case
15:37:41 <rhochmuth> hopefully backing out the mysql repo over time
15:37:47 <witek> but sqlalchemy would become default, right?
15:37:54 <rhochmuth> that is fine with me
15:38:02 <witek> cool
15:38:03 <rhochmuth> we dont' have any production concerns with the python
15:38:16 * slogan_r_ will try and code review that one
15:38:19 <rhochmuth> so, i think getting it in the pipe asap to get more testing on it is best
15:38:25 <rhochmuth> thanks syd
15:38:27 <rhochmuth> it is a biggie
15:38:41 <rhochmuth> it doesnt' help that i'm not a sqlalchemy expert
15:38:48 <rhochmuth> so i'm learnign this area
15:38:59 <slogan_r_> nod
15:39:03 <rhochmuth> i'l try and lobby some resources from hpe
15:39:17 <rhochmuth> fabiog: what do you need from us
15:39:22 <rhochmuth> that review is taking forever
15:39:23 <witek> thanks Roland!
15:40:01 <rhochmuth> fabiog?
15:40:25 <fabiog> rhochmuth: it would be good if Doug will +2 it again. He did before but I had to rebase
15:41:01 <fabiog> also it will be good if many Monasca people will +1 this will generate interest around the patch
15:41:13 <fabiog> to get other infra committers to merge it
15:41:16 <rhochmuth> is everything else resolved then
15:41:51 <fabiog> yes, I did a second patch that added the tempest check for requirements and that has been merged. I added as dependency to the reqs patch
15:42:00 <rhochmuth> OK, So if folks can +1, https://review.openstack.org/#/c/251674/, that would be great
15:42:07 <fabiog> thanks, all
15:42:45 <rhochmuth> probably should ping doug
15:43:04 <rhochmuth> Anye other pressing review?
15:43:55 <rhochmuth> #topic devstack
15:44:10 <rhochmuth> sounds like devstack is broken again
15:44:25 <shinya_kwbt> Yes.
15:44:29 <slogan_r_> how so?
15:44:33 <shinya_kwbt> monasca-vagrant provisioning is currently success.
15:44:44 <shinya_kwbt> But I can't log into Horizon UI. Roland and Witold are neither.
15:45:01 <shinya_kwbt> I doubt keystone because log in processing raises error.
15:45:09 <rhochmuth> so, there is a bug that was introduced in the monasca-ui
15:45:12 <rhochmuth> not sure when
15:45:34 <rhochmuth> that is preventing the horizon login from working
15:45:35 <witek> I think it is dependencies issue
15:45:44 <shinya_kwbt> I think so too.
15:45:58 <rhochmuth> so, can you resolve
15:46:05 <witek> would updating devstack box help?
15:46:16 <slogan> when you say devstack bug, are you referring to devstack code in monasca-api?
15:46:22 <rhochmuth> no, devstack and monasca-vagrant are entirely separate
15:46:23 <shinya_kwbt> I tried to update devstack box
15:46:54 <rhochmuth> there is the monasca-vagrant repo
15:47:02 <rhochmuth> and then there is monasca-api/devstack
15:47:18 <rhochmuth> and there is a Vagrantfile in the devstack directory
15:47:23 <slogan> yes
15:47:26 <witek> shinya_kwbt: any success?
15:48:01 <shinya_kwbt> Then I tried to make monasca/devstack which has latest keystone by using ds-build. This image doesn't have admin_token,
15:48:15 <shinya_kwbt> then I patched this(https://review.openstack.org/284010/), I finally successfully log in.
15:49:32 <shinya_kwbt> monasca-repo's devstack seem to be old
15:49:56 <rhochmuth> ohh, now i understand
15:50:06 <rhochmuth> the devstack vm that is in monasca-vagrant is out of sync
15:50:09 <witek> shinya_kwbt: so it seems to solve the problem, right?
15:50:50 <shinya_kwbt> made at July 2015, liberty version.
15:51:13 <slogan> I noticed when I tried vagrant that python monasca-client failed to install
15:51:22 <slogan> I had to hand install it afterwards
15:51:44 <rhochmuth> so, what is the status now then
15:51:45 <shinya_kwbt> witek: I can log into Horizon.
15:52:03 <rhochmuth> shinya: does your review get things working again?
15:52:17 <rhochmuth> and do we need to update the devstack image?
15:53:31 <witek> rhochmuth: I think we need an update
15:53:49 <Kamil> The current version was created 8 months ago
15:53:57 <rhochmuth> i'll check with the developer to see what is involved
15:53:57 <shinya_kwbt> I think needs to update. Because current image is liberty.
15:54:41 <rhochmuth> the other option is to move completely to the devstack in monasca-api/devstack
15:54:58 <rhochmuth> how do folks feel about that
15:55:04 <rhochmuth> second option
15:55:35 <bklei> +1 on that
15:55:35 <slogan> why would there need to be anything other than the monasca-api devstack? It's the only one I considered when I went looking
15:55:55 <rhochmuth> it is mostly historical/legacy
15:56:00 <witek> we still are using ansible roles
15:56:09 <slogan> I'm not sure why there is a monasca-vagrant, can someone explain that and the difference between the monasca-api devstack vagrant file?
15:56:18 <witek> but want to write devstack plugin for log-part
15:56:19 <rhochmuth> we started with our own Vagrant env and a lot of Ansible
15:56:46 <Kamil> for testing purposes monasca-vagrant is fast and easy
15:57:14 <rhochmuth> i'll talk with the developer about a devstack image to see what is involved
15:57:24 <slogan> there is a Chinese saying: the tiger that chases two rabbits will catch neither
15:57:40 <rhochmuth> lol
15:57:52 <slogan> s/rabbits/devstacks/
15:58:19 <rhochmuth> so, we only have 2 minutes
15:58:32 <ho_away> fyi: admin token is deprecated and found the commit https://github.com/openstack/keystone/commit/5286b4a297b5a94895a311a9e564aa87cb54dbfd
15:59:05 <pradipm> Is there a document that describes how to integrate ELK (elastic-search, logstash,kibana) with Monasca?
15:59:29 <witek> there is a change in gerrit
16:00:07 <rhochmuth> we've reached the end folks
16:00:11 <rhochmuth> got to end the meeting
16:00:24 <rhochmuth> head over to #openstack-monasca for more follow-up
16:00:32 <rhochmuth> #endmeeting