Table of Contents outline true absoluteUrl true
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 Jan 17(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 | M2 |
Feb 28 Feb 14, 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 0714, 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 March 28, 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 0216th, 2019 | Release Candidate 1 | |||
Marketing: Outline for written content agreed with LF marketing | May 0916, 2019 | ||||
Marketing: Near-final draft for written content | May 1623, 2019 | ||||
RC2 |
May 1630th, 2019 | Release Candidate 2 | |||
Marketing: Content freeze | May 2330, 2019 | ||||
Marketing: New video content | May 2330, 2019 | ||||
Sign-Off | Release Delivery |
June 6th, 2019 | Dublin Release Sign-Off | ||
Marketing: Public announcement | May 30June 13th, 2019 TBD |
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
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 consul<-sdnc consul<-dcaegen2 msb<-dcaegen2 aaf aaf-cm 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-locatecs aaf-fssms aaf-locate -sms-quorumclient (via job) aaf-sms-guivault aaf-cm aaf-hello-sms-vault-backend aai aai aai-resources aai-traversal aafaai-locategraphadmin aafaai-locatechamp aafaai-servicecassandra aafaai-oauthgraphadmin aafaai-locatecassandra aafaai-serviceresources aafaai-cscassandra aafaai-sparky-smsbe aaf-sms-quorumclient (via job)aai-elasticsearch aafaai-smssearch-vaultdata aaf-sms-vault-backend aai aai-spike aaimessage-router-resourceskafka aai-traversal aai-graphadmin aai-champcassandra aai-cassandra aaf-locate (conditional) appc aai-graphadminappc aaimariadb-cassandragalera aaiappc-ansible-resourcesserver aai-cassandraappc clamp aai-sparky-beclamp aai-elasticsearchmariadb aaiclamp-searchdash-datakibana aaiclamp-dash-es aaiclamp-dash-spikelogstash messageclamp-router-kafkadash-es common aaicontroller-traversalblueprints aaimariadb-galera aai-cassandramongo aaf-locate (conditional) appc appc*-nfs-provisioner mysql mariadb-galera*-nfs-provisioner dgbuilder appcnetwork-ansiblename-servergen appcmariadb-galera clampdcaegen2 clampdcae-bootstrap mariadbdcae-cloudify-manager clamp-dash-kibana consul-server clampmsb-dash-esdiscovery clamp-dash-logstashkube2msb dep-health-init clamp-dash-eshbase commondmaap dmaap-bus-controller-blueprints mariadb-galera mongopostgres *dmaap-nfsdr-provisionernode mysql *dmaap-nfsdr-provisionerprov dgbuilder networkdmaap-namedr-genprov mariadb message-galera dcaegen2 dcae-bootstraprouter kafka zookeeper dcaemessage-cloudifyrouter-managerkafka consul-serverzookeeper log log-kibana msblog-discoveryelasticsearch kube2msb dep-health-init log-logstash hbaselog-elasticsearch dmaapmsb dmaap-bus-controllerkube2msb postgresmsb-discovery dmaap-dr-nodemsb-discovery dmaap-dr-provmsb-consul dmaap-dr-provmsb-eag mariadbmsb-discovery messagemsb-routeriag kafkamsb-discovery music zookeepermusic-cassandra message-router-kafka music-tomcat zookeeper logoof logoof-has-kibanaapi log-elasticsearch log-logstashoof-has-controller logaaf-elasticsearchservice msb kube2msboof-has-controller msb-discovery msbmusic-discoverytomcat msbaaf-consulsms msb-eag oof-has-data msbmusic-discoverytomcat msboof-has-iagreservation msbmusic-discoverytomcat music musicoof-has-cassandraservice music-tomcat policy policy zookeeper oof oof-has-apimariadb oof-has-controllerbrmsgw aaf-servicepap oof-has-controller drools music-tomcatmariadb aaf-smsnexus oof-has-datapdb music-tomcatpap pomba oofpomba-has-reservationcontextaggregator musicmessage-tomcatrouter oofpomba-has-servicekibana musicpomba-tomcatelasticsearch policy policypomba-data-router mariadbpomba-search-data brmsgwpomba-search-data pap droolspomba-elasticsearch portal mariadbportal-widget nexusportal-db pdbportal-sdk papportal-db pombasdc pomba-contextaggregatorsdc-dcae-be common.name messagesdc-routerbe pombasdc-dcae-kibanadt pombasdc-dcae-elasticsearchbe pombasdc-datadcae-routerfe pombasdc-searchdcae-databe pombasdc-dcae-searchtosca-datalab pomba-elasticsearch portalsdc-dcae-be portalsdc-widgetfe portalsdc-dbkb portalsdc-wfd-sdkfe portalsdc-wfd-dbbe sdcsdnc sdc-dcae-besdnc common.namemysql sdnc-ansible-server sdc-besdnc sdcdmaap-dcae-dtlistener sdc-dcae-bemysql sdc-dcae-fe sdnc sdcmessage-dcae-berouter sdc-dcae-tosca-labsdnc-portal sdc-dcae-be sdc-femysql / sdnc-db sdc-kbsdnc sdcsdnc-wfd-feprom sdc-wfd-be sdnc sdnc mysqlconsul sdncueb-ansible-serverlistener sdncmysql sdnc-prom sdncsdc-be consulmessage-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.