...

• CSIT suites that test components from multiple project repositories at the same time 
  • such CSIT tests may have to be separated using additional simulators, or
  • project repository structures themselves may have to be reconsidered
  • In any case, the division between the images under test and images that are just necessary dependencies should be clearly made and documented
    • the images under test should be coming from the commit branch
    • in the case of necessary dependencies it must be decided whether they should be provided as simulators or real components
      • if provided as real components, they should be referred to with a fixed, unchanging version number and should be stable and mature enough to develop on
        • ONAP's (unintentional?) practice of allowing the same versioned image to be changed might prove problematic
    • project-specific simulators are trivial case from dependency handling point of view, but if common simulators are in use, dependency considerations for them are the same as with real components
• Jenkins templates may have to be redesigned to support unified approach for triggering review branch-specific docker build, CSIT execution and voting chain as part of review verification
  • What is the most elegant and effortless solution for ensuring that the docker images built from commit branch are taken in use in the CSIT (both in Jenkins and in local development environment)?
• CSITs would become blockers for merging code
  • local pre-commit verification should be supported better by common CSIT tools

  • are all projects and suites mature enough to deal with that?

• Docker image production practices will have to be unified (see Docker Image Build Guidelines)
  • To which extent are the current guidelines actually followed?
  • Are the guidelines good enough for CSIT development as they are now if they were followed?

Technical details to be decided

...