Skip to content

OSPRH-38067: Record platform-state after RHOSO in monolithic jobs - #48

Open
tusharjadhav3302 wants to merge 1 commit into
mainfrom
feat/monolithic-record-platform-state
Open

OSPRH-38067: Record platform-state after RHOSO in monolithic jobs#48
tusharjadhav3302 wants to merge 1 commit into
mainfrom
feat/monolithic-record-platform-state

Conversation

@tusharjadhav3302

@tusharjadhav3302 tusharjadhav3302 commented Oct 11, 2026

Copy link
Copy Markdown
Contributor

Summary

Monolithic osp_verification* jobs now write the phased platform-state.yaml contract on the hypervisor after RHOSO is already deployed, so warm Pipeline B can reuse Saturday platforms.

  • New record_platform_state stage/role probes live RHOSO via rhoso_kubeconfig (OpenStackVersion.deployedVersion, OCP /readyz, OpenStackControlPlane Ready) and writes /home/zuul/ci-framework-data/platform-state.yaml on the hypervisor (same schema as ci-framework-jobs phased recorder).
  • Wired in playbooks/ocp_testing.yaml when the stage is listed.
  • Enabled only on monolithic osp_verification.yaml and osp_verification_*_nightly.yaml job definitions.
  • Not for phased setup: Pipeline A already records via ci-framework-jobs; Pipeline B overrides stages without this stage (would be redundant).

Related

Test plan

  • Dry-run / review: stage appears first in monolithic nightlies only; absent from phased cifmw_shiftstack_stages_override.
  • On next monolithic osp_verification run, confirm /home/zuul/ci-framework-data/platform-state.yaml exists on the hypervisor with platform_status: ready and live rhoso_version_full.
  • Confirm phased Pipeline B still skips this stage via override and continues to use Pipeline A recorded state.

Made with Cursor

@tusharjadhav3302 @cursoragent
OSPRH-38067: Record platform-state after RHOSO in monolithic jobs
7bf008e 
Add a record_platform_state stage that probes live RHOSO
(OpenStackVersion.deployedVersion, OCP API, OpenStackControlPlane Ready)
from the shiftstackclient pod and writes platform-state.yaml on the
hypervisor in the same schema as the phased recorder.

Enable the stage only on monolithic osp_verification* nightlies so warm
Pipeline B can reuse Saturday platforms. Phased Pipeline A already
records via ci-framework-jobs; Pipeline B stage overrides must not list
this stage (redundant).

Co-authored-by: Cursor <cursoragent@cursor.com>
@openshift-ci-robot

openshift-ci-robot commented Oct 11, 2026 •
edited by openshift-ci Bot
Loading

Copy link
Copy Markdown

@tusharjadhav3302: This pull request references OSPRH-38067 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "5.1.0" version, but no target version was set.

Details

In response to this:

Summary

Monolithic osp_verification* jobs now write the phased platform-state.yaml contract on the hypervisor after RHOSO is already deployed, so warm Pipeline B can reuse Saturday platforms.

  • New record_platform_state stage/role probes live RHOSO via rhoso_kubeconfig (OpenStackVersion.deployedVersion, OCP /readyz, OpenStackControlPlane Ready) and writes /home/zuul/ci-framework-data/platform-state.yaml on the hypervisor (same schema as ci-framework-jobs phased recorder).
  • Wired in playbooks/ocp_testing.yaml when the stage is listed.
  • Enabled only on monolithic osp_verification.yaml and osp_verification_*_nightly.yaml job definitions.
  • Not for phased setup: Pipeline A already records via ci-framework-jobs; Pipeline B overrides stages without this stage (would be redundant).

Related

Test plan

  • Dry-run / review: stage appears first in monolithic nightlies only; absent from phased cifmw_shiftstack_stages_override.
  • On next monolithic osp_verification run, confirm /home/zuul/ci-framework-data/platform-state.yaml exists on the hypervisor with platform_status: ready and live rhoso_version_full.
  • Confirm phased Pipeline B still skips this stage via override and continues to use Pipeline A recorded state.

Made with Cursor

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci

openshift-ci Bot commented Oct 11, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign imatza-rh for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@chenwng chenwng Awaiting requested review from chenwng chenwng is a code owner
@dlaw4608 dlaw4608 Awaiting requested review from dlaw4608 dlaw4608 is a code owner
@ekuris-redhat ekuris-redhat Awaiting requested review from ekuris-redhat ekuris-redhat is a code owner
@eshulman2 eshulman2 Awaiting requested review from eshulman2 eshulman2 is a code owner
@gryf gryf Awaiting requested review from gryf gryf is a code owner
@imatza-rh imatza-rh Awaiting requested review from imatza-rh imatza-rh is a code owner
@mandre mandre Awaiting requested review from mandre mandre is a code owner
@stephenfin stephenfin Awaiting requested review from stephenfin stephenfin is a code owner
@winiciusallan winiciusallan Awaiting requested review from winiciusallan winiciusallan is a code owner

Assignees

No one assigned

Labels

jira/valid-reference

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@tusharjadhav3302 @openshift-ci-robot