Rather than establish a project for OpenDaylight, the OPNFV community has agreed to work on establishing focus community groups where we will describe community engagement practices, identify community leaders, manage our contributions toward those communities and generally get ourselves organised well enough to be a benefit, rather than a burden, to our source communities.
In general, we would like to have a consistent process for feature requests across OPNFV projects. Since the bar in terms of structure and information seems to be highest for OpenStack, we will align feature request documentation on the OpenStack blueprint process. The process is defined for requirements projects.
In short, projects should create a high-level OPNFV requirements document, an OpenDaylight blueprint, and after an OPNFV review, should transition to upstream projects for community review and discussion.
repository/requirements/reference_document.rst- this document should describe the goal at a high level for ONFV consumers
repository/design_docs/reference_document.rst- if features affect multiple projects, there should be a single blueprint per project
OpenDaylight is a collection of loosely affiliated projects, under a common project umbrella. Projects commit to a simultaneous release process with a series of milestones. How the projects organise themselves within that release process is a matter for the project developers.
OpenDaylight projects are organised into three groups:
Projects in Offset 1 typically have deadlines set 1 or 2 weeks after Offset 0 projects, and Offset 2 projects are similarly offset from Offset 1.
Release candidates will be made as necessary, starting 6 weeks after M5 (all projects commit to RC dates).
Table with OPNFV-related projects, links to their feature planning, mailing list and other relevant information.
|Project||Description||Mailing list||Lithium release plan|
|OpenFlow||OpenFlow Plugin Projectfirstname.lastname@example.org||lithium plan|
|SFC||Service Function Chainingemail@example.com||lithium plan|
|GBP||Group-based Policyfirstname.lastname@example.org||Lithium Plan|
|AAA||Authentication and authorization|
|SDNi||Interconnection of multiple SDN controllers|
|DLUX||User interface project|
|Project||Description||Relevant ODL projects|
|Inspector||Inspector's goal is to have a full stack security audit framework. Since part of the audit compliance affects the network, audit requirements need to be communicated to ODL, and implemented there|
|Service Function Chaining||We need to define service function chains, and communicate those to the SDN controller, which will implement the chains through flow management.||SFC and GPB|
|Genesis||Genesis is about deploying OpenDaylight with OpenStack as a Neutron back-end. ODL as a network virtualization solution is a basic requirement||Neutron NBI, OVSDB integration, and OpenFlow primarily|