If your project has the intent to become an OPNFV core-integrated project (part of the mandatory requirements for OPNFV Genesis member installers) - you need to follow this process: How to interface with Genesis? Work procedures

• This will generate a workflow of genesis committer voting, which will either result in a mandatory integration of your project in all Genesis member installers or will be abandoned/rejected.

If you instead do not yet want to become a core integrated project, and only want to integrate your project with with one or a few projects - like Fuel@OPNFV. You should issue a Jira request in the Fuel@OPNFV Jira namespace - preliminary indicating (As the integration iterations goes along, these items will be refined):

• Project description
• Purpose
• Dependencies (Packages, Patches, Linux kernel, etc)
• High-availability model
• Upgrade model
• Managed objects (configuration, Fault management, Performance management, etc.)
• Available logs, etc.
• ETA for functional code freeze.
• ETA for integration adaptation to Fuel@OPNFV - E.g. a "Fuel plug-in"

In any case - no matter the model followed, an integrated project will be responsible for the integration with Fuel@OPNFV and the development of:

• A functional Fuel Plug-in.
• Instrumentation of configuration in accordance with the Fuel plug-in concept, as well as a config.yaml template fragment for the plug-in.
• Build environment, including population of the plug-in to the fuel@OPNFV .iso artifact.
• Integration/build-time tests.
• Functional tests, coordinated with the OPNFV Func-test project.
• Higher order tests - I.e. Yard-stick test cases.

The Fuel@OPNFV integration request is acknowledged by assigning the corresponding Jira request to the project lead of the integrated project.

Once agreed in which Fuel@OPNFV project work-package/mile-stone the integration is due, the Jira request goes into status "In progress" - and from now on the integrated project is part of fuel@OPNFV and is expected to:

• Attend Fuel@OPNFV meetings
• Follow Fuel@OPNFV committer decisions and plans
• Execute according to out-set plans
• If an Integrated project fails to deliver according to plan-, quality expectations-, or outset dependencies, Fuel@OPNFV committers may - through voting decide to exclude the integrated project from a work package/mile-stone, or from a project release as a whole.

Instructions on how to build a Fuel-plugin can be found in the Fuel Plugin Developers Guideline - Note that the Fuel Plugin framework capabilities are rapidly evolving

An example of an ODL Fuel-plugin that was developed for the Fuel@OPNFV Arno release can be found here.

Another example is the OVS 2.4 Fuel-plugin that is being developed for the Fuel@OPNFV Brahmaputra release, work in progress can be found here.

In Fuel@OPNFV we require that all artifacts and plugins are part of the the installable .iso image, here is a Make file fragment example that will ensure inclusion of a plug-in to the local .iso image.

You can also find already developed Fuel Plugins here

NOTE It is an absolute requirement that any Fuel artifact is self contained with dependencies, needed patches, etc. - and can be installed/deployed without pulling artifacts from upstream. It is also an equally strong requirement that orderly configuration management practices are enforced such that any top-level Fuel@OPNFV commit can reproduce the exact same output/artifact - RE-PRODUCABILITY - and that upstream component versions can be identified - VISIBILITY.