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