Versions Compared

Old Version 68

changes.mady.by.user Alla.Goldner

Saved on

compared with

New Version Current

changes.mady.by.user cl664y@att.com

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
outlinetrue
absoluteUrltrue

...


El-Alto Release

Dublin Release Planning

Draft Dublin Release milestone

Image Removed

Dublin Release Calendar

...

Opening of Release Planning

...

By this date, all use cases/functional requirements need to be discussed with a different projects, and demanded scope of development should be clear to the projects:

For use cases/functional requirements:

(link to current use cases/functional requirements proposals description:

Release 4 (Dublin) Use Cases and functional requirements)

...

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:

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

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

...

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

Image Removed

Casablanca Release Calendar

...

Opening of Release Planning

...

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:

  1. Security
  2. Documentation
  3. Don't break the build

El-Alto Release Calendar



Image Added


El-Alto Release Calendar (tabular)


MilestoneDate 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 releasedComplete 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

Image Added

Dublin Release Calendar

July 26, 2018August 23, 2018Sept 20, 2018Oct 11, 2018Casablanca
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
June 14Dec 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
June 21Jan 10, 20182019

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

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 freezeM2

Feb 21, 2019

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.

API FreezeM3

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 FreezeM4

April 4, 2019

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.

IntegrationRC0

April 25, 2019

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:

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

RC1Oct 25

May 09,

2018

2019

May 16th, 2019

Release Candidate 1
Marketing: Outline for written content agreed with LF marketing 
Nov 1May 16, 20182019
Marketing: Near-final draft for written content 
Nov 8May 23, 20182019

RC2

Nov 08May 23, 20182019Nov 27

May 30th, 20182019

Release Candidate 2

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

Marketing: Content freeze 
Nov 15May 30, 20182019
Marketing: New video content
Nov 15May 30, 20182019
Sign-OffRelease Delivery

Nov 15, 2018

Nov May 30, 2018

2019

June 6th, 2019

Dublin Release Sign-Off

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

Marketing: Public announcement 
Nov 29June 13th, 20182019

...


Casablanca Maintenance Release

This release calendar below has been approved by TSC at Santa Clara Developers F2F  on Dec 13, 2017.

Beijing Release Planning

Image Removed

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

...

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.

Image Added

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

Image Added

Casablanca Release Calendar

...

Review MilestoneDateEvents
Kick-Off (Open Intent To Participate)M0November 16May 25, 20172018

Opening of Release Planning

Project Submission Closure
November 30June 07, 20172018

Last Date to announce Intention to Participate

Project Proposal Approved
December 13June 14, 20172018The 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 8June 21, 20172018

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 18June 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 freezeM2Feb 12July 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 FreezeM3March 8August 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 FreezeM4March 29Sept 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).


IntegrationRC0Avril 19Oct 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

RC1May 3Oct 25, 2018Release Candidate 1RC2

May 17, 2018

May 31Marketing: 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 review by 2 weeks (Topic 3, section am)to Nov 27.

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

May 24Nov 15, 2018

June 7Nov 30, 2018

Beijing Casablanca Release Sign-Off

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

Amsterdam Release

Amsterdam Release Planning 

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

Image Added

...

Link to ONAP Amsterdam Beijing Release planning Planning (PDF) .

Amsterdam Release Calendar

as presented at Paris F2F, Sept 2017

Update ONAP Beijing Release Planning (PDF) as presented at Santa Clara F2F, Dec 2017

Beijng Release Calendar

...

All projects candidate for the first ONAP Release have to:

  • use the Project Proposal Template
    • post the inform Proposed Projects.Nov 9, 2017
    Review MilestoneDateEvents
    Kick-Off (Open Intent To Participate)M0May 4November 16, 2017Planning process opens for all projects to submit their intent.Project SubmittedMay 15, 2017

    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:
    Project Submission Closure
    		November 30, 2017

    Last Date to announce Intention to Participate

    Project Proposal Approved
    		June 1December 13, 2017The TSC has a goal to review and provide its disposition on all submitted projects proposal.

    		PlanningM1June 29

    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 freezeM2August 03Feb 12, 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 FreezeM3August 24March 8, 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 FreezeM4Sept 28March 29, 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).

    IntegrationRC0Oct 12Avril 19, 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:

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

    		RC1Oct 26May 3, 20172018Release 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 DeliveryNov 16, 2017Amsterdam

    May 24, 2018

    June 7, 2018

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

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

    Amsterdam Release

    Amsterdam Release Planning 

    Amsterdam Release CalendarImage Added

    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 New Project Proposals
    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 DependenciesImage Added

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