Created by Chaker Al-Hakim December 10, 2019

Current ONAP Lifecycle Process

  • “The activities of the ONAP community are articulated around projects and releases. The scope of each project is aligned with the ONAP architecture and the scope of each release is defined with the objective to fulfill a particular use case(s).”

  • “A project is a long-term endeavor setup to deliver features across multiple releases, which have a shorter lifespan.”

  • The project and release lifecycle are simple and provide sufficient visibility to allow teams to coordinate with one another and flock naturally.”

  • “The key point of the project and release lifecycle process is to provide adequate visibility to all stakeholders, provide synchronization, and support to all contributors.”

Project Lifecycle States and Reviews

  • ONAP project lifecycle defines five states that each project goes through. The project lifecycle may extend across multiple releases.

  • The procedure of moving from one state to the next one is independent from the release and the pace depends on each individual project.

  • In order to effectively review project progress, four reviews are build-in within the project lifecycle


Project State

Description

Proposal

Project doesn’t really exist yet, may not have real resources, but is proposed and is expected to be created due to business needs.

Incubation

Project has resources but is recognized to be in the early stages of development. The outcome is a minimum viable product (MVP) that demonstrates the value of the project and is a useful vehicle for collecting feedback but is not expected to be used in production environments.

Mature

Project is fully functioning and stable, has achieved successful releases.

Core

Project provides value to and receives interest from a broad audience.

Archived

Project can reach Archived state for multiple reasons. Either project has successfully been completed and its artifacts provide business values, or project has been cancelled for unforeseen reasons (no value anymore, technical, etc.).

Project in any state can be Archived through a Termination Review.

To move from one state to the next state, the Project Team has to formulate a Kick-Off release review to the TSC, by specifying its goal to move up the Project Lifecycle ladder.


From

State

To

State

Review Description

Null

Proposal


Proposal

Incubation

Incubation review

Incubation

Mature

Maturity review

Mature

Core

Core review

Core

Archived(retirement)

Termination review

Termination Review – proposed additional steps

  1. Add a step in the project approval process that would clearly define how to retire the proposed project
  2. Cancel all technical meetings
  3. IT related items
  4. Open a JIRA ticket to track the project retirement
  5. Repository – make source control read-only, turn off automated builds
  6. Update Wiki
  7. Update Docs
  8. Assess dependencies from other components
  9. Close down all related mailing lists
  10. .... any additional steps


Proposed Next Steps

The table below should be used as a guiding checklist for developing a plan to retire any ONAP project/component


Step

Project Incubation Review

Artifacts

Project Retirement  Review

Artifacts

Comments

 for retirement

( added )

1

Name of the project is appropriate (no trademark issues etc.); Proposed repository name is all lower-case without any special characters

Same

2

Project contact name, company and email are defined and documented

Same

3

Description of the project goal and its purpose are defined

Same

4

Scope and project plan are well defined

Identify impacts  on other projects, components, work efforts, release timeline, etc


5

Resources committed and available

Identify and release all the resources


6

Contributors identified

Notify all the contributors

send email to tsc, discuss, ptl and to the project list (if it exists)

7

Initial list of committer identified (elected/proposed by initial contributors)



8

Meets ONAP TSC Policies

Perform:

  1. Security assessment
  2. Architecture Review
should be part of line #4

9

Proposal has been socialized with potentially interested or affected projects and/or parties

Required

wider ecosystem in the general release notes

(preceded by a release where it has been moved to unmaintained)

send an email to the lfn-euag, onap-users, and send a note to the general IM channel (currently Slack)

10

Cross Project Dependencies (XPDs). In the case where a project will require changes in other projects, those projects are listed in the proposal, and a sponsoring developer in the project has been identified

Required – undo all the changes to the impacted projects.  This can span multiple releases

concerns from SECCOM about this spanning multiple releases. N

11

Tools have been identified and discussed with relevant partners (Linux Foundation, IT). Once the project pass the review,:

  1. the tools chain must be  created within one week.
  2. Tools encompass Configuration Management, CI-CD,
  3. Code Review,
  4. Testing,
  5. Team Wiki,
  6. End Users documentation (not exhaustive)

 A plan is required to undo all these steps


12

N/A

Develop a test plan to certify the rest of the ONAP components without the deprecated component


13

N/A

Identify any previous release(s) that would need to be maintained that use(s) the retired component and provide ongoing support until an upgrade occurs. (things can get a little bit messy here – this requires further debate/discussion)


14

N/A

IT related items:

  1. Open a JIRA ticket to track the project retirement
  2. Repository – make source control read-only,
  3. turn off automated builds
  4. Update Wiki
  5. Update Docs
  6. Close down all related mailing lists
  7. ...etc

  • No labels

2 Comments

  1. Pamela Dragosh

    Chaker Al-Hakim  - can we point to what each state means? the links don't really point anywhere as to what mature vs core mean. I believe these states are defined in the charter?? There are certain conditions other than "successful releases", such as code coverage that have to be met as I recall.


    And for the reviews to be done by M1, what does that mean exactly? Schedule a review with architecture? What should be prepared by the PTL?

    1. Pamela Dragosh

      Actually never mind - I don't see those metrics anymore in the charter. Maybe it changed - or was on another wiki page that Gildas created long ago.


      Code Coverage and Static Code Analysis - sorry this page has some guidelines for project maturity. So wondering if this should be removed as they are not in the charter??