-
Story
-
Resolution: Unresolved
-
Critical
-
None
-
None
-
None
-
3
-
False
-
-
False
-
?
-
?
-
?
-
?
-
-
Following Implement basic ping test in the Adoption testing we now activate the job in the CI.
The choosen job for the first iteration of activation is periodic-internal-adoption-multinode-to-crc-no-ceph whose code can be found there.
This task will be completed when:
- we have a testproject with no or merged dependency that run the job successfully
- job have been run in CI automatically at least once.
Note that the testproject should also include periodic-internal-adoption-multinode-to-crc-ceph as it shares the variables definition with the job we want include, meaning that we activate ping test in both jobs.
Furthermore periodic-internal-adoption-multinode-networker-to-crc is also impacted for the same reason. But here, we need to make sure that it doesn't start the ping test. It has its own ping test mechanism and we don't want to interfer. So the testproject should also run that job to ensure that the new ping test in not run there.
We also have periodic-internal-adoption-multinode-to-crc-no-ceph-rollback which is impacted as a child of the job we defined. So we need to make sure that it doesn't trigger the ping test.
Eventually, component-internal-adoption-multinode-to-crc-no-ceph is also impacted as a descendant of the the job we're modifying. It defined a set of vars, but ZUUL uses deep merge on `vars` for job (here). It's a abstract job without any concrete implementation as far as I could see.
- relates to
-
OSPRH-11302 Implement basic ping test in the Adoption testing
- Closed