How do the Deliverables from Projects and their features get mapped(marked 'released') into a planned/supported and tested release deliverable in a given release?

asked 2015-09-01 09:45:24 -0800

lmcdasm gravatar image

updated 2015-09-01 10:07:58 -0800

If we examine that each of the project is responsible for what they "intend" to release.

and we keep in mind that OPNFV goal within each release is to provide a broad spectrum of installation and deployment options (i.e many installers).

There needs to be an understanding of how the features releases in the projects are mapped into a " OPNFV release".

Being specific in the final cases as what maps to what is important, since we need to avoid the following scenario:

  • ARNO comes out. . and projects start to develop on arno (master genesis branch).
  • Plans for B-Release come out, and all projects (installers and feature/delivery/code projects) start to build. - So - Projects use ARNO as baseline. - Installers use ARNO and start to go forwards. We have a problem here, since the installers will move the code ahead and the projects wont have been building on the same baseline..

So we have a stream issue in terms of our approach to deliver and it would be great to understand how we want to define what the final look, feature and tests end to end from a OPNFV artifact standpoint - think Installation instrutions, DOcumentation on what this "release allows a user to do and how they do it" from the features that the projects are going to release.

For example, project A says they are going to release deliverable:

  • project A indicates they will test on FUEL only
  • project A contacts FUEL installer group and requests testing for their feature
  • FUEL and project A do integration - and setup CI pipeline
    • however Project A was using ARNO (not latest code)
    • so uplift / refactor is required - BLOCKING PROCESS POINT

Other side cases to consider: - project A wants to have feature released on all installers - same issue as well as resources. - project A and project B drop feature set on installer that causes conflict (probably a bit early for this one yet)

Some discussion on how baseline, stream and tick-tock (between installer/OStack layer vs. feature ) is going to work would be a good idea, otherwise we dont have consistency in our releases each go around.

It would be really great to understand our definition of "released feature", "Lab ready", "tested" and how the CI pipeline is supposed to work in conjunction with projects. Should each project be required to provide configuration spec (based on template) to CI group - how does this work?

Could we have a process page that shows how the relation from project deliverables is transformed into a testable and delivery "RELEAESE" Object? (something that will be on the ISO, documented, tested and included into the CI Pipeline?).

SUMMARY OF POINTS /QUESTIONS FROM CALL:

  • Requirements in/out of Projects and to/from Infrastructure/Platform groups (i.e Installers)

  • How do stated Project (non-Installer) deliverables get worked into the various Infra./Platform level releases

    • One installer, many installer, testing methodology

      • What do we mean by released from a project in the context of “released” on an ISO – how to handle ...
(more)
edit retag flag offensive close merge delete