Differences

This shows you the differences between two versions of the page.

--- 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: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/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  =====
@@ Line 22: / Line 26: @@
 Any needed exemptions to the above guidelines may be raised to the TSC for discussion.   It is envisioned that any exemptions raised after code freeze will be extremely difficult to accommodate.
-====  FaQ  ====
+====  FAQ  ====
 === How are different features/functions enabled for a Brahmaputra installation? ===
@@ Line 28: / Line 32: @@
 === 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? ===
@@ 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.
-=== 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? ===

Wiki

User Tools

Site Tools

Differences

Page Tools