15:07:27 <alagalah> #startmeeting GBP 9/2
15:07:27 <odl_meetbot> 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 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:07:27 <odl_meetbot> The meeting name has been set to 'gbp_9_2'
15:07:37 <alagalah> #topic Agenda bashing
15:09:41 <martin-sunal> #info martin-sunal
15:10:02 <yapeng> alagalah, do we have webex link?
15:10:17 <alagalah> yapeng, no unfortunately, IRC only this week... we will ahve to make do
15:10:30 <yapeng> alagalah, ok.
15:10:50 <alagalah> #link https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Team_Meeting GBP agena
15:10:55 <alagalah> #info alagalah
15:11:27 <alagalah> #topic M2 milestone due tomorrow
15:11:52 <alagalah> #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 <alagalah> #link https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Releases/Beryllium/Release_plan Draft Release Plan Be
15:12:36 <alagalah> #info yapeng should we add FaaS explicitly ?
15:13:00 <yapeng> alagalah, please add FaaS Render item.
15:13:14 <alagalah> yapeng, Can I add it as a sub-item to Renderer SDK ?
15:13:24 <yapeng> alagalah, sure.
15:13:50 <alagalah> #info alaglah will add FaaS to Renderer SDK, otherwise it looks good to go.
15:14:51 <alagalah> #topic Recent GBPSFC demo issues/fixes
15:15:13 <alagalah> #info I recently did a fresh build of the GBPSFC demo env and found some weird issues
15:15:48 <alagalah> #info What I saw was that everything was provisioned correctly, and when I ran a test (demo-symmetry) I saw that
15:16:18 <alagalah> #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 <alagalah> #info but were not ingressing into OVS... very odd.
15:16:46 <alagalah> #info turns out the Box we were using from AWS, must have upgraded their kernel to 3.19
15:16:59 <alagalah> #info this is incompatible with Pritesh's OVS repo.
15:17:19 <alagalah> #info The fix was to use an existing ubuntu/trusty64 box from Hashi, which has 3.13.
15:17:45 <alagalah> #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 <alagalah> #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 <alagalah> #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 <alagalah> #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 <alagalah> #info any questions ?
15:20:52 <yapeng> this is great, I will try it out.
15:21:10 <tomas_c|3> alagalah: demo worked for me with 3.13
15:21:27 <alagalah> #info yapeng says this is great. tomas_c|3 says demo worked... alagalah makes big smiley face, will push
15:21:34 <tomas_c|3> alagalah: but i had to add flows manualy to gbpsfc3 ang gbpsfc5
15:21:52 <tomas_c|3> alagalah: you probably forgot to put flow configuration in sf-config.sh
15:21:53 <alagalah> tomas_c|3, Then it didn't work... now we must find out why, cos that worked for me.
15:22:20 <alagalah> tomas_c|3, It should work OOB ... it only changes the packaging, not the IP addressing etc... so thats very odd...
15:22:47 <tomas_c|3> alagalah: hm, i can try to run it again now and let you know
15:23:38 <alagalah> #action tomas_c|3 alagalah to see why tomas_c|3 doesn't see SF flows being created but alagalah does...
15:24:07 <dileep> is there a demo env for neutron+sfc?
15:24:10 <alagalah> #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 <alagalah> dileep, you're too quick, mate :D
15:24:37 <alagalah> #info alagalah notes dileep asks if there is a similar neutron+SFC environment.
15:25:57 <alagalah> 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 <tomas_c|3> 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 <alagalah> 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 <alagalah> 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 <alagalah> Anything else on this before I change topic to CSIT >
15:27:47 <alagalah> ?
15:28:13 <alagalah> #topic CSIT
15:28:34 <alagalah> #info as of yesterday, we should have Ubuntu in CSIT! Finally! Thanks to edwarnicke
15:28:47 <alagalah> #info and zxiiro tykeal
15:29:20 <alagalah> #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 <alagalah> kblagov, ?
15:29:38 <alagalah> martin-sunal, ?
15:29:45 <martin-sunal> #info yes, here is that commit https://git.opendaylight.org/gerrit/#/c/25547/4
15:29:48 <kblagov> yes, I can contact him
15:30:17 <alagalah> dileep, can you guys unicast IRC contact details, or use the list (groupbasedpolicy-dev) ?
15:30:41 <alagalah> #info As a reminder our goals with CSIT are thus:
15:30:48 <dileep> Sure. Thanks.
15:32:03 <alagalah> #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 <alagalah> #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 <alagalah> #info 3. Include clustering which I believe we already have a job for
15:34:17 <alagalah> #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 <alagalah> #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 <alagalah> #topic Project documentation
15:35:47 <alagalah> #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 <alagalah> #link websequencediagrams.com
15:36:15 <alagalah> #info our plan is once these are revised to publish them to the wiki as a form of documentation.
15:36:59 <alagalah> martin-sunal, Any comments ?
15:37:28 <alagalah> martin-sunal, I take it that's a no :D
15:37:29 <martin-sunal> alagalah: no
15:37:31 <alagalah> hehehe
15:37:44 <alagalah> #topic GBP Be Renderer SDK
15:38:12 <alagalah> #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 <yapeng> sure, khaldoon can give the updates
15:38:51 <khaldoon> Updated design document to show the progress for converting PolicyInfo java object into YANG -- please see and provide comments
15:39:02 <khaldoon> Created YANG model
15:39:36 <khaldoon> wrote the method of putting the info into datastore & still testing
15:39:39 <alagalah> #info khaldoon has created a YANG model for PolicyInfo and updated the design doc
15:39:55 <alagalah> khaldoon, thats awesome, anything you can publish or share as draft ?
15:41:01 <alagalah> #link https://docs.google.com/document/d/1sh9wsKfpra6u5dR4SyEN8FmTw06v3nJ-2q8IUq2MfIk/edit#heading=h.7nr85g2tfoc4 SDK design doc
15:41:03 <khaldoon> 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 <alagalah> 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 <alagalah> khaldoon, You could put it in DRAFT so it doesn't have to hit the build system
15:41:51 <khaldoon> ok
15:42:04 <alagalah> Cool
15:42:25 <alagalah> #info khaldoon to push a patch for new PolicyInfo YANG model, potentially next week.
15:42:32 <alagalah> #topic Instrumentation
15:43:19 <alagalah> I just wanted to give a brief update on Instrumentation
15:44:06 <alagalah> #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 <tomas_c|3> alagalah: symmetric demo works fine. there was an issue on my side.
15:45:11 <alagalah> #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 <alagalah> #info Currently seeing what other options are available but sFlow requires a collector etc
15:46:38 <alagalah> 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 <yapeng> alagalah, sure
15:47:55 <alagalah> 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 <alagalah> yapeng, Thanks mate
15:48:14 <alagalah> #topic Open forum - 5min
15:48:18 <yapeng> since we are dealing with physical devices, sflow or netflow maybe a good start point.
15:48:24 <alagalah> #info 5min for anything else...
15:48:51 <alagalah> #info yapeng states that due to FaaS dealing w phys. devices, sFlow/netflow may be good starting point
15:49:23 <alagalah> 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 <alagalah> Ok folks and with that we will call the meeeting
15:50:20 <alagalah> #endmeeting