fuel_opnfv_integrated-project-guidelines
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
fuel_opnfv_integrated-project-guidelines [2015/10/04 09:26] Jonas Bjurel |
fuel_opnfv_integrated-project-guidelines [2015/12/09 10:18] Jonas Bjurel [How to build a Fuel-Plugin and integrate it with Fuel@OPNFV] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== How to become a Fuel@OPNFV Integrated project ====== | ====== How to become a Fuel@OPNFV Integrated project ====== | ||
| ===== Integration request process ===== | ===== Integration request process ===== | ||
| - | * 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: [[genesis:genesis_work_procedures|How to interface with Genesis? Work procedures]] | + | 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: [[genesis:genesis_work_procedures|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. | + | * 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. | + | 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): |
| - | * 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: | + | * Project description |
| - | * Attend Fuel@OPNFV meetings | + | * Purpose |
| - | * Follow Fuel@OPNFV committer decisions and plans | + | * Dependencies (Packages, Patches, Linux kernel, etc) |
| - | * Execute according to out-set plans | + | * 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. | * 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. | ||
| ===== How to build a Fuel-Plugin and integrate it with Fuel@OPNFV ===== | ===== How to build a Fuel-Plugin and integrate it with Fuel@OPNFV ===== | ||
| - | Instructions on how to build a Fuel-plugin can be found in the [[http://example.com|Fuel Plugin Developers Guideline]] - ** Note that the Fuel Plugin framework capabilities is rapidly evolving** | + | Instructions on how to build a Fuel-plugin can be found in the [[https://wiki.openstack.org/wiki/Fuel/Plugins|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 [[https://github.com/stackforge/fuel-plugin-opendaylight|here]]. | + | A simple description on how to build an NFS fuel plugin can be found [[https://www.mirantis.com/blog/accessing-nfs-from-openstack-how-to-build-a-fuel-plugin/|here]]. |
| + | |||
| + | An example of an ODL Fuel-plugin that was developed for the Fuel@OPNFV Arno release can be found [[https://github.com/stackforge/fuel-plugin-opendaylight|here]], and the corresponding video: [[https://mirantis.webex.com/mirantis/ldr.php?RCID=91679dc40d1c1d0360dc4a9602058aca|Arno SR1 ODL Plugin Demo]] | ||
| 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 [[https://review.openstack.org/#/c/222066/1|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 [[https://review.openstack.org/#/c/222066/1|here]]. | ||
| Line 39: | Line 44: | ||
| You can also find already developed Fuel Plugins [[https://www.mirantis.com/products/openstack-drivers-and-plugins/fuel-plugins/|here]] | You can also find already developed Fuel Plugins [[https://www.mirantis.com/products/openstack-drivers-and-plugins/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)**. | |
| - | + | ||
fuel_opnfv_integrated-project-guidelines.txt · Last modified: 2015/12/09 10:18 by Jonas Bjurel
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
