Jump to: navigation, search

Events:Carbon Dev Forum

Contents

OpenDaylight Carbon Developer Forum - Bellevue Washington September 28th & 29th 2016

If you are a developer within the OpenDaylight Project or would like to become one soon, please join us at our next OpenDaylight Developer Forum. This event is by developers for developers. Topics for this event are collected and decided in two different ways.

  1. Please see the section below and add any topics that you would like to lead and/or attend. List the topic, and your name. If there is a topic that you would like discuss, but you do not feel that you can lead it, please list the topic below and indicate that you are "Interested in Attending", then indicate TBD as the "Topic Leader".
  2. - We will also run an "unconference" at the design forum where we will collect topics of interest during the morning of each day and partition out the available space/time for those interested in those topics to discuss them.

Remember If you haven't yet registered for the DDF you need to do so at this URL: Carbon Developer Design Forum Registration

Topics

OVSDB Project : Carbon Release Planning

  • Name: OVSDB Project : Carbon Release Planning
  • Description: Committers will open the session for the feedback from OVSDB users/consumers and community members. They will discuss the major work that is planned for the OVSDB project for Carbon release. They will also discuss the performance, scalability and documentation of the project and discuss the plan around it for Carbon release. They also want to discuss the plan around how to further improve the quality of OVSDB plugin.
  • Topic Leader: Anil Vishnoi (vishnoianil@gmail.com, IRC:vishnoianil)
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add you name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Anil Vishnoi (vishnoianil@gmail.com, IRC: vishnoianil)
    • Stephen Kitt
    • Vishal Thapar
    • Isaku Yamahata
    • Alon Kochba
    • Daniel Farrell
    • Eric Multanen
    • First Last

OpenFlow Plugin Project : Carbon Release Planning

  • Name: OpenFlow Plugin Project : Carbon Release Planning
  • Description: Planning for Carbon release. Particularly refactoring/cleanup of the OpenFlow Plugin / OpenFlow Java Models, etc.
  • Topic Leader: Abhijit Kumbhare (abhijitkoss@gmail.com, IRC:abhijitkumbhare)
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add you name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Abhijit Kumbhare (abhijitkoss@gmail.com, IRC:abhijitkumbhare)
    • Anil Vishnoi (vishnoianil@gmail.com, IRC: vishnoianil)
    • Shuva Jyoti Kar (shuva.jyoti.kar@ericsson.com. IRC:shuva)
    • Vishal Thapar
    • Manohar SL
    • Guy Sela <guy.sela@hpe.com>
    • Isaku Yamahata
    • Alon Kochba
    • Colin Dixon
    • Gaurav Bhagwani <gaurav.bhagwani@ericsson.com>
    • Hema Gopalakrishnan

Neutron Northbound: Carbon and openstack Ocata Planning

  • Name: Neutron Northbound Project: Carbon (and openstack Ocata) Planning
  • Description: Discuss on direction for openstack Ocata cycle and new features, how to cooperate with other ODL project. Especially ODL netvirt. Feedback from ODL openstack service providers to improve the process.
  • Topic Leader: Isaku Yamahata
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add you name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
  • Slides: https://docs.google.com/presentation/d/1606VOorn9pk90ICw99IeT9tIwB_itoGS2jIErp7pGwg/edit?usp=sharing
  • Trello board: https://trello.com/b/LhIIQ8Z0/odl-neutronnorthbound
    • Isaku Yamahata
    • Vishal Thapar
    • Vivek Narasimhan
    • Alon Kochba
    • Gideon Kaempfer
    • Ariel Noy
    • Eric Multanen
    • Anil Vishnoi
    • Sridhar Gaddam
    • Mike Kolesnik
    • Hema Gopalakrishnan
    • First Last

Spectrometer Planning

  • Name: Spectrometer Planning
  • Description: Let's get together and figure out what the next priorities for Spectrometer should be. Devs and Users are both welcome!
  • Topic Leader: Thanh Ha
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add you name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Thanh Ha <thanh.ha@linuxfoundation.org> IRC: zxiiro
    • Vasu Srinivasan <vasya10@gmail.com> IRC: vasya10
    • An Ho <an.ho at huawei.com>
    • Alon Kochba
    • Colin Dixon
    • Anil Belur
    • Alexis de Talhouët (adetalhouet)
    • Anil Vishnoi

ODL Parent Carbon planning

  • Name: ODL Parent Carbon planning
  • Description: Discuss the scope of ODL Parent, what people would like to see there; topics I'd like to cover include merging parts of Controller, workflows for upstream dependencies in dependency management, third-party Karaf features.
  • Topic Leader: Stephen Kitt
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add you name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Stephen Kitt (skitt)
    • Thanh Ha (zxiiro)
    • Michael Vorburger <vorburger@redhat.com> (vorburger)
    • Robert Varga (rovarga)
    • Anil Belur
    • Alexis de Talhouët (adetalhouet)
    • First Last

Defining and enforcing our policies (SRs, stable branches...)

  • Name: Defining and enforcing our policies
  • Description: We have a number of policies around stable releases, stable branches, the changes allowed after various milestones in our project lifecycles... The enforcement of these policies varies from one project to another though, so in effect they don't serve as much purpose as they could. For example, some projects introduce new features in stable releases (to avoid having to wait for the next cycle). Should we enforce these policies more strictly? What balance should we aim for, between development flexibility and release stability? The aim of this session is to review our existing policies, discuss the reasons which encourage projects to ignore them in some cases, and come up with an action plan: we might need to update our policies, or come up with ways of enforcing them without discouraging contributors...
    • Colin Dixon adds that we should talk about how to balance providing quality releases to our users, which involves tolerating projects that stat testing late, and not pushing the projects that tested earlier and delivered on time.
  • Topic Leader: Stephen Kitt
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add you name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Stephen Kitt (skitt)
    • Michael Vorburger <vorburger@redhat.com> (vorburger)
    • David Goldberg <gdavid@hpe.com>
    • Alon Kochba
    • Daniel Farrell
    • Colin Dixon
    • Andy Vanko (avanko@cisco.com)
    • Alexis de Talhouët (adetalhouet)
    • Thanh Ha (zxiiro)
    • Anil Vishnoi
    • Anil Belur
    • Revital Aronis
    • Luis Gomez
    • First Last

Vision of a future ideal integration (build) architecture to never have any build failures

  • Name: Vision of a future ideal integration (build) architecture to never have any build failures
  • Description: We kick off a number of sometimes fairly long running build jobs on each change (verify, distribution, validate), yet we cannot always reliably detect mechanical build failing problems such as e.g. what happened in https://git.opendaylight.org/gerrit/#/c/43594/ (a parent pom.xml change which broke the build of downstream projects depending on it - despite getting a Verified+1 Build Successful from jenkins-releng), or Checkstyle rule changes which need a manual process to gauge build impacts (why can we not just raise any kind of proposed change and see ALL impacts on Gerrit, automatically?), and probably other kind of changes (please edit this and insert specific examples of other limitation you have run into?).

    One possible solution to this problem could be to move away from continuously integrating all ODL projects every day (by way of Maven's SNAPSHOT concept) and move to completely stable fixed release artefacts; see various emails on the lists re. "Fast and/or Phased", e.g. https://lists.opendaylight.org/pipermail/discuss/2016-July/006751.html. One of the risks of that kind of approach is typically that projects will start to lag behind, and while stable in the present, have to eat the cost of adapting to changes in the future when they upgrade?

    Another possible solution to this problem could be to look more seriously at enforcing API baseline contracts kind of tools (OSGi-based for ODL; but there are others too) - but IMHO it's very hard or impossible to cover things like pom.xml changes or Checkstyle rules with the existing tools in that space, which are typically focused on Java API changes. This kind of stuff is probably still relevant for automated API compatibility checks across releases, but may not be the right answer for fast in-development change management.

    Could another solution for this area be to simply continuously integrate the *entire* ODL caboodle for *every* change - but still do this so fast that it's viable in practice? Imagine you would be guaranteed to always see all build failure impacts incl. broken Maven, compilation, tests etc. of any change on all dependant downstream projects (which are on opendaylight.org; external projects should use release and not SNAPSHOT artifacts, and if they do use SNAPSHOT there is little we can do about them).

    To even dream about this, the only realistic path is probably that a build of a Change on Jenkins would have to be able to re-build incrementally only what changed and what that change impacts - incl. autom. taking dependencies impacts into account! What would need to happen to make this possible?

    This is intended to be a high level "let's dream" vision type of session. In the initial discussion we should not let ourselves be held back with "that's not possible with Maven" kind of limitations, but establish an ideal goal, and then back-track to what would have to be done to achieve that goal. If that's another build technology (Gradle.org? BuckBuild.com? Even more exotic fruits?), no harm in dreaming about it together for the first half of the discussion. In the second half, we could try to break down what this would mean in practice if together we were to do anything about it, and who would like to fund what portions of such an effort.
  • Topic Leader: Michael Vorburger <vorburger@redhat.com> (vorburger)
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Michael Vorburger <vorburger@redhat.com>
    • Guy Sela <guy.sela@hpe.com>
    • Daniel Farrell
    • David Goldberg <gdavid@hpe.com>
    • Colin Dixon
    • Anil Belur
    • Revital Aronis
    • Luis Gomez
    • YOU?

UNI Manager Project : Carbon Planning

  • Name: UNI Manager Project : Carbon Planning
  • Description: We will open the session for discussion of the carbon planning. we will be happy to get feedback from UNI Manager users/consumers and community members. We will plan the Carbon release, and which MEF API's we want to use. We will discuss how we can have multiple southbounds. We will also discuss the testing aspect of the project, and what tests are needed to keep the project stable.
  • Topic Leader: David Goldberg (gdavid@hpe.com, IRC:gdavid_comp)
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add you name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • David Goldberg (gdavid@hpe.com, IRC:gdavid_comp)
    • Guy Sela (guy.sela@hpe.com)
    • First Last

Inversion of Control (IoC) : From wiring objects with Controller Config to OSGi Blueprint to... Guice?

  • New Description: I'd like to share some very recently completed work I've done to partially move netvirt's aclservice-impl from BP XML for beans to @Inject annotation using the blueprint-maven-plugin (with much less XML now!), and see if this inspires you to use the same approach in your projects, and share some thoughts how to possibly go even further and use Guice (not Dagger) in OSGi for wiring to replace BP
  • Original Description: Blueprint uses XML files to wire objects. Other dependency injection frameworks can use static Java for wiring objects; e.g. Spring Framework's @Configuration or Google Guice (which both use Java Reflection internally), or the latest and greatest kid on block Dagger (2; see http://google.github.io/dagger/) which goes further and uses a fully static, compile-time approach based on (transparent; through an APT Annotation Processor) code generation. This leads to very early validation of your graph’s wiring (it detects any errors while you type and any refactoring adjusts the Java wiring code - or causes build compilation failures), and is blazingly fast to start-up at runtime, as it's really just (generated) standard Java to wire objects.

    Let us discuss whether it would be desirable, useful and possible to use a dependency injection framework with Java code instead of XML for wiring objects in ODL? To integrate with OSGi let us look at what integration with Blueprint may make sense?

    This topic is expected to be more of a hands-on hackathon type session than a kind of panel discussion. Maybe we could even end with a sort of early POC built together...
  • Topic Leader: Michael Vorburger <vorburger@redhat.com> (vorburger)
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Michael Vorburger <vorburger@redhat.com>
    • Guy Sela <guy.sela@hpe.com>
    • Colin Dixon
    • Stephen Kitt
    • Anil Vishnoi
    • YOU?

OpenDaylight alternative distribution option without OSGi & Karaf?

  • Description: Over on fd.io Honeycomb they run (parts of) ODL without OSGi & Karaf. Would an alternative packaging without OSGi & Karaf for (some) ODL distribution be of any value & interest? What would it take to make that happen?
  • Topic Leader: Michael Vorburger <vorburger@redhat.com> (vorburger)
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • YOU?

Simple Java Map interface on top of MD-SAL lists

  • Name: Simple Java Map interface on top of MD-SAL lists
  • Description: It would be nice to be able to pass the path (instance identifier) to a YANG list in the MD-SAL and have that return an MD-SAL-backed Java map that would listen to updates and translate put/deletes into appropriate transactions into the MD-SAL. See BUG-5365 for more details.
  • Topic Leader: Colin Dixon
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Colin Dixon
    • Guy Sela <guy.sela@hpe.com>
    • Shuva Jyoti Kar (shuva.jyoti.kar@ericsson.com. IRC:shuva)
    • First Last

Filtering and/or Querying over RESTCONF

  • Name: Filtering and/or Querying over RESTCONF
  • Description: We need a way for applications to query the data they need and not get tons of information back over RESTCONF. The issue with table features for Open vSwitch returning megabytes of data per switch is just one example.
  • Topic Leader: Colin Dixon
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Colin Dixon
    • Guy Sela <guy.sela@hpe.com>
    • Alon Kochba
    • Shuva Jyoti Kar (shuva.jyoti.kar@ericsson.com. IRC:shuva)
    • Alexis de Talhouët (adetalhouet)
    • Shlomi Alfasi (shlomi.alfasi@hpe.com)
    • First Last

Replacing MD-SAL Eventing with an off-the-shelf message bus

  • Name: Replacing MD-SAL Eventing with an off-the-shelf message bus
  • Description: The MD-SAL provides many kinds of events including RPCs, YANG notifications, and data change notifications. It does so using a custom eventing system which has different delivery semantics (both within and outside clustering) and doesn't lend itself to easy tapping and debugging. It would be exciting if we could replace it all with an off-the-shelf (or maybe pluggable different) message bus.
  • Topic Leader: Colin Dixon
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Colin Dixon
    • Shuva Jyoti Kar(shuva.jyoti.kar@ericsson.com IRC:shuva)
    • Guy Sela <guy.sela@hpe.com>
    • Gideon Kaempfer <gidi@hpe.com>
    • Ariel Noy <ariel.noy@hpe.com>
    • Ashutosh Bisht (ashutosh.bisht@ericsson.com)
    • Alexis de Talhouët (adetalhouet)
    • Stephen Kitt
    • Eric Multanen
    • Michael Vorburger <vorburger@redhat.com> (vorburger)
    • Anil Vishnoi
    • Shlomi Alfasi (shlomi.alfasi@hpe.com)
    • Miguel A. Muñoz (miguel.angel.munoz.gonzalez@ericsson.com)
    • Juan M. Fernandez (juan.manuel.fernandez@ericsson.com)
    • Luis Gomez
    • Hema Gopalakrishnan
    • First Last

OpenDaylight Upgrades

  • Name: OpenDaylight Upgrades
  • Description: Let's revisit how we might allow for sane user-tolerable upgrades from major releases where users could bring their data with them. In part, I think this will involve a framework for each project to provide a migration script for their data.
  • Topic Leader: Colin Dixon
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Colin Dixon
    • Shuva Jyoti Kar (shuva.jyoti.kar@ericsson.com IRC:shuva)
    • Alon Kochba
    • Daniel Farrell
    • Gideon Kaempfer
    • Ariel Noy
    • David Goldberg <gdavid@hpe.com>
    • Alexis de Talhouët (adetalhouet)
    • Shlomi Alfasi (shlomi.alfasi@hpe.com)
    • Anil Vishnoi
    • Revital Aronis
    • Miguel A. Muñoz (miguel.angel.munoz.gonzalez@ericsson.com)
    • Luis Gomez
    • First Last

Replacing the MD-SAL data store with etcd?

  • Name: Replacing the MD-SAL data store with etcd?
  • Description: It seems as though etcd3 might provide an off-the-shelf replacement for our own data store that offers tree-based data items with good performance and the ability to watch for data changes on arbitrary subtrees. It's at least worth investigating.
  • Topic Leader: Colin Dixon
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Colin Dixon
    • Shuva Jyoti Kat( shuva.jyoti.kar@ericsson.com IRC: shuva)
    • Manohar SL (email: Manohar.SL@ericsson.com IRC: ManoharSL)
    • Guy Sela <guy.sela@hpe.com>
    • Daniel Farrell
    • Ritu Sood
    • Dileep Ranganathan
    • Gideon Kaempfer
    • Thanh Ha
    • Ashutosh Bisht (ashutosh.bisht@ericsson.com)
    • Isaku Yamahata
    • Michael Vorburger <vorburger@redhat.com> (vorburger)
    • Anil Vishnoi
    • Miguel A. Muñoz (miguel.angel.munoz.gonzalez@ericsson.com)
    • Juan M. Fernandez (juan.manuel.fernandez@ericsson.com)
    • Hema Gopalakrishnan
    • Jie Han (han.jie@zte.com.cn)
    • First Last

Cleaner shutdown and startup

  • Name: Cleaner shutdown and startup
  • Description: As it stands it's very hard to tell if the controller is up, that is all the bundles we think we're loading have come up. There have been some ideas around this in the past that we could probably make work. Also, it's not at all clear that OpenDaylight is capable of shutting down cleanly. We should understand why and how to improve it.
  • Topic Leader: Colin Dixon
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Colin Dixon
    • Guy Sela <guy.sela@hpe.com>
    • Alon Kochba
    • Daniel Farrell
    • Shuva Jyoti Kar (shuva.jyoti.kar@ericsson.com. IRC:shuva)
    • Thanh Ha (zxiiro)
    • Anil Belur
    • Ashutosh Bisht (ashutosh.bisht@ericsson.com)
    • Alexis de Talhouët (adetalhouet)
    • Michael Vorburger <vorburger@redhat.com> (vorburger)
    • Revital Aronis
    • Miguel A. Muñoz (miguel.angel.munoz.gonzalez@ericsson.com)
    • Luis Gomez
    • First Last

opendaylight dashboard with project visibillity

  • Name: opendaylight dashboard with project visabillity
  • Description: creating a dashboard what will show the current status of the code for each project, in a way which will allow easy analysis of regressions in each project including project dependencies, so that if your project's csit tests are failing due to a regression in the openflow project, it will be easy to detect. We can also create a "sanity" csit for the core projects, so we can see the general status of ODL.
  • Topic Leader: Revital Aronis <revital.aronis@hpe.com>
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Revital Aronis <revital.aronis@hpe.com>
    • Alon Kochba
    • Jamo Luhrsen <jluhrsen@redhat.com>
    • Daniel Farrell
    • David Goldberg <gdavid@hpe.com>
    • Luis Gomez
    • First Last

NetVirt - New Features Introduced in Boron

  • Name: NetVirt - New Features Introduced in Boron
  • Description: This session will introduce new features and changes of interfaces in NetVirt used for OpenStack, following the merge with the vpnservice project.
    • Security Groups - Learn based security groups (for OVS-DPDK) and stateful security groups using OVS conntrack.
    • Automatic tunnel configuration on demand
    • VLAN and Flat provider network support for multiple internal and external networks.
    • Discuss floating IP support and changes in bridge port configurations.
    • Centralized NAPT support.
    • Review of current pipeline design, and discussion of possible optimizations and performance considerations. https://docs.google.com/presentation/d/15h4ZjPxblI5Pz9VWIYnzfyRcQrXYxA1uUoqJsgA53KM
    • Discuss L2/L3 services pipeline reversal.
    • Counters and debugging capabilities
  • Topic Leader: Alon Kochba <alonko@hpe.com>, Tali Ben-Meir <tali.ben-meir@hpe.com>, Sam Hague <shague@redhat.com>
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Vishal Thapar
    • Isaku Yamahata
    • Gideon Kaempfer
    • Ariell Noy
    • Eric Multanen
    • Josh Hershberg
    • Sridhar Gaddam
    • Anil Vishnoi
    • Revital Aronis
    • Juan M. Fernandez
    • Aswin Suryanarayanan
    • Hema Gopalakrishnan
    • First Last

NetVirt - Carbon Release Planning

  • Name: NetVirt - Carbon Release Planning - Proposed New Features for Carbon
  • Description: This session will propose NetVirt plans for new features to be done in Carbon. Following is a list of possible enhancements which will be reviewed and ownership will be taken on certain parts. Planning Spreadsheet - add items here
    • Stateful NAPT using conntrack (OVS 2.6)
    • OVS-DPDK stateful SG conntracking testing (OVS 2.6)
    • Distributed NAPT (IP per compute) - lower priority?
    • LBaaS support
    • IPSEC tunnel support (VPNaaS?) / OpenStack GRE provider networks?
    • Static Routes (related to subnet routes in FIB table? supported for BGP implementation only? refers to neutron router route configurations)
    • TOR configuration by ODL
    • Dynamic ARP requests, unknown devices connected to provider network - if all these aren't covered we should add any missing implementation - https://docs.google.com/presentation/d/1ByvEQXUtIyH-H7Bin6OBJNrHjOv-3hpHYzU6Sf6hDbA
    • L2/L3 permanent pipeline reversal, cleanup of pipeline and performance considerations
    • Consider eliminating internal ODL datastore info passed on wire - Internal Tunnel uses this today (problematic for Federation and over-complicates pipeline)
    • Ethernet VPN support (i.e., L2 BGPVPN)
    • Multiple VxLAN tunnel ports
    • IPv6 - track progress and look into roadmap for Carbon - can IPv6 be completed?
    • Flow based VxLAN tunneling
    • Tunnel monitoring - what exists today? What can we improve? BFD? Conflict with using flow based VxLAN tunneling?
    • Transparent VLANs
    • VLAN Aware VMs(TRUNK API)
    • QoS - Metering based QoS and differences from OVSDB based http://docs.openstack.org/draft/networking-guide/config-qos.html
    • TAP - VM Port, Provider network, Tunnel, Tenant traffic in a tunnel
    • TAPaaS
    • SFC - are there plans to move to new NetVirt in Carbon? (for NSH support etc) What functionality is missing?
    • SFC - Plain openstack SFC non NSH VNF
    • Traffic classification for multi underlay steering and SFC
    • Routed network
    • FWaaS v2
    • What's coming in openstack Neutron/networking-odl and long term plan
  • Topic Leader: Alon Kochba <alonko@hpe.com>, Sam Hague <shague@redhat.com>
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Vishal Thapar
    • Vivek Narasimhan
    • Isaku Yamahata
    • Jamo Luhrsen <jluhrsen@redhat.com>
    • Gideon Kaempfer
    • Ariel Noy
    • Stephen Kitt
    • Eric Multanen
    • Josh Hershberg
    • Sridhar Gaddam
    • Tali Ben-Meir
    • Anil Vishnoi
    • Shlomi Alfasi (shlomi.alfasi@hpe.com)
    • David Goldberg (david.goldberg@hpe.com)
    • Brady Johnson (brady.allen.johnson@ericsson.com)
    • Juan Manuel Fernandez (juan.manuel.fernandez@ericsson.com)
    • Manuel Buil (manuel.buil@ericsson.com)
    • Aswin Suryanarayanan
    • Hema Gopalakrishnan
    • First Last

NetVirt - CSIT monitoring and debugging

  • Name: NetVirt - CSIT monitoring and debugging
  • Description: his session will discuss NetVirt CSIT current state, provide pointers on monitoring and debugging, present changes in testing introduced in Boron and planned for Carbon.
    • CSIT monitoring best practices
    • Using flow/group debug prints and counters for debugging of failures
    • Tempest testing, scenario tests and visibility (report and test suite parsing changes)
    • Floating IP and external provider network testing
    • Log parsing and viewing using logs server
    • Testing with various Security Group implementations
    • Testing with networking-odl_v2 neutron ml2 plugin
    • Testing with pseudo-agent port binding method in ml2 plugin
    • Testing with OVS-DPDK
    • Error messages in logs - grepping and failing in future after cleanup.
  • Topic Leader: Alon Kochba <alonko@hpe.com>, Sam Hague <shague@redhat.com>, Jamo Luhrsen <jluhrsen@redhat.com>
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Vishal Thapar
    • Isaku Yamahata
    • Jamo Luhrsen <jluhrsen@redhat.com>
    • Ariel Noy
    • Daniel Farrell
    • Josh Hershberg
    • Al Morton
    • Tali Ben-Meir
    • Venkatrangan Govindarajan
    • First Last

NetVirt: Scale Testing

  • Name: NetVirt: Scale Testing
  • Description: Review Test Plans for NetVirt see NetVirt Scale Testing
  • Topic Leader: Andre Fredette <afredette@redhat.com>
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Alon Kochba
    • Isaku Yamahata
    • Vishal Thapar
    • Jamo Luhrsen <jluhrsen@redhat.com>
    • Daniel Farrell
    • Gideon Kaempfer
    • Ariel Noy
    • Al Morton
    • Tali Ben-Meir
    • Anil Vishnoi
    • Shlomi Alfasi (shlomi.alfasi@hpe.com)
    • Revital Aronis
    • First Last

NetVirt: Retrospective

  • Name: NetVirt: Retrospective
  • Description: Boron has been our first release with the new NetVirt. We have a new project, new code, and new people working together. This is intended as an interactive session where we discuss
    • What went well?
    • What went wrong?
    • What can we do better moving forward?
  • Topics may include, but are not limited to:
    • Procedural and Teamwork topics
    • Architecture
    • Implemenation
  • Topic Leader: Andre Fredette <afredette@redhat.com>, Sam Hague <shague@redhat.com>, Vishal Thapar <vishal.thapar@ericsson.com>
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Andre Fredette
    • Josh Hershberg
    • Oded Shvartz
    • Sam Hague
    • Michael Vorburger
    • Alon Kochba
    • Gideon Kaempfer
    • Ariel Noy
    • Vishal Thapar
    • Tali Ben-Meir
    • Anil Vishnoi
    • Shlomi Alfasi (shlomi.alfasi@hpe.com)
    • Sridhar Gaddam
    • Revital Aronis
    • Aswin Suryanaryanan
    • First Last

Federation

  • Name: Brainstorm a new MD-SAL events federation service
  • Description: The idea would be to have the ability to federate events coming from MD-SAL to ODL instances outside of the local cluster. The first concrete use case would be to federate NetVirt such that Neutron networks on different sites (OpenStack clouds) could be seamlessly interconnected at L2 or L3 over VXLAN tunnels just like compute hosts are connected within a single site. The difference between this proposal and other proposals from the past is that we seek to have a way to perform ordered messaging between ODL clusters with the possibility of transforming information before/after federating it.
    • Should this be combined with #Cross Site Manager below? --Colin Dixon The scope of Federation is beyond that of the Cross Site Manager. IMHO, better to keep separate. -- Gideon Kaempfer
  • Topic Leader: Guy Sela <guy.sela@hpe.com>, Gideon Kaempfer <gidi@hpe.com>
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Alon Kochba
    • Ashutosh Bisht (ashutosh.bisht@ericsson.com)
    • Colin Dixon
    • Shuva Jyoti Kar (shuva.jyoti.kar@ericsson.com. IRC:shuva)
    • Alexis de Talhouët (adetalhouet)
    • Isaku Yamahata
    • Ariel Noy
    • Anil Vishnoi
    • Shlomi Alfasi (shlomi.alfasi@hpe.com)
    • Miguel Angel Muñoz (miguel.angel.munoz.gonzalez@ericsson.com)
    • Luis Gomez
    • First Last

Cross Site Manager

  • Name: Cross site manager
  • Description: We want to define the process to configure relationships between neutron networks in different Openstack sites. Elements attached to a network defined in one site should be accessible to other sites in the same "global-network". In this session we want to discuss how plugins (such as a netvirt plugin to be described) should be implemented and how to use the federation service to achieve this functionality. In addition we would like to propose a new UI to manage cross site configuration and monitoring.
    • Should this be combined with #Federation above? --Colin Dixon The scope of Federation is beyond that of the Cross Site Manager. IMHO, better to keep separate. -- Gideon Kaempfer
  • Topic Leader: Shlomi Alfasi (shlomi.alfasi@hpe.com), Ariel Noy (ariel.noy@hpe.com )
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add you name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Colin Dixon
    • Alon Kochba
    • Gideon Kaempfer
    • Alexis de Talhouët (adetalhouet)
    • Isaku Yamahata
    • Anil Vishnoi
    • First Last

Unifying BGP implementations/needs

  • Name: Unifying BGP implementations/needs
  • Description: As I understand it, we have at least 4 different places we're using BGP: bgpcep, atrium, snmp4sdn, and vpnservice. I believe that atrium and vpnservice use Quagga, while snmp4sdn uses a forked version of bgpcep. It would be good to figure out if there was a way to allow all the projects to (at least optionally) consume the bgpcep implementation and maybe also create a simple way to switch between Quagga and bgpcep in keeping with our modular design.
  • Topic Leader: Colin Dixon?
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Colin Dixon
    • Brian Freeman
    • Ajay Lele
    • Alexis de Talhouët (adetalhouet)
    • Vivek Srivastava
    • Luis Gomez

Release Discussion

  • Name: Release Discussion
  • Description: Discussion for release for Carbon and future
  • Topic Leader: Colin Dixon <colin at colindixon.com>, Thanh Ha <thanh.ha@linuxfoundation.org>, An Ho <an.ho at huawei.com>
  • Details:
    • Observed Reality:
      • We have different projects at different "phases": some projects are new with steep learning curve of the release process; some projects are in active development, changing their API midway through a release; some projects are in maintenance mode with no development (and some no committers).
    • Open Questions:
      • Milestone: How can we improve the manner with which we collect and milestone updates from projects. How can we improve the milestone questions to minimize overhead for projects (such as asking for New Project Checklist from Existing projects). How can we improve the verification of
      • Gamification of Release Checklist Items: How can we incentivize projects to complete release items? How can the published results be used end users?
      • Requirements: How can we verify the reported status of projects at Milestone, RCX, etc. checkpoints? How can we verify the completion of the release requirements at each checkpoint (dos reqs, test reqs, MX, RCX status reqs, autorelease reqs)? How can we encourage projects to follow the release timeline requirements of projects during the release at each checkpoint?
      • Peer Review: How can we peer review release items? How can we encourage to projects to review the documents of other projects including per project release plans, user/developer guides, milestone reports, release notes, system test plan, etc.
      • Release Test Reporting: How can we encourage projects to report their RCX testing? How can we encourage projects with waivers to report their manual/external testing?
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Thanh Ha (zxiiro)
    • Anil Belur
    • Alexis de Talhouët (adetalhouet)
    • Stephen Kitt
    • Daniel Farrell
    • David Goldberg <gdavid@hpe.com>
    • Michael Vorburger <vorburger@redhat.com> (vorburger)
    • Anil Vishnoi
    • Revital Aronis
    • Luis Gomez
    • First Last

Horizontal scaling of ODL modules / Apps

  • Name: Horizontal scaling of ODL modules / Apps using open-source datastore such as Cassandra
  • Description: Current MD-SAL based datastore offers only strong consistency model for datastore. We want to discuss mechanisms to integrate other open-source datastores (such as Cassandra etc) to ODL. This will allow ODL modules to trade-off consistency and availability parameters (as defined in CAP theorem) for failures scenarios or consistency and latency (as defined in PACELC theorem) for normal operations. ODL modules would be able to select a datastore that is most appropriate for its workload. This include scenarios where a module needs high throughput / scalable throughput with low latency when it can support eventual consistency.
  • Topic Leader: Ashutosh Bisht.
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • First Last
    • First Last

Migrating to RESTCONF draft 11 (now 16?)

  • Name: Migrating to RESTCONF draft 11 (now 16?)
  • Description: As part of Boron we have released support for RESTCONF draft 11, which should be very close to the final RFC form of the RESTCONF IETF draft. Nobody is currently using it to my knowledge, but we would like to eventually move in that direction. This will also necesitate getting #YANG 1.1 Support.
  • Topic Leader: Colin Dixon (and hopefully others)
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Colin Dixon
    • First Last

YANG 1.1 Support

  • Name: YANG 1.1 Support
  • Description: Recent drafts of RESTCONF require the use of YANG 1.1. OpenDaylight only supports YANG 1.0. We need to close this gap if we want to be compliant with the eventual RFC version of RESTCONF. This also raises several questions including:
    1. how long do we need to support RESTCONF with YANG 1.0?
    2. do we need to support RESTCONF draft 02 with YANG 1.1?
    3. how do we internally handle the fact that we may have internal models that are in both YANG 1.0 and 1.1?
  • Topic Leader: Ryan Goulding
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Ryan Goudling
    • Colin Dixon
    • First Last

Clustered Performance Improvements

  • Name: Clustered Performance Improvements
  • Description: As it stands our clustered performance is notably lower than when not clustered. I (Colin) believe that this is mainly for one reason with two causes. The reason is that we have a limited number of transactions can be in flight. This is caused by (a) the clustering back-end, which can only have one transaction going through the three-phase-commit at a time, and (b) projects that make blocking calls on transactions and thus only allow one or a small number a time.

    To fix this, we would need to do some subset of few things:
    1. transparently batch transactions in the clustering backend
    2. batch transactions into one explicitly at the application level
    3. pipeline transactions in the clustering backend to allow for more than one to complete at a time
    4. remove artificial serialization of transactions in appliations
  • Topic Leader: Colin Dixon, Tom Pantelis, and Robert Varga
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Colin Dixon
    • Tom Pantelis
    • Robert Varga
    • Shuva Jyoti Kar
    • Daniel Farrell
    • Michael Vorburger <vorburger@redhat.com> (vorburger) <= if free (interested mostly in part (b))
    • Anil Vishnoi
    • Miguel A. Muñoz (miguel.angel.munoz.gonzalez@ericsson.com)
    • Juan M. Fernandez (juan.manuel.fernandez@ericsson.com)
    • Luis Gomez
    • First Last

Moving to Java/YANG binding specification v2

  • Name: Moving to Java/YANG binding specification v2
  • Description: The Java/YANG binding specification v2 should be mostly done in in the Boron release, but nobody (or nearly nobody) is using it. Covering how to move and at what time-frame would be useful. More information can be found at the August 15th TWS call.
  • Topic Leader: Colin Dixon, but hopefully somebody from the team that built it. If they're not in attendance, I guess we punt.
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Colin Dixon
    • First Last

ODL Testing coverage, reporting and process

  • Name: Improving ODL testing Methodologies
  • Description: Creating a process which will allow projects to manage and track testing tasks and status in a way that will allow transparency of the testing coverage for each feature in the project. In addition, this will reduce the duplicate work that is being done these days, especially with manual testing which isn't even documented.
  • Topic Leader: Revital Aronis
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Revital Aronis <revital.aronis@hpe.com>
    • David Goldberg <gdavid@hpe.com>
    • Alon Kochba
    • Jamo Luhrsen <jluhrsen@redhat.com>
    • Daniel Farrell
    • Thanh Ha (zxiiro)
    • Al Morton
    • Michael Vorburger <vorburger@redhat.com> (vorburger) <= MAYBE
    • Luis Gomez
    • First Last

New "end2end" test style (Java JUnit; non-*IT, not CSIT)

  • Description: I'd like to share some ongoing work I'm doing to write tests in netvirt's aclservice-impl & elanmanager-impl in a new "end2end" test style for offset 2 functional modules, at least some of which lack tests of real value IMHO (this effort does not target offset 0/offset 1 infrastructure framework projects). The approach in this style is pure Java JUnit, pure standalone Java (non-OSGi; so not really like a full-blown IT, as it's often not really needed IMHO), and non-CSIT. These tests should focus on simple testing of your bundles' API and their expected effect / outcome on the system, not their internal implementation details. Some of the dependant services in other modules are typically stubbed. Mocking is fairly limited or avoided all together. The internal beans of one bundle are all used together however. This is much more than your typical unit test, as those would, in theory at least, test each internal class separately; and use mocking, sometimes perhaps too extensively. Wiring of all bundle internal beans is through post-BP @Inject (successfully explored in netvirt), discussed in more details in another session. Conceptually this kind of test style is thus positioned between unit tests and IT/CSIT. Interested in feedback from attendees if they think this is worthwhile pursuing in general (not limited to netvirt), and see if this inspires you to use the same approach in your projects, or hear your objections. Session may include some live coding. It would also be good to agree on a name for this style (other than my only tentative "end2end" convention).
  • Topic Leader: Michael Vorburger <vorburger@redhat.com> (vorburger)
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Sridhar Gaddam
    • Revital Aronis
    • First Last
  • WHERE AND WHEN: This session does not appear on https://opendaylightsummit2016.sched.org, but I'm hoping we can touch upon this as part of the https://opendaylightsummit2016.sched.org/event/8NPS/inversion-of-control-ioc-from-wiring-objects-with-controller-config-to-osgi-blueprint-to-dagger-michael-vorburger session - please join that.

Integration/[Test|Packaging|Distribution] Open Forum

  • Name: Integration/[Test|Packaging|Distribution] Open Forum
  • Description: This is an open discussion for planning and setting goals for the Carbon release for all projects under the Integration umbrella. Some items likely to be discussed are test refactor/cleanup, automation of performance and scale tests, cluster testing, job reorganization, patch gating, distribution health (e.g. testing it, size of it), packaging flavors and delivery, etc.
  • Topic Leader: Jamo Luhrsen, Daniel Farrell, Luis Gomez
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Jamo Luhrsen <jluhrsen@redhat.com>
    • Al Morton
    • Thanh Ha (zxiiro)
    • Daniel Farrell
    • Anil Belur
    • Revital Aronis
    • Alon Kochba
    • Venkatrangan Govindarajan
    • Luis Gomez
    • First Last

Genius: Carbon Planning

  • Name: Genius Project: Carbon Planning
  • Description: Discuss the scope of carbon cycle, new features and improvements to be added. Discuss the usage and benefits of available genius features. Understand the needs of applications using or planning to use genius framework. Also discuss the integrations of new applications over genius framework.
  • Topic Leader: Vivek Srivastava, Faseela K.
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add you name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Tali Ben-Meir
    • Vishal Thapar
    • Andre Fredette
    • Juan M. Fernandez
    • Alon Kochba
    • Hema Gopalakrishnan

Genius: OF Tunnel Proposal

  • Name: Genius Project: OF Tunnel Proposal
  • Description: Discuss the scope for implementation of OF based tunnels. Currently genius programs one tunnel port per remote end point, this increases the number of tunnel ports on a switch as the scale increases, if we are using a full mesh as provided by genius ITM feature. This discussion intend to analyze the approach to be taken for this as there are multiple things to be taken care for this functionality to be in place.
  • Topic Leader: Vivek Srivastava, Vishal Thapar.
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add you name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Tali Ben-Meir
    • Andre Fredette
    • Juan M. Fernandez
    • Alon Kochba

Genius: Enable ResourceManager usage

  • Name: Genius Project: Enable ResourceManager usage
  • Description: Resource Manager is the genius module which will enable easy application co-existence by dynamically allocating non-conflicting resources like table-ids, group-ids and other unique-ids. This discussion is to analyze how to promote the usage of resourcemanager among applications so that applications need not bother about the resources they are managing.
  • Topic Leader: Vivek Srivastava.
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add you name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Tali Ben-Meir
    • Andre Fredette
    • Juan M. Fernandez
    • Alon Kochba

Genius: Scaling Service Bindings

  • Name: Genius Project: Scaling Service Bindings
  • Description: Currently genius supports binding a maximum of 8 services on an ingress interface. This discussion is how to improve this for Carbon, and understand the various concerns from application perspective on the various service binding features provided by genius so that enhancements can be done for Carbon
  • Topic Leader: Vivek Srivastava, Faseela K
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add you name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • Tali Ben-Meir
    • Andre Fredette

SFC & VPN integration

  • Name: SFC & VPN Integration
  • Description: As of today, it is not possible to integrate SFC with VPNs. There are several things missing and it would be great to brainstorm a plan about how to address these problems in order to have Netvirt’s VPN Service integrated with SFC ready in Carbon release. Probably the most important gap is modeling the entry point and the exit point of a chain, so that for example packets can be sent to the VPN service once they exit the chain. Today the entry and exit points are provided by the classifier, so it must be also considered as part of the integration with Netvirt’s VPN.
  • Topic Leader: Manuel Buil, Juan M. Fernandez, Prem Sankar, Brady Johnson
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • First Last
    • First Last

SFC Carbon Feature List

  • Name: SFC Carbon Feature List
  • Description: Along Boron release, we have discussed about several features and enhancements we would like to introduce in SFC project, now it is time to start talking about what we can introduce in Carbon release. Here there is a list of features we have discussed so far and that we might probably extend during the Design Forum:
    • SFC Genius integration and coexistence with other Genius based and non-Genius based applications (there is a topic about that proposed by our colleagues in Netvirt project)
    • VPN integration (there is another SFC topic to talk about that in more detail)
    • SFC Proxy
    • Load Balancing & Failover, Mirror/Receive-only SFs, Bypass of Service Functions/Offload
    • Bare-metal SFs support
    • Hierarchical Service Chaining
  • Topic Leader: Juan M. Fernandez, Manuel Buil, Brady Johnson
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • First Last
    • First Last


Sample Design Forum Discussion Topic

  • Name: Sample Name (eg Improving Boron Documentation)
  • Description: Description of the topic and the objective/outcome desired at the end of the discussion.
  • Topic Leader: The person that is knowledgeable enough to lead and moderate this discussion.
  • Interested In Attending: If you are interested in this discussion and would like to participate in it, please add your name and email here (one name/email per line please). We'll use this information when building the schedule so that we minimize overbooking people where possible.
    • First Last
    • First Last