El-Alto Release
El-Alto Release Planning
The El-Alto release content is being planned. Currently the proposed contents include:
- Refactoring
- JIRA Backlog Reduction (defects, etc.)
- Vulnerability issues
- Test Coverage including jS
- Test Automation & CI/CD pipeline
- Deployment procedure
- Documentation
The release contents will be prioritized at the 2019 El-Alto DDF in Stockholm.
TSC priorities:
- Security
- Documentation
- Don't break the build
El-Alto Release Calendar
El-Alto Release Calendar (tabular)
| Milestone | Date | Deliverable | Notes |
|---|---|---|---|
| Dev1 Start |
| Vetted Jira list for the EarlyDrop (ED) | List of planned jiras for the development sprint (M1) |
| M1 checkpoint |
| TSC reviews and sign-off on intended El Alto Content | Content defined by fixVersion = "El Alto Release" Early Drop content defined by: label contains "El_Alto_Early_Drop" |
| Test Plan Review |
| Early drop and Final release test plan review and sign off by TSC | |
| Test1 Start |
| Test to deliver ED | Phased integration and test plan. (M4_early_drop) Run daily sanity on El Alto released images, and start vFW, vLB and vCPE use case testing All containers for ED are due to be delivered to testing/integration |
| Dev1 End |
| Priority 0 vulnerabilities addressed | List of completed jiras due API documentation complete Arch changes reviewed and documented |
| Dev2 Start |
| Fixes only to support ED | Integration team drives bug list priority. All other development deferred check in until Dev3 Integration will work with dev teams to close highest/high priority jiras discovered during integration test. All integration tests should be finished three days before ED release so we will have time to update release note, put tag on branches, etc. |
| Dev2 End |
| ED released | Complete release - includes rel_notes, named release, branch. (M2/M3 milestone) |
| Test1 End |
| ED released | Complete release - includes rel_notes, named release, branch. (Sign_off_early_drop) |
| EarlyDrop |
| ||
| Dev3 Start |
| ||
| Test2 Start |
| ||
| Dev3 End |
| All code complete (M4) | |
| Test2 End |
| ||
| Test3 Start |
| Pair-wise testing (1 wk only) and Integration (RC0 - 9/19) All containers due to be delivered to testing/integration | |
| Test3 End |
| All docs complete: reviewed and cherry-picked into stable | |
| El Alto Release |
|
Dublin Release
Dublin Release Planning - NOT UPDATED, please refer to the Dublin Release Calendar
Dublin Release Calendar
| Review | Milestone | Date | Events |
|---|---|---|---|
| Last day for Service Providers to submit their priorities for Dublin | Nov 1, 2018 | ||
| Last day for overall providing use case/functional requirements as a candidates for Dublin | Nov 15, 2018 | ||
| Kick-Off (Open Intent To Participate) | M0 | Nov 15, 2018 | Opening of Release Planning
|
| Last day for getting all of the ONAP Platform requirements (high level impacts for architecture, security, projects, S3P etc.) and getting a single consolidated list so all of the projects have full picture of what is required from them. | Nov 29, 2018 | By this date, all ONAP use cases/ ONAP platform functional requirements (high level impacts) need to be discussed with a different projects, and demanded scope of development should be clear to the projects: For use cases/functional requirements (high level impacts) :
(link to current use cases/functional requirements proposals description: | |
| Project Submission Closure | Nov 30, 2018 | Last Date to announce Intention to Participate | |
| Project Proposal Approved | Dec 13, 2018 | Use Case Analysis and Potential impacts to VNF Requirements identified. The TSC has a goal to review and provide its disposition on all submitted projects proposal. This is the last date for TSC to formally approved New Project Proposal | |
| Project Planning Closure | Jan 10, 2019 | Project Planning submission, by this date all projects have submitted in wiki their Release Planning materials. That will give everyone to time to understand project scope and dependencies. | |
| Planning | M1 | Jan 24, 2019 (ALL except Integration) Jan 31, 2019 (Integration) | Planning process complete, all Project Deliverables are defined (including functional architecture, scope, dependencies,...) Integration Team has defined the vendor Equipments list and the End 2 End Release Test Cases are fully defined. The Document and Training teams have defined their plans. The packaging and installation strategy is defined. initial impacts to VNF Requirements (EPICs) identified by use cases and ONAP platform component projects. To pass the M1 milestones, all approved projects have to:
|
| Functionality freeze | M2 |
Feb 28, 2019 | Functionality freeze, no new visible functionality is to be added to the current ONAP release. Each Project team has defined and documented their Functional Test Cases. The vendor equipments have been delivered. A stable document describing the API is documented and available in wiki. Base set of impacts to VNF Requirements identified by use case/ project. |
| API Freeze | M3 | March 14, 2019 | API/data model freeze. Mark the end of API and Data Model change. API and Data Model are now Frozen. Any changes to the API must be brought to the knowledge of the TSC for review and approval. 50% of Functional Test Case are automated. |
| Code Freeze | M4 |
April 11, 2019 | Code Freeze. Mark the end of the Features coding. Jira issues are either fixed in the current release or assigned to next release. 100% of Functional Test Case are automated. End 2 End Release Test Cases are implemented (Integration Team). All new VNF Requirements planned for the release reviewed and implemented in VNF Requirements project. |
| Integration | RC0 |
May 2nd, 2019 | Release Candidate 0 RCs are to ensure proper alignment and execution on End 2 End Release Test Cases and End 2 End functional Test Cases. Project Team focused its effort on:
|
| RC1 |
May 16th, 2019 | Release Candidate 1 | |
| Marketing: Outline for written content agreed with LF marketing | May 16, 2019 | ||
| Marketing: Near-final draft for written content | May 23, 2019 | ||
| RC2 |
May 30th, 2019 | Release Candidate 2 | |
| Marketing: Content freeze | May 30, 2019 | ||
| Marketing: New video content | May 30, 2019 | ||
| Sign-Off | Release Delivery |
June 6th, 2019 | Dublin Release Sign-Off |
| Marketing: Public announcement | June 13th, 2019 |
Casablanca Maintenance Release
The main timeline is proposed below. The full deck as discussed at PTL meeting on Dec 3 is here. Scope of the MR will be finalized at "M1" on Dec 10, 2018.
Casablanca Release
This release calendar below has been presented during ONAP Break out session at ONS Los Angeles Developers on March 26, 2018.
Casablanca Release Planning
Link to PDF
Casablanca Release Calendar
| Review | Milestone | Date | Events |
|---|---|---|---|
| Kick-Off (Open Intent To Participate) | M0 | May 25, 2018 | Opening of Release Planning
|
| Project Submission Closure | June 07, 2018 | Last Date to announce Intention to Participate | |
| Project Proposal Approved | June 14, 2018 | The TSC has a goal to review and provide its disposition on all submitted projects proposal. This is the last date for TSC to formally approved New Project Proposal | |
| Project Planning Closure | June 21, 2018 | Project Planning submission, by this date all projects have submitted in wiki their Release Planning materials. That will give everyone to time to understand project scope and dependencies. | |
| Planning | M1 | June 28, 2018 | Planning process complete, all Project Deliverables are defined (including functional architecture, scope, dependencies,...) Integration Team has defined the vendor Equipments list and the End 2 End Release Test Cases are fully defined. The Document and Training teams have defined their plans. The packaging and installation strategy is defined. To pass the M1 milestones, all approved projects have to:
|
| Functionality freeze | M2 | July 26, 2018 | Functionality freeze, no new visible functionality is to be added to the current ONAP release. Each Project team has defined and documented their Functional Test Cases. The vendor equipments have been delivered. A stable document describing the API is documented and available in wiki. |
| API Freeze | M3 | August 23, 2018 | API/data model freeze. Mark the end of API and Data Model change. API and Data Model are now Frozen. Any changes to the API must be brought to the knowledge of the TSC for review and approval. 50% of Functional Test Case are automated. |
| Code Freeze | M4 | Sept 20, 2018 | Code Freeze. Mark the end of the Features coding. Jira issues are either fixed in the current release or assigned to next release. 100% of Functional Test Case are automated. End 2 End Release Test Cases are implemented (Integration Team). |
| Integration | RC0 | Oct 11, 2018 | Release Candidate 0 RCs are to ensure proper alignment and execution on End 2 End Release Test Cases and End 2 End functional Test Cases. Project Team focused its effort on:
|
| RC1 | Oct 25, 2018 | Release Candidate 1 | |
| Marketing: Outline for written content agreed with LF marketing | Nov 1, 2018 | ||
| Marketing: Near-final draft for written content | Nov 8, 2018 | ||
| RC2 |
Nov 27, 2018 | Release Candidate 2 TSC decision on Nov 8 to postpone RC2 to Nov 27. | |
| Marketing: Content freeze | |||
| Marketing: New video content | |||
| Sign-Off | Release Delivery |
Nov 30, 2018 | Casablanca Release Sign-Off TSC decision on Nov 8 to postpone Sign-Off to Nov 30. |
| Marketing: Public announcement |
Beijing Release
This release calendar below has been approved by TSC at Santa Clara Developers F2F on Dec 13, 2017.
Beijing Release Planning
Link to ONAP Beijing Release Planning (PDF) as presented at Paris F2F, Sept 2017
Update ONAP Beijing Release Planning (PDF) as presented at Santa Clara F2F, Dec 2017
Beijng Release Calendar
| Review | Milestone | Date | Events |
|---|---|---|---|
| Kick-Off (Open Intent To Participate) | M0 | November 16, 2017 | Opening of Release Planning
|
| Project Submission Closure | November 30, 2017 | Last Date to announce Intention to Participate | |
| Project Proposal Approved | December 13, 2017 | The TSC has a goal to review and provide its disposition on all submitted projects proposal. This is the last date for TSC to formally approved New Project Proposal | |
| Project Planning Closure | Jan 8, 2017 | Project Planning submission, by this date all projects have submitted in wiki their Release Planning materials. That will give everyone to time to understand project scope and dependencies. | |
| Planning | M1 | Jan 18, 2018 | Planning process complete, all Project Deliverables are defined (including functional architecture, scope, dependencies,...) Integration Team has defined the vendor Equipments list and the End 2 End Release Test Cases are fully defined. The Document and Training teams have defined their plans. The packaging and installation strategy is defined. To pass the M1 milestones, all approved projects have to:
|
| Functionality freeze | M2 | Feb 12, 2018 | Functionality freeze, no new visible functionality is to be added to the current ONAP release. Each Project team has defined and documented their Functional Test Cases. The vendor equipments have been delivered. A stable document describing the API is documented and available in wiki. |
| API Freeze | M3 | March 8, 2018 | API/data model freeze. Mark the end of API and Data Model change. API and Data Model are now Frozen. Any changes to the API must be brought to the knowledge of the TSC for review and approval. 50% of Functional Test Case are automated. |
| Code Freeze | M4 | March 29, 2018 | Code Freeze. Mark the end of the Features coding. Jira issues are either fixed in the current release or assigned to next release. 100% of Functional Test Case are automated. End 2 End Release Test Cases are implemented (Integration Team). |
| Integration | RC0 | Avril 19, 2018 | Release Candidate 0 RCs are to ensure proper alignment and execution on End 2 End Release Test Cases and End 2 End functional Test Cases. Project Team focused its effort on:
|
| RC1 | May 3, 2018 | Release Candidate 1 | |
| RC2 |
May 31, 2018 | Release Candidate 2 TSC decision to postpone RC2 review by 2 weeks (Topic 3, section am) | |
| Sign-Off | Release Delivery |
June 7, 2018 | Beijing Release Sign-Off TSC decision to postpone RC2 review by 2 weeks (Topic 3, section am) |
Amsterdam Release
Amsterdam Release Planning
Link to ONAP Amsterdam Release planning (PDF).
Amsterdam Release Calendar
| Review | Milestone | Date | Events |
|---|---|---|---|
| Kick-Off (Open Intent To Participate) | M0 | May 4, 2017 | Planning process opens for all projects to submit their intent. |
| Project Submitted | May 15, 2017 | All projects candidate for the first ONAP Release have to:
| |
| Project Approved | June 1, 2017 | The TSC has a goal to review and provide its disposition on all submitted projects proposal. | |
| Planning | M1 | June 29, 2017 | Planning process complete, all Project Deliverables are defined (including functional architecture, scope, dependencies,...) Integration Team has defined the vendor Equipments list and the End 2 End Release Test Cases are fully defined. The Document and Training teams have defined their plans. The packaging and installation strategy is defined. To pass the M1 milestones, all approved projects have to:
|
| Functionality freeze | M2 | August 03, 2017 | Functionality freeze, no new visible functionality is to be added to the current ONAP release. Each Project team has defined and documented their Functional Test Cases. The vendor equipments have been delivered. A stable document describing the API is documented and available in wiki. |
| API Freeze | M3 | August 24, 2017 | API/data model freeze. Mark the end of API and Data Model change. API and Data Model are now Frozen. Any changes to the API must be brought to the knowledge of the TSC for review and approval. 50% of Functional Test Case are automated. |
| Code Freeze | M4 | Sept 28, 2017 | Code Freeze. Mark the end of the Features coding. Jira issues are either fixed in the current release or assigned to next release. 100% of Functional Test Case are automated. End 2 End Release Test Cases are implemented (Integration Team). |
| Integration | RC0 | Oct 12, 2017 | Release Candidate 0 RCs are to ensure proper alignment and execution on End 2 End Release Test Cases and End 2 End functional Test Cases. Project Team focused its effort on:
|
| RC1 | Oct 26, 2017 | Release Candidate 1 | |
| RC2 | Nov 9, 2017 | Release Candidate 2 | |
| Sign-Off | Release Delivery | Nov 16, 2017 | Amsterdam Release Sign-Off |
Amsterdam Release Dependencies
API Dependencies
The source of information to generate this information are the data point gathered into the project Release Planning template.
The graph below represents API dependencies for M1 Release Planning projects.
More info on how to generate the graph are available.
Casablanca Release Dependencies
Kubernetes Deployment Dependencies
The following are directly from the init containers in all the charts from the 20181208 baseline - raw data that needs to be put into a 2 dimensional graph
Note: these dependencies are at the lowest deployment level and represent a partial view of the REST/API dependency tree - they do not reflect any compile time or runtime/injection code dependencies (pom.xml)
Use fo any containers stuck at the 0/1 Init:0/1 stage - these are likely waiting on dependent containers
check the --container-name kv pair in StatefulSet/Deployment.yaml:spec:intiContainers:args
or the corresponding defined chart/container names in values.yaml:config:
106 sets in 87 files
overall order
aaf<-aai
aaf<-oof
music<-oof
dmaap<-aai
dmaap<-pomba
dmaap<-sdnc
consul<-sdnc
sdc<-sdnc
consul<-dcaegen2
msb<-dcaegen2
aaf
aaf-cm
aaf-locate
aaf-fs
aaf-locate
aaf-gui
aaf-cm
aaf-hello
aaf-locate
aaf-locate
aaf-service
aaf-oauth
aaf-locate
aaf-service
aaf-cs
aaf-sms
aaf-sms-quorumclient (via job)
aaf-sms-vault
aaf-sms-vault-backend
aai
aai
aai-resources
aai-traversal
aai-graphadmin
aai-champ
aai-cassandra
aai-graphadmin
aai-cassandra
aai-resources
aai-cassandra
aai-sparky-be
aai-elasticsearch
aai-search-data
aai
aai-spike
message-router-kafka
aai-traversal
aai
aai-cassandra
aaf-locate (conditional)
appc
appc
mariadb-galera
appc-ansible-server
appc
clamp
clamp
mariadb
clamp-dash-kibana
clamp-dash-es
clamp-dash-logstash
clamp-dash-es
common
controller-blueprints
mariadb-galera
mongo
*-nfs-provisioner
mysql
*-nfs-provisioner
dgbuilder
network-name-gen
mariadb-galera
dcaegen2
dcae-bootstrap
dcae-cloudify-manager
consul-server
msb-discovery
kube2msb
dep-health-init
hbase
dmaap
dmaap-bus-controller
postgres
dmaap-dr-node
dmaap-dr-prov
dmaap-dr-prov
mariadb
message-router
kafka
zookeeper
message-router-kafka
zookeeper
log
log-kibana
log-elasticsearch
log-logstash
log-elasticsearch
msb
kube2msb
msb-discovery
msb-discovery
msb-consul
msb-eag
msb-discovery
msb-iag
msb-discovery
music
music-cassandra
music-tomcat
zookeeper
oof
oof-has-api
oof-has-controller
aaf-service
oof-has-controller
music-tomcat
aaf-sms
oof-has-data
music-tomcat
oof-has-reservation
music-tomcat
oof-has-service
music-tomcat
policy
policy
mariadb
brmsgw
pap
drools
mariadb
nexus
pdb
pap
pomba
pomba-contextaggregator
message-router
pomba-kibana
pomba-elasticsearch
pomba-data-router
pomba-search-data
pomba-search-data
pomba-elasticsearch
portal
portal-widget
portal-db
portal-sdk
portal-db
sdc
sdc-dcae-be
common.name
sdc-be
sdc-dcae-dt
sdc-dcae-be
sdc-dcae-fe
sdc-dcae-be
sdc-dcae-tosca-lab
sdc-dcae-be
sdc-fe
sdc-kb
sdc-wfd-fe
sdc-wfd-be
sdnc
sdnc
mysql
sdnc-ansible-server
sdnc
dmaap-listener
mysql
sdnc
message-router
sdnc-portal
mysql / sdnc-db
sdnc
sdnc-prom
sdnc
consul
ueb-listener
mysql
sdnc
sdc-be
message-router
so
so
mariadb
so-bpmn-infra
mariadb
so-catalog-db-adapter
mariadb
so-openstack-adapter
mariadb
so-request-db-adapter
mariadb
so-sdc-adapter
mariadb
so-sdc-controller
mariadb
so-vfc-adapter
mariadb
vfc
vfc-catalog
vfc-db
vfc-ems-driver
mariadb // commented
vfc-generic-vnfm-driver
mariadb // commented
vfc-hauwei-vnfm-driver
mariadb // commented
vfc-juju-vnfm-driver
mariadb // commented
vfc-multivim-proxy
mariadb // commented
vfc-nokia-vnfm-driver
mariadb // commented
vfc-nokia-v2vnfm-driver
mariadb // commented
vfc-nslcm
vfc-db
vfc-vnfmgr
vfc-db
vfc-resmgr
mariadb // commented
vfc-workflow
mariadb // commented
vfc-workflow-engine
mariadb // commented
vfc-vnflcm
vfc-db
vfc-vnfres
vfc-db
vfc-zte-sdnc-driver
mariadb // commented
vfc-zte-vnfm-driver
mariadb // commented
vid
vid
mariadb-galera
vnfsdk
postgres
ONAP Release Lifecycle
- Release Lifecycle. It provides a description of each of the above milestones and the activities to be implemented.
10 Comments
Michael O'Brien
Gildas, Nice diagram. I added an editable lucidchart diagram under your dependencies diagram (it looks like a jenkins generated artifact). As I am getting 1.1 up and running into AA&I issues - ran into a deployment dependency between aai:model-loader-service and sdc:sdc-fe. Don't know if your diagram includes all of deployment|compile|rest|jdbc dependencies.
/michael
Pamela Dragosh
Gildas, Policy has a dependency on SO for their API for vLB Use Case. Also, Holmes does not call any Policy API's. Only CLAMP/DCAE call the Policy API's for R1.
Gildas Lanilis
Pam,
Regarding the dependency between Policy and SO, would you mind updating the Incoming API section of the policy release planning? That will help to ensure consistency. Currently, SO is not listed as a dependency.
Pamela Dragosh
Done. Thanks for pointing this out!
Ryan Hallahan
For the Casablanca Release Plan, it is hard to tell what date is being proposed for "E2E Release Use Case Approved".
However, it looks like it's around the beginning of May, which is well before the M0 milestone. I believe this is too early. Instead, I propose we have the E2E Use Case approval coincide with M0. Project teams then have over a month between M0 and M1 to do their project planning.
Gildas Lanilis
Ryan Hallahan Thanks for your inputs. That is correct, as there is a new "end-user-advisory-group" coming into the picture, the date was not engraved in the calendar. We need to understand how this group is going interact with use-case sub-committee. As we discussed at TSC meeting on April 12, we have now set the "E2E Release Use Case Approved" milestone as no later than May 10". I will update the timeline once I got all feedback.
Helen Chen
Three suggestions:
2. We need to make sure all "existing" health check and automated use cases won't break for each milestone.
3. For "new" projects in that release, OOM deployment and health check need to be done before M4.
Gildas Lanilis
Helen Chen Thanks for your suggestions. I tend to think this suggestion should not alter the proposed timeline. It will help the discussion if you could highlight which projects should come on first offset.
I think it would also help if we could could define "HealthCheck". May be something like: "Healthcheck test is intended to provide an API that would perform functional testing of an application in its environment such as database, http server, .... Healthcheck is not intended to perform integration testing with other ONAP componants." These are just my thoughts. I am sure Brian Freeman have some suggestions.
Tina Tsou
Is M1 and M0 opposite here for Casablanca Release?
Rebecca Lantz
Any idea when we may see a first draft for a Dublin release calendar?