This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
releases:brahmaputra [2015/11/17 13:53] Frank Brockners |
releases:brahmaputra [2016/01/15 15:08] (current) Frank Brockners [Brahmaputra release page] |
||
---|---|---|---|
Line 5: | Line 5: | ||
* [[releases:brahmaputra:release_plan|Brahmaputra release plan]] | * [[releases:brahmaputra:release_plan|Brahmaputra release plan]] | ||
+ | * [[releases:brahmaputra:daily_status|Brahmaputra daily status updates]] | ||
+ | * [[releases:brahmaputra:minutes|Daily release scrum meeting for Brahmaputra - agendas and minutes]] | ||
+ | * [[:brahmaputra_testing_page#test_scenarios_for_brahmaputra|Test-scenarios for Brahmaputra]] | ||
* [[releases/brahmaputra/upstream_projects_schedules|Schedules of upstream projects relevant for Brahmaputra]] | * [[releases/brahmaputra/upstream_projects_schedules|Schedules of upstream projects relevant for Brahmaputra]] | ||
* [[releases/brahmaputra/release_artifacts_discussion|Discussion on release artifacts for Brahmaputra]] | * [[releases/brahmaputra/release_artifacts_discussion|Discussion on release artifacts for Brahmaputra]] | ||
+ | * [[:functextnexttaks|Functest R2 Brahmaputra wiki]] | ||
+ | * [[https://build.opnfv.org/ci/view/OPNFV%20Platform%20CI%20-%20Alternative%20View/|Latest results of Brahmaputra builds]] | ||
===== Overview ===== | ===== Overview ===== | ||
Line 28: | Line 32: | ||
=== Several projects require specific components installed. How are their needs being met? === | === Several projects require specific components installed. How are their needs being met? === | ||
- | Projects which are interested in a particular combination of features and functionality are expected to supply the configuration files (i.e. the specific versions of “install.yaml” and “features.yaml”) they require to the CI/CD (Octopus) and Release engineering (Releng) projects. In addition, the projects are to supply a set of system tests (typically as part of one of the testing projects like FuncTest, Yardstick, etc.) to verify their functionality, leveraging the particular combination installed – along with a description of what “successful testing” of the feature means. Note that as part of a test, additional features and/or configuration to the installer-supplied setup may need to be added. Using OpenDaylight as an example: OpenDaylight might only come configured with a set of base features by the installation process. Additional features that specific project testing requires would be installed by the test itself, i.e. through feature:install in karaf. | + | Projects which are interested in a particular combination of features and functionality are expected to supply the configuration files (i.e. the specific versions of “install.yaml” and “features.yaml”) they require to the CI/CD (Octopus) and Release engineering (Releng) projects. In addition, the projects are to supply a set of system tests (typically as part of one of the testing projects like FuncTest, Yardstick, etc.) to verify their functionality, leveraging the particular combination installed – along with a description of what “successful testing” of the feature means. Note that as part of a test, additional features and/or configuration to the installer-supplied setup may need to be added ("post-install"). Using OpenDaylight as an example: OpenDaylight might only come configured with a set of base features by the installation process. Additional features that specific project testing requires would be installed by the test itself, i.e. through feature:install in karaf. In summary, a deployment can be phased into 3 steps - typically followed by testing, which would be the 4th step: |
+ | * //Hardware configuration// (so that an installer can execute successfully): Pharos system description and associated hardware configuration scripts supply for this. | ||
+ | * //Base system installation//: One of the deployment tools ("installers") supplies for this. If a project has a specific feature/component that needs to be installed as part of base system setup, the project needs to engage with the installer projects to get its feature installed/configured. Features and functions of the OPNFV platform fall into this category. See also: [[genesis/install_or_post-install|Is my feature an install-time or post-install-time feature?]]. | ||
+ | * //Post base-install feature installation/configuration//: Per the above, several projects might have the need to perform project specific installation and/or configuration (often required by test projects). | ||
+ | * //Test//: Tests (leveraging one of the test frameworks in OPNFV) are carried out post any installation (base, or post-base install). | ||
=== What is the role of testing and test-documentation for the Brahmaputra release? === | === What is the role of testing and test-documentation for the Brahmaputra release? === | ||
Line 36: | Line 44: | ||
A release is constituted through a set of deployments (defined by the configuration files), the associated tests (defined by the test configuration) and the corresponding test results. Note that the set of combinations tested follows interest: For a release not all possible feature/component and deployment configurations will be tested. Testing will follow the interest (and associated invested effort) of the projects participating, rather than try to test any possible combination. | A release is constituted through a set of deployments (defined by the configuration files), the associated tests (defined by the test configuration) and the corresponding test results. Note that the set of combinations tested follows interest: For a release not all possible feature/component and deployment configurations will be tested. Testing will follow the interest (and associated invested effort) of the projects participating, rather than try to test any possible combination. | ||
- | === What does it mean for a feature to be accepted by the Genesis project? === | + | === What does it mean for a feature to be delivered by the Genesis project? === |
- | A feature or functionality accepted by the Genesis project will be supported by all installers participating in Genesis, which are currently Apex (RDO-Manager based), Compass4NFV (Compass based), Fuel@OPNFV (Fuel based), JOID (Juju based). This means that independent of the installer used, a user can assume that a particular installation behavior or functionality be provided by the installer. | + | A feature or functionality delivered by the Genesis project will be supported by all installers participating in Genesis, which are currently Apex (RDO-Manager based), Compass4NFV (Compass based), Fuel@OPNFV (Fuel based), JOID (Juju based). This means that a common deployment of OPNFV can be achieved using any installer according to the common features or functionality delivered by Genesis. |
- | === What if a feature request did not get accepted by the Genesis project? Is there any impact on that feature being available as part of Brahmaputra? === | + | === What if a feature request did not get delivered by the Genesis project? Is there any impact on that feature being available as part of Brahmaputra? === |
- | In case Genesis does not accept a feature, then this simply means that not all installers are going to support a particular feature or functionality. It could still mean that a subset of the installers could support the feature or functionality – and as such be part of the Brahmaputra release. | + | In case Genesis does not define a feature as a common requirement for all installers participating in Genesis, then this simply means that not all installers are going to support this particular feature or functionality. It could still mean that a subset of the installers could support the feature or functionality – and as such be part of the Brahmaputra release. |
=== How will the Brahmaputra release be maintained? Will there be specific service releases? === | === How will the Brahmaputra release be maintained? Will there be specific service releases? === |