Skip to end of metadata
Go to start of metadata




Dublin Release

Dublin Release Planning

Dublin Release milestone (1-16-19: Updated to align to Release Calendar below)

Dublin Release Calendar

Review MilestoneDateEvents
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)M0Nov 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:

Release 4 (Dublin) Use Cases and functional requirements)

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.

PlanningM1

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:

  1. Fill out the Release Planning Template
  2. Fill out the Deliverables for Planning Milestone Checklist Template
  3. Post these 2 project deliverables in wiki.
Functionality freezeM2Feb 21, 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 FreezeM3March 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 FreezeM4April 4, 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.

IntegrationRC0April 25, 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:

  1. supporting integration testing (complete Health Check and Pair Wise Testing)
  2. closing high priority defects
  3. supporting Documentation team

RC1May 09, 2019Release Candidate 1
Marketing: Outline for written content agreed with LF marketing 
May 16, 2019
Marketing: Near-final draft for written content 
May 23, 2019

RC2May 23, 2019Release Candidate 2
Marketing: Content freeze 
May 30, 2019
Marketing: New video content
May 30, 2019
Sign-OffRelease DeliveryMay 30, 2019Dublin Release Sign-Off
Marketing: Public announcement 
June 6, 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 MilestoneDateEvents
Kick-Off (Open Intent To Participate)M0May 25, 2018

Opening of Release Planning

Project Submission Closure
June 07, 2018

Last Date to announce Intention to Participate

Project Proposal Approved
June 14, 2018The 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.

PlanningM1June 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:

  1. Fill out the Release Planning Template
  2. Fill out the Deliverables for Planning Milestone Checklist Template
  3. Post these 2 project deliverables in wiki.
Functionality freezeM2July 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 FreezeM3August 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 FreezeM4Sept 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).


IntegrationRC0Oct 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:

  1. supporting integration testing (complete Health Check and Pair Wise Testing)
  2. closing high priority defects
  3. supporting Documentation team

RC1Oct 25, 2018Release 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 08, 2018

Nov 27, 2018

Release Candidate 2

TSC decision on Nov 8 to postpone RC2 to Nov 27.

Marketing: Content freeze 
Nov 15, 2018
Marketing: New video content
Nov 15, 2018
Sign-OffRelease Delivery

Nov 15, 2018

Nov 30, 2018

Casablanca Release Sign-Off

TSC decision on Nov 8 to postpone Sign-Off to Nov 30.

Marketing: Public announcement 
Nov 29, 2018


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 MilestoneDateEvents
Kick-Off (Open Intent To Participate)M0November 16, 2017

Opening of Release Planning

Project Submission Closure
November 30, 2017

Last Date to announce Intention to Participate

Project Proposal Approved
December 13, 2017The 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.

PlanningM1Jan 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:

  1. Fill out the Release Planning Template
  2. Fill out the Deliverables for Planning Milestone Checklist Template
  3. Post these 2 project deliverables in wiki.
Functionality freezeM2Feb 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 FreezeM3March 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 FreezeM4March 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).

IntegrationRC0Avril 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:

  1. supporting integration testing
  2. closing high priority defects
  3. supporting Documentation team

RC1May 3, 2018Release Candidate 1

RC2

May 17, 2018

May 31, 2018

Release Candidate 2

TSC decision to postpone RC2 review by 2 weeks (Topic 3, section am)

Sign-OffRelease Delivery

May 24, 2018

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 

Amsterdam Release Calendar

Link to ONAP Amsterdam Release planning (PDF).

Amsterdam Release Calendar


Review MilestoneDateEvents
Kick-Off (Open Intent To Participate)M0May 4, 2017Planning process opens for all projects to submit their intent.
Project Submitted
May 15, 2017

All projects candidate for the first ONAP Release have to:

  1. use the Project Proposal Template
  2. post the proposal in the wiki at Proposed Projects
  3. inform ONAP TSC of their intention throught the ONAP TSC mailing list.
Project Approved
June 1, 2017The TSC has a goal to review and provide its disposition on all submitted projects proposal.
PlanningM1June 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:

  1. Fill out the Release Planning Template
  2. Fill out the Deliverables for Planning Milestone Checklist Template
  3. Post these 2 project deliverables in wiki.
Functionality freezeM2August 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 FreezeM3August 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 FreezeM4Sept 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).

IntegrationRC0Oct 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:

  1. supporting integration testing
  2. closing high priority defects
  3. supporting Documentation team

RC1Oct 26, 2017Release Candidate 1

RC2Nov 9, 2017Release Candidate 2
Sign-OffRelease DeliveryNov 16, 2017Amsterdam 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.

ONAP API Dependencies

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

  1. 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

  2. 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.

    1. 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.

      1. Done. Thanks for pointing this out!

  3. 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.

    1. 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.

  4. Three suggestions:

    1. Until we reached our continuous release for each project dream. I would suggest that it is time to group projects according to their dependency and have 1~2 weeks offset on milestone.

    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.


    1. 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.

  5. Is M1 and M0 opposite here for Casablanca Release?


  6. Any idea when we may see a first draft for a Dublin release calendar?