Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

David McBride created a set of milestones for the different projects.

It is obviously impossible to be generic due, RM asks "specific" project to review the milestones according to their scope

See Generic Milestones descriptions: Frankfurt Deliverables by Milestone

+ Focus on Frankfurt Milestone Status

M4

Here are the current requirements for M4 (generic):

  • New 3rd party dependencies, new FOSS (final confirmation)
  • License scan issues addressed
  • Address all security issues
  • All high/highest priority jira tickets addressed
  • Update Frankfurt Release Platform Maturity, CII badging update - update M4 Result
  • Test coverage goals complete
  • No Gerrit requests older than 36 hrs.
  • Integration weather board update
  • Update Frankfurt Risks

I would appreciate if each of you could do the following:

  • Identify which tasks from the list above make sense for your project.
  • Identify additional tasks that would make sense for your project.


M4 Integration criteria Proposal - note we should also review the previous milestones...

General

  • License scan (integration/*, testsuite/*, demo/*)  issues addressed
  • No Gerrit requests older than 1 week
  • Update Frankfurt Risks
  • All high/highest priority jira tickets addressed (blocking integration board ready)

Labs

  • Resources secured for release validation (if needed some resources may be pre-empted) - at least 2 labs available for testing

Use cases

  • Integration use case weather board update - use cases frozen (only status update allowed)
  • Documentation shall be initiated (at M2/M3)

CI/CD

  • Daily Master => Daily candidate (here Daily Frankfurt) running on at least 2 labs
  • Stability test ready for Daily Frankfurt?
  • Testing dockers and testing declared in the DB frozen

Tests

  • New tests done on Master only (no backport to Frankfurt)
  • Ideally the code of the test should also respect some code coverage/quality criteria (not the case today)
  • Documentation shall be initiated (M2/M3)

Tooling (the code we develop to test and integrate ONAP)

  • should not be very different than the other code even if it is not as critical as not part of the release
  • oparent docker ready (M2/M3)
  • java11 docker ready for consumption (M2/M3)


RC

we have a timing issue assuming that code was frozen in M4 but dockers are not available at M4. It means that integration env can be built only at RC so it is not possible to complete the test plan before we build the test env..

M4/RC and docker availabilty


Default

  • All high/highest priority jira tickets addressed
  • Remaining License scan, security critical issues addressed
  • Update Release note and documentation
  • Docker images “Release” dues
  • Project specific test plan for El Alto completed
  • Update Frankfurt Risks
  • Integration Weather Board complete
  • Versioning at the project level
  • Check the certification expiry of your application. It should be valid for the next 9 months after RC0.


Proposal


General

  • All high/highest priority jira tickets addressed
  • Update Release note and documentation
  • Update Frankfurt Risks
  • Versioning at the project level

Use cases

  • Project specific test plan for Frankfurt initiated (due docker needed to build the target env)
  • Documentation completed
  • Integration Weather Board complete

CI/CD

  • Daily Frankfurt created and running on 2 labs
  • Frankfurt CI/CD chain successfull (all tests OK)

Tests

  • Preparation of Robot and testsuite dockers (but due dockers needed as prerequisite + time to complete integration)
  • No labels