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
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):
In any case - no matter the model followed, an integrated project will be responsible for the integration with Fuel@OPNFV and the development of:
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:
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
A simple description on how to build an NFS fuel plugin 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 Integrated Fuel artifact is reasonably 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).