gantt
    title Validation Framework Roadmap WIP WIP

    section VF Independent
    Releasing & Branching Model           :a1, 2021-10-18, 21d
    Tripleo CLI deprecation     :after a1  , 20d
    Another task     :after a1  , 20d
    section ROI
    Validation Legacy Catalog      :2021-09-27  , 42d
    anther task      : 24d

Release Model
(VF as an independent tool)

Legacy Catalog
(Fix, deprecate)

Simplification
(Remove TripleO CLI, Merge validation-common)

Project extension
(Insights and other consumer/partner)

Roadmap and priority for the Validation Framework:

1/ First of all, we need to get a state of what is currently broken or not in the current Validation Catalogue.
The 1st sprint goal should draw a state of the Art of it and start to fix and deprecates Validations.

2/ The 2nd major goal is, in order to get easy quick win, to work on the component CI side.
The VF can benefit a lot in that regard:
* first because the daily execution of the Validations against all the component will make sure that every Validations is not broken and still running properly.
* second because the Validations start to be a gate in the process of landing code for each OSP components. The Validations will begin to be analysed and even, can be a potential + for the DFGs to catch issues before landing downstream.

It makes a lot of visibility for the VF and growth the importance of the usage.

Tasks:
* Move from standalone job to multinode for the Component pipeline
* Re-enable the run of the Validations in the Component pipeline
* (and how to make sure VF is still running there)
* Increase the number of Components and Validations per Components.
* Make sure the Validation jobs are criteria for the Components.
* Use Multinode jobs for tripleo-validations CI jobs: *keep the standalone one* and see how to gate a specific Validations on it:
* ie: if Xyz validation has been touch by a patch, then trigger the Validation role with this specific Validation.
* few questions: how to make sure the Validation is executed against the correct setting, job topology

3/ Simplification:

The simplification is an important gap to pass for the team. It will decrease the scope of the VF and the potential issues.
For instance, the TripleO CLI implementation is simply a caller to the current VF CLI *but* with a different entry point (tripleo). It can cause some issues and different behavior when the team lands bug fixes and features.
The team has to test twice for a some code path.

On an other side, the validation-common repository should be merged in validations-libs and tripleo-validations. This repository doesn't really offer real gain for the project and has a big cost for the team. (CIX and management)

Tasks:
* deprecate Tripleo CLI
* Merged validations-common

4/ Usuability:

Community Validation and Validation creation automation.

5/ Release Model and VF as an independent tool

6/ External consumer inside REDHAT.

* Sprints 3 weeks
* Milestone 3 sprints
* Long term vision:
* +1 year 2 years

Long vision & Goals:
Framework as an autonomous tool:

* Installed and used with less dependencies
* OS agnostic
* CLI / UI for Users
* Able to connect complex logging system
* Help users to handle easily new Validations
* Able to run different type of Validations (like Python Insights rules)
* Able to consume Validation from outside of TripleO world

Validations:

* A strong collection of Validations for TripleO
* Used as a strong verification prior to Upgrade & Update for TripleO but also RHEL (Leap)
* Also for Deployment and Post deployment for TripleO/OSP
* A set of Validation collections for Openstack
* General Upstream set of checks for Openstack
* Consumable by other callers

Sprint [1..3] should be focus on ROI:

Main prios
* Legacy Validations
* Component CI
Parallele work:
* Usuability:
Community Validation
Validation creation automation

MileStone #1:
* Get a fully working set of Validations
* Those Validations is run against all OSP Components
* Validations are gates for promoted Components
* Users can easily create the skeleton of a Validation and start to contribute.
* Users can use the framework to consumer their specific sets of Validations

Sprint [4..6]
* Deprecate TripleO CLI
* Drop v-common
* We release on each sprint (or milestone) 1 tag with his branch.
* tripleo-validation can be consume via Ansible Collection

MileStone #2
* Team no longer manage a duplicate CLI in Tripleo
* The Validations are all in a same place
* Callbacks are in the framework.
* The validations can be consume via ansible-galaxy
* The Framework can consume Collection for Validations

Sprint [7..9]

MileStone #3

Personnal notes:
* See how tempest is operating for:
* discovering Openstack
* Inventory
* Tempest plugin