#opendaylight-group-policy: GBP 9/9

Meeting started by alagalah at 15:00:18 UTC (full logs).

Meeting summary

    1. alagalah (alagalah, 15:00:23)

  2. Agenda bashing (alagalah, 15:01:37)
    1. meeting held on hangouts: https://talkgadget.google.com/hangouts/_/gz4g7iazv6vburqjnrtkyjknmea (alagalah, 15:01:46)
    2. https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Team_Meeting Agenda (alagalah, 15:02:00)

  3. M2 milestone delivered (alagalah, 15:02:46)
    1. M2 was delivered last Thu, the main point was the final RP (alagalah, 15:03:25)
    2. martin-sunal (martin-sunal, 15:03:46)

  4. NEutron NPE bug (alagalah, 15:03:54)
    1. dileep_r on Hangout says he was able to reproduce it? (alagalah, 15:04:08)
    2. alagalah: patch merged to stable lithium yesterday and master too I believe (alagalah, 15:04:29)
    3. please note there is an issue OVSDB currently that causes NPE in InventoryHelper. alagalah logged a bug, martin-sunal was unable to reproduce but dileep_r can.... (alagalah, 15:05:24)
    4. fix is to: 1. Pull OVSDB stable-lithium-SR1 (important: SR1) (alagalah, 15:05:39)
    5. 2. build by either removing OVSDB from .m2/repository/org/opendaylight OR you could try building with -U ... is mvn clean install -U -DskipTests (alagalah, 15:06:14)
    6. 3. Pull GBP stable/lithium and build: mvn clean install -nsu -DskipTests (alagalah, 15:06:37)
    7. Note this is not the NPE bug I was talking about in the topic (alagalah, 15:08:59)
    8. NPE bug I was referring to which was patched in GBP stable and master, was when we add the chain action to neutron generated policy, we would NPE due to VXLANGPE port not getting added to augmentation. This has been resolved! (alagalah, 15:10:36)

  5. Be Release plan - multirenderer SDK (alagalah, 15:10:56)
    1. khaldoon you around ? (alagalah, 15:11:02)
    2. khaldoon mentioned that he had a policyInfo YANG model that he will push... khaldoon can you expand ? (alagalah, 15:11:47)

  6. Multirenderer SDK - IOVisor agent (alagalah, 15:15:09)
    1. khaldoon's work ties in nicely with the timing of the next item, which is an IOVisor agent. (alagalah, 15:15:31)
    2. The IOVisor project (iovisor.org) leverages eBPF. I am on the TSC for the IOVisor project, and as a POC, will start work on an IOVisor Module for taking policy from ODL GBP and applying it to the linux kernel networking pipeline via IOVisor (alagalah, 15:16:46)
    3. this will be "another" renderer but will be very lightweight from the ODL GBP side I hope, in that we need to potentially serialize policy as YAML to the agent running on the linux host. Hence khaldoon's work on making policyInfo available in the datastore is key (alagalah, 15:17:38)
    4. This is meant as a POC to showcase the capabilities of IOVisor and eBPF (alagalah, 15:18:27)

  7. Instrumentation (alagalah, 15:19:42)
    1. The 3 things we want to achieve with Instrumentation: (alagalah, 15:20:59)
    2. 1. OAM 2. Time-series data a) immediate b) historical/trend (alagalah, 15:21:21)
    3. #2 is proving to be a tricksy hobbit. Just using EP data is not going to yield the results we want, and the alternative is a bunch of interfaces for every object.. Ideally we could have leveraged simple data and derive stats, but thats a bit of a fools errand... (alagalah, 15:22:27)
    4. as discussed last week, the best way forward appears to be sFlow (alagalah, 15:22:39)
    5. since this is an open standard, this *should* be ok with FaaS as well as OVS. (alagalah, 15:22:58)
    6. that was Yapeng's opinion on the last call. (alagalah, 15:23:07)
    7. The big issue here is the collector (alagalah, 15:23:15)
    8. where would it live? Would it be external? It maybe something someone wants to take a look at as there are existing sFlow collectors available we could play with while we see what sort of data it can pull, and how we map that to policy constructs, before we start worrying about whether we want an sFlow collector in the ODL datastore. (alagalah, 15:24:09)
    9. unless someone wants to take that on, it seems the next sensible step is OAM. (alagalah, 15:24:30)
    10. I have some thoughts on leveraging our existing packet Out/In capability we use for neutron external gateway ARP to achieve this. Is anyone interested in working on this with me ? (alagalah, 15:25:02)

  8. Stable lithium update - CSIT (alagalah, 15:26:45)
    1. There appears to have been some confusion about how we progress with Ubuntu in CSIT. We were under the impression that Vagrantfiles would be provided, but it appears we need to provide our own, which makes sense. We have them. Trying to organise a meeting today with "rel-eng" to get some pointers on how to start pushing our Vagrantfiles for GBP-neutron and GBPSFC demo environments up into CSIT. (alagalah, 15:27:50)
    2. dileep wants to work on CSIT, so hopefully he and I can get some help this morning to kick this off from edwarnicke et al (alagalah, 15:28:51)
    3. we could leverage the GBPSFC demo branch that uses a pre-built BOX so we aren't trying to provision everything from SHELL (40+min per VM) .... (alagalah, 15:31:03)
    4. https://github.com/alagalah/gbpsfc-env/tree/box GBP SFC demo that leverages prebuilt box (alagalah, 15:31:17)
    5. note that this box has the OVS pre-installed. There were issues where the install required more RAM but with the BOX I believe since OVS NSH is already installed, we can drop this to 512M RAM which will be nicer for CSIT (alagalah, 15:33:52)
    6. I have tested successfully the same approach for neutron integration ... ie I have a box for devstack-control and a box for devstack-compute with the right repos etc already installed. (alagalah, 15:34:32)
    7. this means you can (from ~/devstack) do "restack.sh" and 4min (control) 1min (compute) have the system up and ready then run through the scripts already in the path (ie step01.sh etc) /vagrant/devstack-scripts/tutorial/ (alagalah, 15:35:28)
    8. The issue with PBR requirements with devstack stable/kilo has been resolved, so we have a couple of avenues to pursue.... (alagalah, 15:36:27)
    9. 1. A fixed BOX configuration for DevStack. This will have the downside that it won't have all the latest updates for stable/kilo but for base neutron testing/development will be ideal. I believe there is a branch for GBP devstack called "newbox" BUT PLEASE DO NOT USE THIS YET (alagalah, 15:37:58)
    10. https://github.com/alagalah/gbp-devstack/tree/newbox new box branch (alagalah, 15:38:04)
    11. this is still under development and should be ready next week. (alagalah, 15:38:16)
    12. with this in place, we can have a locked down devstack that we can use not only for development but also for CSIT since it should remain invariant. (alagalah, 15:38:49)
    13. the next thing we need to progress on is on pulling both the latest stable/kilo and latest master liberty and testing those for upstream compatibility / breakages. (alagalah, 15:39:21)
    14. our current thinking is that the OPNFV project already has test environments that include openstack Tempest testing so we are in the works of leveraging those environments. (alagalah, 15:39:53)

  9. Stable/lithium SFC+neutron working (alagalah, 15:40:49)
    1. yesterday with the tunnel NPE bug fixed I was able to get two NOVA instances talking over SFC!!!! (alagalah, 15:41:06)
    2. woot!!! (alagalah, 15:41:10)
    3. The NPE patch has been merged but that leads onto the next topic for martin-sunal ... (alagalah, 15:41:31)

  10. neutron-mapper redesign (alagalah, 15:41:40)
    1. draft was created (martin-sunal, 15:41:56)
    2. as some of you may know, we have mapped neutron security groups to EPGs (alagalah, 15:42:02)
    3. A Security Group rule is more like an ACL, ie one sided... but an EPG and contract needs an EPG to provide and an EPG to consume (alagalah, 15:42:35)
    4. to make policy resolution happen, each SecurityGroup mapped to an EPG and its Security Group Rules mapped to a contract that the SecurityGroup/EPG PROVIDED. (alagalah, 15:43:08)
    5. this contract was CONSUMED by an EPG known as the ANY group. (alagalah, 15:43:28)
    6. this worked reasonably well in the simple case, but as we tested more complex scenarios with SecurityGroupRules that used either ip-prefix or "remove-security-group" we found instances where we could get asymmetric policy resolution. This has been an outstanding bug since before Li release. (alagalah, 15:44:30)
    7. to that end, martin-sunal has been working ona solution and has a draft that is almost ready for review (alagalah, 15:44:48)
    8. mapping between neutron and GBP entities is much easier (martin-sunal, 15:45:28)
    9. each security group rule is represented as a contract with one subject (martin-sunal, 15:46:04)
    10. a subject has one rule which contains classifier and action reference (martin-sunal, 15:46:50)
    11. classifier ref points to classifier-instance created based on attributes of security group rule (martin-sunal, 15:47:25)
    12. action-instance is always Allow b/c neutron has only this action (martin-sunal, 15:47:44)
    13. a contract is always provided by EPG which represents security-group from security-group-rule (martin-sunal, 15:48:27)
    14. we are testing this implementation now (martin-sunal, 15:48:57)
    15. I expect to have it done and publish at the end of this week? (martin-sunal, 15:49:18)
    16. yes, all attributes from classifier-instance are used in naming convention of rule, clause, etc. (martin-sunal, 15:50:13)
    17. cool so instead of seeing a UUID, we see the actual components of the classifier in the name ? (alagalah, 15:51:50)
    18. ip-prefix from security-group-rule is mapped as endpoint-identification-constraint in clause (martin-sunal, 15:52:01)
    19. UUID is still there - contract does not have name but ID (martin-sunal, 15:53:16)
    20. everything what has name as key contains text representing classifier (martin-sunal, 15:53:53)
    21. Ok thats very cool! (alagalah, 15:55:07)
    22. we are having a side conversation on the google hangout, and dileep asked about conflicts (alagalah, 15:55:22)
    23. even name of contract-named-selector is composed from classifer which is inside contract (martin-sunal, 15:55:23)
    24. ie if we have SG1 and SG2 with each having a rule TCP 80, would there be one or two classifiers in that case ? (alagalah, 15:55:57)
    25. there would be 2 classifiers (martin-sunal, 15:56:47)
    26. sorry, there is one classifier-instance (martin-sunal, 15:57:07)
    27. but 2 contracts using that classifier-instance (martin-sunal, 15:57:26)
    28. I think thats great (alagalah, 15:57:26)
    29. ack, thats what I thought... so in the case where we have that (alagalah, 15:57:37)
    30. two contracts sharing a classifier, if SG2 were to say change its rule from TCP 80 to TCP 80-100 would we create a new classifier and associate it with the contract and hence have two classifiers ? (alagalah, 15:58:14)
    31. exactly (martin-sunal, 15:58:38)
    32. Very cool, and how do you know a classifier is still in use? ie do you do "garbage collection" or is this an item of optimisation for later ? (alagalah, 15:59:11)
    33. classifier-instance is removed immidietely after it is not used anymore (martin-sunal, 15:59:55)
    34. dileep Asks on hangout, do we expect these things to only be changed via neutron or via the ODL GBP GUI ... alagalah prepares a long answer :) (alagalah, 16:00:01)
    35. nice answer martin-sunal (alagalah, 16:00:09)
    36. 1. Neutron expects to be single-writer (alagalah, 16:01:07)
    37. changing of entities which were created based on neutron state is considered as illegal state (martin-sunal, 16:01:09)
    38. 2. As Martin points out, we would consider this illegal state but since we don't have AuthZ/AuthN on parts of the datastore (YET), this is something you can do (alagalah, 16:01:49)
    39. 3. In order to support SFC, we DO modify the ACTION from ALLOW to CHAIN-"foo" (tested yesterday) in order to make this work since Neutron doesn't support SFC (yet) (alagalah, 16:02:19)
    40. martin-sunal Anything to add ? (alagalah, 16:02:28)
    41. I think that basicly I told everything (martin-sunal, 16:03:00)
    42. Ok thats great... so I best wrap this up since its top of the hour (alagalah, 16:03:47)
    43. we will be presenting more on this in the next meeting (alagalah, 16:04:04)
    44. ok with that, lets wrpa this up... thanks everyone for joining (alagalah, 16:04:35)


Meeting ended at 16:04:43 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. alagalah (91)
  2. martin-sunal (24)
  3. khaldoon (6)
  4. odl_meetbot (3)


Generated by MeetBot 0.1.4.