#opendaylight-group-policy: GBP 9/2

Meeting started by alagalah at 15:07:27 UTC (full logs).

Meeting summary

  1. Agenda bashing (alagalah, 15:07:37)
    1. martin-sunal (martin-sunal, 15:09:41)
    2. https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Team_Meeting GBP agena (alagalah, 15:10:50)
    3. alagalah (alagalah, 15:10:55)

  2. M2 milestone due tomorrow (alagalah, 15:11:27)
    1. currently sticking with our design docs. I don't see any major changes proposed from what I put in the draft.... any comments? (alagalah, 15:11:52)
    2. https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Releases/Beryllium/Release_plan Draft Release Plan Be (alagalah, 15:12:21)
    3. yapeng should we add FaaS explicitly ? (alagalah, 15:12:36)
    4. alaglah will add FaaS to Renderer SDK, otherwise it looks good to go. (alagalah, 15:13:50)

  3. Recent GBPSFC demo issues/fixes (alagalah, 15:14:51)
    1. I recently did a fresh build of the GBPSFC demo env and found some weird issues (alagalah, 15:15:13)
    2. What I saw was that everything was provisioned correctly, and when I ran a test (demo-symmetry) I saw that (alagalah, 15:15:48)
    3. userland flows were being matched, and packets were indeed being sent OUT the VXLAN tunnel, and packets were hitting the remote linux kernel.... (alagalah, 15:16:18)
    4. but were not ingressing into OVS... very odd. (alagalah, 15:16:26)
    5. turns out the Box we were using from AWS, must have upgraded their kernel to 3.19 (alagalah, 15:16:46)
    6. this is incompatible with Pritesh's OVS repo. (alagalah, 15:16:59)
    7. The fix was to use an existing ubuntu/trusty64 box from Hashi, which has 3.13. (alagalah, 15:17:19)
    8. this then worked. What I have subsequently done is create a bespoke box (alagalah/gbpsfc-trusty64) with OVS+NSH, docker+images (alagalah, 15:17:45)
    9. 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) (alagalah, 15:18:13)
    10. 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) (alagalah, 15:18:55)
    11. 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" (alagalah, 15:20:24)
    12. any questions ? (alagalah, 15:20:32)
    13. yapeng says this is great. tomas_c|3 says demo worked... alagalah makes big smiley face, will push (alagalah, 15:21:27)
    14. ACTION: tomas_c|3 alagalah to see why tomas_c|3 doesn't see SF flows being created but alagalah does... (alagalah, 15:23:38)
    15. 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. (alagalah, 15:24:10)
    16. alagalah notes dileep asks if there is a similar neutron+SFC environment. (alagalah, 15:24:37)

  4. CSIT (alagalah, 15:28:13)
    1. as of yesterday, we should have Ubuntu in CSIT! Finally! Thanks to edwarnicke (alagalah, 15:28:34)
    2. and zxiiro tykeal (alagalah, 15:28:47)
    3. 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 (alagalah, 15:29:20)
    4. yes, here is that commit https://git.opendaylight.org/gerrit/#/c/25547/4 (martin-sunal, 15:29:45)
    5. As a reminder our goals with CSIT are thus: (alagalah, 15:30:41)
    6. 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 (alagalah, 15:32:03)
    7. 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 (alagalah, 15:32:38)
    8. 3. Include clustering which I believe we already have a job for (alagalah, 15:32:53)
    9. 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) (alagalah, 15:34:17)
    10. 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 (alagalah, 15:35:03)

  5. Project documentation (alagalah, 15:35:14)
    1. This week some of the internal Cisco contributors created some web sequence diagrams of some of the aspects of how GBP works internally (alagalah, 15:35:47)
    2. websequencediagrams.com (alagalah, 15:35:53)
    3. our plan is once these are revised to publish them to the wiki as a form of documentation. (alagalah, 15:36:15)

  6. GBP Be Renderer SDK (alagalah, 15:37:44)
    1. yapeng khaldoon hey guys, sorry I know this wasn't on the agenda, but mind if we spend some time discussing this topic ? (alagalah, 15:38:12)
    2. khaldoon has created a YANG model for PolicyInfo and updated the design doc (alagalah, 15:39:39)
    3. https://docs.google.com/document/d/1sh9wsKfpra6u5dR4SyEN8FmTw06v3nJ-2q8IUq2MfIk/edit#heading=h.7nr85g2tfoc4 SDK design doc (alagalah, 15:41:01)
    4. khaldoon to push a patch for new PolicyInfo YANG model, potentially next week. (alagalah, 15:42:25)

  7. Instrumentation (alagalah, 15:42:32)
    1. 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 (alagalah, 15:44:06)
    2. 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 (alagalah, 15:45:11)
    3. Currently seeing what other options are available but sFlow requires a collector etc (alagalah, 15:45:56)

  8. Open forum - 5min (alagalah, 15:48:14)
    1. 5min for anything else... (alagalah, 15:48:24)
    2. yapeng states that due to FaaS dealing w phys. devices, sFlow/netflow may be good starting point (alagalah, 15:48:51)


Meeting ended at 15:50:20 UTC (full logs).

Action items

  1. 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)
  2. tomas_c|3 alagalah to see why tomas_c|3 doesn't see SF flows being created but alagalah does...
  3. As a consequence of this, today I am working on our devstack environment, as this explains why I was seeing similar issues with it.


Action items, by person

  1. alagalah
    1. 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)
    2. tomas_c|3 alagalah to see why tomas_c|3 doesn't see SF flows being created but alagalah does...
  2. tomas_c|3
    1. 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)
    2. tomas_c|3 alagalah to see why tomas_c|3 doesn't see SF flows being created but alagalah does...


People present (lines said)

  1. alagalah (83)
  2. yapeng (8)
  3. tomas_c|3 (6)
  4. khaldoon (5)
  5. martin-sunal (3)
  6. odl_meetbot (3)
  7. dileep (2)
  8. kblagov (1)


Generated by MeetBot 0.1.4.