Table of Contents outline true absoluteUrl true
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
...
Opening of Release Planning
- For existing Projects:
- Every existing Beijing projects that plan to be part of Casablanca Release must email TSC to notify their intention through the ONAP TSC mailing list
- For New Projects:
- New Candidate project must fill out “Project Proposal Template”
- Post the proposal in the wiki at Proposed Projects
- Inform ONAP TSC of their intention throught the ONAP TSC mailing list
...
Last Date to announce Intention to Participate
...
This is the last date for TSC to formally approved New Project Proposal
...
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 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:
- Fill out the Release Planning Template
- Fill out the Deliverables for Planning Milestone Checklist Template
- Post these 2 project deliverables in wiki.
...
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/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. 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).
...
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:
- supporting integration testing
- closing high priority defects
- supporting Documentation team
...
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
...
Opening of Release Planning
- For existing Projects:
- Every existing Amsterdam projects that plan to be part of Beijing Release must email TSC to notify their intention through the ONAP TSC mailing list
- For New Projects:
- New Candidate project must fill out “Project Proposal Template”
- Post the proposal in the wiki at Proposed Projects
- Inform ONAP TSC of their intention throught the ONAP TSC mailing list
...
Last Date to announce Intention to Participate
...
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 810, 20172019 | 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, 201824, 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 814, 20182019 | 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
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 | Avril 19, 2018
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 1RC2 | ||
| Marketing: Outline for written content agreed with LF marketing | May 17, 201816, 2019 | |||
| Marketing: Near-final draft for written content | May 3123, 20182019 | 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
| 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 425, 20172018 | Planning process opens for all projects to submit their intent. | Project Submitted | May 15, 2017 | Opening of Release Planning
| Proposed Projects
| .|
| Project ApprovedJune 1, 2017Submission 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. | Planning | M1 | June 29, 2017 | Planning process complete, all Project Deliverables are defined (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 | August 03July 26, 20172018 | 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 2423, 20172018 | 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 2820, 20172018 | 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 1211, 20172018 | 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 2625, 20172018 | Release Candidate 1RC2 | ||||||
| Marketing: Outline for written content agreed with LF marketing | Nov 9, 2017 | Release Candidate 2 | Sign-Off | Release Delivery | Nov 16, 2017 | Amsterdam Release1, 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 |
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.
| 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
| Code Block | ||
|---|---|---|
| ||
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.