- Schedule (updated Jan 10)
- Projects Intending to Participate in the Iruya Release
- Summary of Release Plans for Iruya
- Iruya Scenario Status
- Milestone Compliance for Iruya (Traditional release process)
- Documentation Compliance for Iruya
- OPNFV Python3 Status for Iruya
- Milestone Exception Requests for Iruya
- Git Tagging Instructions for Iruya
This is the Release Plan for the “Iruya” release of OPNFV.
OPNFV uses scenarios to deploy and test features that are developed by OPNFV projects, or to validate installers, test frameworks, or CI infrastructure.
A scenario is a combination of:
- A collection of upstream components (e.g., OpenStack, OpenDaylight, etc.)
- An installer (i.e., Apex, Compass, Daisy, Fuel)
- A configuration
Progress in the release is partially measured by completion of scenario documentation (MS1), feature implementation (MS5), and test case implementation (MS6).
Note that not all OPNFV projects use scenarios. For example, test frameworks often do not use specific scenarios.
Scenario owners must list their scenarios in the Iruya Scenario Status page.
A scenario owner is the individual that takes responsibility for ensuring that a scenario meets all milestone requirements and is successfully released, per the release schedule. Every scenario must have a scenario owner. Note that the scenario owner is often the same person as the PTL for the feature that is deployed by the scenario.
The scenario owner works with installer owners, test framework owners, and feature project teams to setup Jenkins jobs, fix build issues, enable testing, and resolve bugs and document the scenario. Note that it is NOT the responsibility of installer teams or test framework teams to integrate scenarios, fix build issues, or fix bugs. These teams may provide support for these activities when requested by the scenario owner, however, it is ultimately up to the scenario owner to ensure that the scenario is ready for release.
Requirements for Participation
- Projects must submit a proposal and be approved by the TSC before they may join a release.
- Projects must express their intent to participate in the release between MS0 and MS1. This is true, regardless of whether a project has participated in a past release.
- Note that infrastructure projects, including RELENG, OPNFVDOCS and Pharos are presumed to be participating and are not required to submit intent-to-participate.
- Projects must develop and post a release plan by MS1. The content and format of the release plan is the decision of the PTL and project team. However, fell free to use this suggested template, if you'd like.
Prior to each release cycle the TSC approves a milestone schedule and the version of OpenStack that will be used by projects and scenarios that have OpenStack dependence (most). For the Iruya release, the TSC approved the selection of OpenStack TBD. Therefore, all OPNFV project participating in the release will use this version of OpenStack.
- Projects must adhere to the milestone requirements, according to the schedule approved by the TSC, unless they have an approved milestone exception.
- Milestone compliance will be evaluated by the Release Manager and results will be published on the Milestone Compliance page.
- Projects delivering software for an OPNFV release must be integrated with OPNFV CI, including builds (MS5) and automated testing (MS6).
- Build and test results must be accessible to any user with access to the OPNFV Jenkins dashboard.
- OPNFV projects must track issues, using their own project, within the OPNFV JIRA project.
- Projects should use epic, new feature, story, task, or improvement issue types to represent their plans for the release.
- Projects should use the bug issue type for design problems, build failures, software failures, test failures, performance problems, or programming errors.
- Issues must be assigned to a release using the "fix version" field.
- DO NOT leave the "fix version" field at "None". This creates confusion about the workload for a particular release, since it's unclear which release the project intends to work on a particular release. If you are unclear about when an issue will be resolved, then assign the issue to a valid future release, or to the release named "Future Release".
- DO NOT make up your own version names. Valid version names have already been added to the projects. If your JIRA project does not contain these version names, you may add them yourself, or contact the release manager.
- Valid release names for the Iruya release, are as follows:
- 8.0.0, 8.1.0, 8.2.0
- Future Release
- Note: use this string if you don't anticipate resolving the issue in the current release. However, this means that you should periodically review issues assigned to "Future Release" and reassign them to a specific release.
- In order to support the use of JIRA for program management and for data collection (e.g., Bitergia), projects must do housekeeping on their JIRA project
- Keep the status updated.
- Close issues that have been verified resolved, or that are no longer relevant.
- Update the "fix version" field for issues that you plan to defer to a future release. We should not have unresolved issues that are assigned to past releases.
- Update the "Assignee" field as people leave and join the project.
Documentation compliance is checked at MS4 (preliminary) and MS7 (final). Projects indicate their compliance by completing the documentation compliance tables for MS4 and MS7.
Projects are free to determine what documentation is appropriate for their project. However, the following documents are suggested for various project types:
|Project Type||Installation Instructions||Configuration Guide||User Guide||Scenario Description||Developer Guide||Release Notes|
Format and Structure
- Meets the requirements of all applicable release milestones, especially MS2, MS5, MS6, and MS9, unless there is an approved milestone exception.
- CI deploy job has run at least once during the last week of the release and at least three times over the preceding two weeks.
- Most recent deploy job has passed.
- Majority of deploy jobs over the two weeks preceding the release have passed.
- Functest and/or Yardstick data is available for all builds over the past two weeks where deploy was successful.
- Scenario owner asserts intent-to-release on scenario status page.
- Known issues documented in JIRA and published in documentation for any failing tests.
- Meets the requirements of all applicable milestones, especially MS3 and MS9.
Tool and Test Framework Projects
- Meets the requirements of all applicable milestones, especially MS4 and MS9.
- Passes self-validation tests.
Milestone Gantt Chart
The Gantt chart view (see "Gantt Chart" in Important Links) is useful for seeing an overview of the schedule, including related events (e.g. upstream component releases, community events. plugfests, etc.).
Milestone Schedule and Events
- The deadline time for all milestones is 5 p.m. Pacific Time, unless otherwise stated.
- Color Key:
- Red - feature projects only
- Yellow - requirement for installer projects only
- Blue - requirement for test framework projects only
- Green - scenario owners only
Artifact Delivery Process
On the technical release day:
- Installer teams complete release artifacts according to the following schedule on the day of the technical release (MS11, 12, 13):
- Installer teams in APAC: 5 p.m. (China Standard Time)
- All other installer teams: 3 p.m. (EST)
- LF move artifacts to the appropriate directories and create and verify artifact links for use on the download page.
Within 2 - 3 business days after the technical release day:
- LF will prepare the download page.
- LF will prepare and disseminate press release.
- The download page will go live.
Milestone Compliance Evaluation
Project PTLs should update the specified wiki forms with their compliance evidence as described below. If a wiki page is not specified, please send compliance evidence via email to David McBride.
- No labels