15:07:27 #startmeeting GBP 9/2 15:07:27 Meeting started Wed Sep 2 15:07:27 2015 UTC. The chair is alagalah. Information about MeetBot at http://ci.openstack.org/meetbot.html. 15:07:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:07:27 The meeting name has been set to 'gbp_9_2' 15:07:37 #topic Agenda bashing 15:09:41 #info martin-sunal 15:10:02 alagalah, do we have webex link? 15:10:17 yapeng, no unfortunately, IRC only this week... we will ahve to make do 15:10:30 alagalah, ok. 15:10:50 #link https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Team_Meeting GBP agena 15:10:55 #info alagalah 15:11:27 #topic M2 milestone due tomorrow 15:11:52 #info currently sticking with our design docs. I don't see any major changes proposed from what I put in the draft.... any comments? 15:12:21 #link https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Releases/Beryllium/Release_plan Draft Release Plan Be 15:12:36 #info yapeng should we add FaaS explicitly ? 15:13:00 alagalah, please add FaaS Render item. 15:13:14 yapeng, Can I add it as a sub-item to Renderer SDK ? 15:13:24 alagalah, sure. 15:13:50 #info alaglah will add FaaS to Renderer SDK, otherwise it looks good to go. 15:14:51 #topic Recent GBPSFC demo issues/fixes 15:15:13 #info I recently did a fresh build of the GBPSFC demo env and found some weird issues 15:15:48 #info What I saw was that everything was provisioned correctly, and when I ran a test (demo-symmetry) I saw that 15:16:18 #info userland flows were being matched, and packets were indeed being sent OUT the VXLAN tunnel, and packets were hitting the remote linux kernel.... 15:16:26 #info but were not ingressing into OVS... very odd. 15:16:46 #info turns out the Box we were using from AWS, must have upgraded their kernel to 3.19 15:16:59 #info this is incompatible with Pritesh's OVS repo. 15:17:19 #info The fix was to use an existing ubuntu/trusty64 box from Hashi, which has 3.13. 15:17:45 #info this then worked. What I have subsequently done is create a bespoke box (alagalah/gbpsfc-trusty64) with OVS+NSH, docker+images 15:18:13 #info this work and it has the side benefit of speeding up the time it takes to create the demo env (much much much faster, no added SHELL provisioning scripts) 15:18:55 #action alagalah to push new "box" env for gbpsfc-env repo after tomas_c|3 has finished his testing (I wanted to ensure it all still worked) 15:20:24 #info if anyone is interested in trying it for themselves, you can remove the SHELL provisioner, the link to the BOX file and replace the box file name with "alagalah/gbpsfc-trusty64" 15:20:32 #info any questions ? 15:20:52 this is great, I will try it out. 15:21:10 alagalah: demo worked for me with 3.13 15:21:27 #info yapeng says this is great. tomas_c|3 says demo worked... alagalah makes big smiley face, will push 15:21:34 alagalah: but i had to add flows manualy to gbpsfc3 ang gbpsfc5 15:21:52 alagalah: you probably forgot to put flow configuration in sf-config.sh 15:21:53 tomas_c|3, Then it didn't work... now we must find out why, cos that worked for me. 15:22:20 tomas_c|3, It should work OOB ... it only changes the packaging, not the IP addressing etc... so thats very odd... 15:22:47 alagalah: hm, i can try to run it again now and let you know 15:23:38 #action tomas_c|3 alagalah to see why tomas_c|3 doesn't see SF flows being created but alagalah does... 15:24:07 is there a demo env for neutron+sfc? 15:24:10 #action As a consequence of this, today I am working on our devstack environment, as this explains why I was seeing similar issues with it. 15:24:19 dileep, you're too quick, mate :D 15:24:37 #info alagalah notes dileep asks if there is a similar neutron+SFC environment. 15:25:57 dileep, I'll work on that today. My goal would be to have a GBP+neutron box(es) setup (one for controller one for compute potentially ... whatever works) so we don't have to worry about upstream changes. This doesn't mean we don't have to iterate and test on liberty, but it does mean we will have a stable env to work on the GBP neutron side of things 15:26:29 alagalah: there's not rest.py so i've used postman messeges from the very beggining of gbpsfc-dev. have they changed? 15:26:41 dileep, Once that's done, and we have the right kernel mods installed (which would be another advantage of the Box approach) then I am positive that the DRAFT patch I have for fixing tunnel NPE will mean we can finally do neutron+SFC 15:27:15 tomas_c|3, Lets take that offline... I didn't push a repo so perhaps your rest.py's haven't been merged ? 15:27:45 Anything else on this before I change topic to CSIT > 15:27:47 ? 15:28:13 #topic CSIT 15:28:34 #info as of yesterday, we should have Ubuntu in CSIT! Finally! Thanks to edwarnicke 15:28:47 #info and zxiiro tykeal 15:29:20 #info kblagov can you work with dileep on how he can assist with the CSIT setup ? Since this has been blocking us, dileep expressed an interest on working on this with you 15:29:26 kblagov, ? 15:29:38 martin-sunal, ? 15:29:45 #info yes, here is that commit https://git.opendaylight.org/gerrit/#/c/25547/4 15:29:48 yes, I can contact him 15:30:17 dileep, can you guys unicast IRC contact details, or use the list (groupbasedpolicy-dev) ? 15:30:41 #info As a reminder our goals with CSIT are thus: 15:30:48 Sure. Thanks. 15:32:03 #info 1. Nightly run that tests GBPSFC-demo environment for all 3 existing demos via Robot that does a) counts flows to ensure correct count b) checks each flowtable for the right flows (diff against priority / match sorted using something like bash cut to remove timestamp) 3. Ideally pass traffic between containers for each thing in the contract 15:32:38 #info 2. Jenkins verify job (ie when one submits a patch) that does some lightweight testing. TBD by team but should be more than "it builds" ie include the demo env 15:32:53 #info 3. Include clustering which I believe we already have a job for 15:34:17 #info the goal here is that there has been some discussion about UT v CSIT v Functional/Integration tests. As such we want to do as much testing leveraging the CSIT framework as much as possible to cut down on any integration testing in the UT framework (so local builds don't blow out) 15:35:03 #info As such peter_p has a draft document that outlines a proposal for "UT guidelines/best practises" ... it is currently being reviewed by the committers, and once finalised, will publish to the wiki and email the list 15:35:14 #topic Project documentation 15:35:47 #info This week some of the internal Cisco contributors created some web sequence diagrams of some of the aspects of how GBP works internally 15:35:53 #link websequencediagrams.com 15:36:15 #info our plan is once these are revised to publish them to the wiki as a form of documentation. 15:36:59 martin-sunal, Any comments ? 15:37:28 martin-sunal, I take it that's a no :D 15:37:29 alagalah: no 15:37:31 hehehe 15:37:44 #topic GBP Be Renderer SDK 15:38:12 #info yapeng khaldoon hey guys, sorry I know this wasn't on the agenda, but mind if we spend some time discussing this topic ? 15:38:44 sure, khaldoon can give the updates 15:38:51 Updated design document to show the progress for converting PolicyInfo java object into YANG -- please see and provide comments 15:39:02 Created YANG model 15:39:36 wrote the method of putting the info into datastore & still testing 15:39:39 #info khaldoon has created a YANG model for PolicyInfo and updated the design doc 15:39:55 khaldoon, thats awesome, anything you can publish or share as draft ? 15:41:01 #link https://docs.google.com/document/d/1sh9wsKfpra6u5dR4SyEN8FmTw06v3nJ-2q8IUq2MfIk/edit#heading=h.7nr85g2tfoc4 SDK design doc 15:41:03 I will put a batch for review (so people can see) perhaps early next week -- it takes time push code from Huawei 15:41:29 khaldoon, No problem, even if you just want to push the YANG for PolicyInfo as an isolated patch for review that should be fine 15:41:40 khaldoon, You could put it in DRAFT so it doesn't have to hit the build system 15:41:51 ok 15:42:04 Cool 15:42:25 #info khaldoon to push a patch for new PolicyInfo YANG model, potentially next week. 15:42:32 #topic Instrumentation 15:43:19 I just wanted to give a brief update on Instrumentation 15:44:06 #info currently was pulling stats from Endpoints with a goal of leveraging the EPR to know what network context, tenant, EPGs its in and derive stats for those from EP stats 15:45:01 alagalah: symmetric demo works fine. there was an issue on my side. 15:45:11 #info unfortunately the counters are for all traffic, policy and non-policy. This may not be a big deal once you have REAL traffic on a real workload (as the non-policy traffic should be a rounding error) but it wouldn't accurately reflect stats. ie a misbehaving endpoint trying to send a lot of IPV6 traffic for which there isn't a policy shouldn't have those stats counted 15:45:56 #info Currently seeing what other options are available but sFlow requires a collector etc 15:46:38 yapeng, khaldoon Probably not enough time to get into it here, since I have to leave for another meeting, but can you give some thought on what sort of stats FaaS would provide? sFlow isn't a bad idea since its a standard 15:47:12 alagalah, sure 15:47:55 yapeng, khaldoon We could simply give a list of things we need Tx/Rx bytes/packets for and if they are collected via sFlow, SNMP or polling, that could be contained in the renderer, but worried that starts to introduce external dependencies (ie likethe collector) 15:48:00 yapeng, Thanks mate 15:48:14 #topic Open forum - 5min 15:48:18 since we are dealing with physical devices, sflow or netflow maybe a good start point. 15:48:24 #info 5min for anything else... 15:48:51 #info yapeng states that due to FaaS dealing w phys. devices, sFlow/netflow may be good starting point 15:49:23 Anyone else have something they want to cover? 15:49:46 * alagalah looks at watch second counter 15:49:52 * alagalah 10sec going once 15:50:01 * alagalah 20sec going twice 15:50:10 * alagalah 30 second sold... 15:50:17 Ok folks and with that we will call the meeeting 15:50:20 #endmeeting