This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
releases:brahmaputra [2015/12/03 10:57] 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 30: | Line 34: | ||
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: | 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. | * //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. | + | * //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 feature installation and/or configuration. Deployment of those is the responsibility of the project that is in need of such a post-install feature and/or configuration. | + | * //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). | * //Test//: Tests (leveraging one of the test frameworks in OPNFV) are carried out post any installation (base, or post-base install). | ||