Run oadp-operator e2e against kdm-controller/kdm-plugin PRs (oadp-dev, oadp-1.6) - #83049
Run oadp-operator e2e against kdm-controller/kdm-plugin PRs (oadp-dev, oadp-1.6)#83049kaovilai wants to merge 17 commits into
Conversation
openshift-ci
Bot
added
the
approved
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThe CI configurations build and promote OADP images. The datamover controller and plugin configurations add optional AWS virtualized E2E workflows with OADP installation, image injection, rollout checks, credentials, and resource requests. ChangesOADP development CI and E2E integration
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant CI
participant OADPOperator
participant OLMSubscription
participant DatamoverComponent
participant AWSE2ETests
CI->>OADPOperator: Install the dev-channel OADP operator
CI->>OLMSubscription: Set the datamover related image
OLMSubscription->>DatamoverComponent: Apply the controller or plugin image
DatamoverComponent-->>CI: Report deployment rollout completion
CI->>AWSE2ETests: Mount credentials and run TEST_VIRT=true test-e2e
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@ci-operator/config/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev.yaml`:
- Around line 30-31: Replace the `commands: make test` entry in the `oadp-dev`
test configuration with a direct `go test ./kubevirt-datamover-plugin/...`
invocation, preserving `from: src` and avoiding the Makefile’s container-runtime
prerequisite.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 1448f45b-6cd1-41b8-88b9-4341aa39dd33
⛔ Files ignored due to path filters (4)
ci-operator/jobs/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev-postsubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev-presubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev-postsubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev-presubmits.yamlis excluded by!ci-operator/jobs/**
📒 Files selected for processing (2)
ci-operator/config/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev.yamlci-operator/config/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev.yaml
| commands: make test | ||
| from: src |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
# First, check if the file exists and read its current content
cat -n ci-operator/config/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev.yaml | head -50Repository: openshift/release
Length of output: 1115
🏁 Script executed:
# Also search for any related files in the ci-operator config
find ci-operator/config -name "*kubevirt-datamover*" -type fRepository: openshift/release
Length of output: 1131
🌐 Web query:
kubevirt-datamover-plugin Makefile oadp-dev docker podman check
💡 Result:
The kubevirt-datamover-plugin and its associated kubevirt-datamover-controller are components within the OpenShift API for Data Protection (OADP) ecosystem, primarily developed under the migtools organization with development branches typically tracked under oadp-dev [1][2][3]. Development workflows for these components involve standard Makefile-driven processes that support both Docker and Podman as container runtimes for building and pushing images [4]. Key points regarding the development workflow include: 1. Build and Deployment: The repositories (e.g., kubevirt-datamover-controller) utilize Makefile targets such as make docker-build and make docker-push [4]. These commands facilitate the creation and distribution of container images, often using environment variables like IMG to specify the target registry [4]. 2. Container Runtime Flexibility: While Makefile commands are often documented as docker-build or docker-push, they generally interface with the system's container runtime, which can be Docker or Podman [5][4]. Developers are encouraged to ensure their environment is configured correctly to handle cross-platform builds if necessary (e.g., building amd64 images on arm64 hardware) using --platform flags [4]. 3. Development Environment: Projects are commonly generated using tools like Kubebuilder (e.g., v4.6.0) [2]. The development lifecycle often involves validating changes against the oadp-dev branch of the main oadp-operator repository to ensure compatibility with Velero and other OADP plugins [1][2][3][5]. 4. Checking/Validation: Development validation often involves deploying to a temporary registry like ttl.sh for rapid testing [4], or verifying the generated bundle manifests using the operator-sdk as defined in the operator's main Makefile [6]. For specific implementation details, refer to the Makefile and README.md files located in the respective migtools/kubevirt-datamover-plugin and migtools/kubevirt-datamover-controller repositories [1][2][7].
Citations:
- 1: https://github.com/migtools/kubevirt-datamover-plugin
- 2: https://github.com/migtools/kubevirt-datamover-controller
- 3: https://github.com/openshift/oadp-operator
- 4: https://pkg.go.dev/github.com/migtools/kubevirt-datamover-controller
- 5: https://github.com/oadp-rebasebot/oadp-rebase
- 6: https://github.com/openshift/oadp-operator/blob/oadp-dev/Makefile
- 7: https://github.com/migtools/kubevirt-datamover-controller/blob/oadp-dev/README.md
🏁 Script executed:
# Fetch the Makefile from the specified GitHub link to check its content
curl -s https://github.com/migtools/kubevirt-datamover-plugin/raw/refs/heads/oadp-dev/Makefile | head -100Repository: openshift/release
Length of output: 155
🏁 Script executed:
# Also check if there are any other test-related files in the config
cat -n ci-operator/config/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-1.6.yaml | grep -A 20 "unit-test"Repository: openshift/release
Length of output: 155
🏁 Script executed:
# Try to get the Makefile using git clone or check documentation
# First, let's understand what the ci-operator 'from: src' means by searching for documentation
rg "from: src" ci-operator/config -A 5 -B 5 | head -50Repository: openshift/release
Length of output: 5670
🏁 Script executed:
# Check if there's documentation about ci-operator test steps
find . -name "*.md" -type f | xargs grep -l "from: src" 2>/dev/null | head -5Repository: openshift/release
Length of output: 180
🏁 Script executed:
# Look at the oadp-1.6 version to see if it has the same pattern
cat -n ci-operator/config/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-1.6.yaml | sed -n '20,50p'Repository: openshift/release
Length of output: 346
🌐 Web query:
ci-operator test step from: src container image
💡 Result:
In OpenShift CI, the src container image is a specialized pipeline image that contains the source code of the repository being tested, along with its build dependencies [1]. It is generated automatically by the ci-operator as part of the pipeline initialization process [2][1]. To use the src image in a test step, you reference it via the from field within your test configuration [3][4]. Usage in a Container Test: For a simple container test, you specify the image in the container.from field [3][4]: tests: - as: unit-test commands: make test container: from: src Usage in a Multi-Stage Test: For multi-stage tests, you specify from: src within the individual steps of the test definition [5]: tests: - as: e2e-test steps: test: - as: test-step commands: make test from: src Key Characteristics of the src Image: - Automatic Creation: The ci-operator uses a cloning tool (clonerefs) to inject the source code of the repository into a base image (defined by build_root) and tags the resulting image as src in the pipeline ImageStream [2][1]. - Implicit Source: Unlike standard images, when you use the src image, the source code is already present, so you do not need to perform additional cloning steps within the test container [6]. - Usage: It is primarily intended for running tests, binary builds, or other operations that require access to the source code under test [1].
Citations:
- 1: https://github.com/openshift/ci-operator/blob/master/ONBOARD.md
- 2: https://docs.ci.openshift.org/internals/steps/
- 3: https://github.com/openshift/ci-operator/blob/master/CONFIGURATION.md
- 4: https://docs.ci.openshift.org/architecture/ci-operator/
- 5: https://docs.ci.openshift.org/how-tos/migrating-template-jobs-to-multistage/
- 6: https://docs.ci.openshift.org/getting-started/examples/
🏁 Script executed:
# Check if the kubevirt-datamover-plugin repository is in this repo or if we can look at the Makefile differently
# Let's search for any Makefile references or documentation
find . -type f -name "Makefile" | grep -i "datamover" 2>/dev/nullRepository: openshift/release
Length of output: 155
🏁 Script executed:
# Let's check if there's a reference to the repository content in the release repo
# Look for any OWNER or build info that might hint at the Makefile
rg "oadp-dev" ci-operator/config/migtools/kubevirt-datamover-plugin/ -A 10 -B 10Repository: openshift/release
Length of output: 4257
🏁 Script executed:
# Let's examine what "src" image is in the build_root context for this repo
cat -n ci-operator/config/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev.yamlRepository: openshift/release
Length of output: 1115
🌐 Web query:
kubevirt-datamover-plugin oadp-dev Makefile test target
💡 Result:
In the migtools/kubevirt-datamover-plugin project, the make test target is the standard command used to execute unit tests [1]. This command is typically defined in the repository's Makefile to run the project's Go-based test suite, often utilizing standard Go testing tools. While specific implementation details can evolve, typical development commands in related OADP (OpenShift APIs for Data Protection) projects—such as the kubevirt-datamover-controller—include make test for unit testing and additional targets like make fmt, make vet, and make lint for code quality checks [2][3]. For developers working within the oadp-dev branch or related OADP development environments, make test is a foundational command for validating changes before submission [1][2]. If you are working on a specific fork or a version-controlled branch, it is recommended to inspect the local Makefile directly, as it contains the precise shell commands—such as go test configurations—that are executed when the target is invoked [1][4].
Citations:
- 1: https://github.com/migtools/kubevirt-datamover-plugin
- 2: https://github.com/migtools/kubevirt-datamover-controller
- 3: https://pkg.go.dev/github.com/migtools/kubevirt-datamover-controller
- 4: https://github.com/openshift/oadp-operator/blob/oadp-dev/Makefile
🏁 Script executed:
# Let me check the builder image details more carefully and see if there are any other test configs
cat -n ci-operator/config/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-1.6.yamlRepository: openshift/release
Length of output: 832
🌐 Web query:
ubi9-v1.23 konveyor builder image docker podman
💡 Result:
The konveyor/builder is a container image maintained by the Konveyor community, primarily used for building projects and plugins related to Konveyor and OpenShift, such as OADP (OpenShift API for Data Protection) [1][2][3]. The image is based on the Red Hat Universal Base Image 9 (UBI 9) [1][4]. While you may see references to specific UBI9-based tags like ubi9-v1.23, ubi9-v1.24, or ubi9-v1.25 in CI configurations and pull requests (often linked to underlying toolset versions or specific project releases) [2][5], the most common production tag used in Dockerfiles is typically quay.io/konveyor/builder:ubi9-latest [6][3][7]. Usage with Docker or Podman You can use this builder image in your container builds by referencing it in a multi-stage Dockerfile. Both Docker and Podman support this workflow seamlessly as the image follows the standard OCI (Open Container Initiative) format [8]. Example multi-stage Dockerfile pattern: FROM quay.io/konveyor/builder:ubi9-latest AS builder WORKDIR /app COPY.. RUN go build -o my-app. FROM registry.access.redhat.com/ubi9-minimal COPY --from=builder /app/my-app /usr/bin/my-app ENTRYPOINT ["/usr/bin/my-app"] Technical Notes: 1. Compatibility: Because the builder is based on UBI 9, it is designed to be compatible with Red Hat Enterprise Linux 9-based environments [4][9]. 2. Podman/Docker Environments: When building UBI 9 images on non-x86_64 host architectures (like Apple Silicon/macOS ARM64), ensure your container runtime (Podman/Docker) environment is configured correctly for emulation or cross-platform builds, as some older configurations experienced glibc errors related to x86-64-v2 compatibility [10]. 3. Versioning: If you encounter specific versioned tags like ubi9-v1.23, they typically correspond to the specific build environment configuration for a project's CI pipeline [2][5]. For general use, quay.io/konveyor/builder:ubi9-latest is the recommended tag to ensure you are using an updated, UBI 9-based environment [6][3].
Citations:
- 1: https://github.com/konveyor/builder
- 2: Add OADP 1.5 image build and mirroring for hypershift-oadp-plugin #80356
- 3: https://github.com/openshift/oadp-operator/blob/7bfc0307/Dockerfile
- 4: https://github.com/konveyor/builder/blob/main/Dockerfile.ubi9
- 5: openshift/assisted-service@c118a26
- 6: openshift/velero-plugin-for-microsoft-azure@065f7ed
- 7: openshift/velero@b8f68fe
- 8: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/building_running_and_managing_containers/assembly_working-with-container-images_building-running-and-managing-containers
- 9: https://hub.docker.com/r/redhat/ubi9-micro
- 10: MacOS (arm64) + podman + ubi9: 'Fatal glibc error: CPU does not support x86-64-v2' konveyor/tackle2-hub#180
🏁 Script executed:
# Let me search for any documentation about what the builder image contains
rg "konveyor.*builder" . -A 3 -B 3 | head -50Repository: openshift/release
Length of output: 3227
🏁 Script executed:
# Let me search for any GitHub references or PRs that mention this issue
rg "make test" . -B 5 -A 5 | grep -i "datamover\|podman\|docker" | head -30Repository: openshift/release
Length of output: 5675
🏁 Script executed:
# Check if the konveyor builder Dockerfile is available in the release repo
find . -name "Dockerfile*" -type f | xargs grep -l "konveyor" 2>/dev/null | head -5Repository: openshift/release
Length of output: 155
🌐 Web query:
konveyor builder ubi9 includes podman docker tools
💡 Result:
The Konveyor builder image based on UBI 9 (quay.io/konveyor/builder:ubi9-latest) does not include Podman or Docker tools by default [1]. The Dockerfile.ubi9 for the Konveyor builder image explicitly installs a specific set of development tools: go, git, make, jq, and unzip [1]. It is built upon the standard Red Hat Universal Base Image 9 (ubi9:latest) [1]. While Red Hat Enterprise Linux 9 provides container management tools like Podman, Buildah, and Skopeo as part of the container-tools meta-package [2][3], these are not included in the default configuration of the Konveyor builder image [1]. In many Konveyor-related projects, build processes (such as those defined in Makefiles) are designed to dynamically detect and use whichever container runtime (Podman or Docker) is available on the host system where the build command is executed, rather than relying on tools packaged inside the builder container itself [4].
Citations:
- 1: https://github.com/konveyor/builder/blob/main/Dockerfile.ubi9
- 2: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/htmlsingle/building_running_and_managing_containers/assembly_adding-software-to-a-ubi-container_building-running-and-managing-containers
- 3: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/building_running_and_managing_containers/assembly_adding-software-to-a-ubi-container_building-running-and-managing-containers
- 4: https://github.com/kubevirt/kubevirt-velero-plugin/blob/main/Makefile
🏁 Script executed:
# Let me check if there are any comments or notes in the release repo about this specific issue
rg "container.runtime\|podman\|docker" ci-operator/config/migtools/ -A 2 -B 2Repository: openshift/release
Length of output: 155
🏁 Script executed:
# Let me search for patterns in the release repo about NO_DOCKER or similar workarounds
rg "NO_DOCKER\|NO_PODMAN" ci-operator/config/ | head -20Repository: openshift/release
Length of output: 155
🏁 Script executed:
# Check if there are any other kubevirt or datamover related configs with different commands
rg "datamover\|kubevirt" ci-operator/config/ -A 5 | grep "commands:" | head -10Repository: openshift/release
Length of output: 155
Avoid the Makefile container-runtime prerequisite by calling go test directly.
The oadp-dev Makefile checks for docker or podman at parse time. The src test image (konveyor/builder:ubi9-v1.23) does not include either tool. When make test runs, the Makefile exits before executing go test ./kubevirt-datamover-plugin/.... Call the Go test command directly instead.
Proposed fix
- commands: make test
+ commands: go test ./kubevirt-datamover-plugin/...📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| commands: make test | |
| from: src | |
| commands: go test ./kubevirt-datamover-plugin/... | |
| from: src |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@ci-operator/config/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev.yaml`
around lines 30 - 31, Replace the `commands: make test` entry in the `oadp-dev`
test configuration with a direct `go test ./kubevirt-datamover-plugin/...`
invocation, preserving `from: src` and avoiding the Makefile’s container-runtime
prerequisite.
Source: MCP tools
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
kaovilai
changed the title
openshift-ci
Bot
added
the
needs-rebase
|
@kaovilai, Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@ci-operator/config/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev.yaml`:
- Around line 41-79: Run make update to regenerate and sanitize the CI metadata
and Prow job definitions for the new e2e-test-aws job. Apply the generated
changes for
ci-operator/config/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev.yaml
lines 41-79 and
ci-operator/config/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev.yaml
lines 41-79, then commit all resulting generated files so Prow registers both
presubmits.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 57b2a657-6601-4add-84b2-27a8de580657
⛔ Files ignored due to path filters (7)
ci-operator/jobs/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev-postsubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev-presubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev-postsubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev-presubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/openshift/oadp-operator/openshift-oadp-operator-oadp-dev-periodics.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/openshift/oadp-operator/openshift-oadp-operator-oadp-dev-postsubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/openshift/oadp-operator/openshift-oadp-operator-oadp-dev-presubmits.yamlis excluded by!ci-operator/jobs/**
📒 Files selected for processing (3)
ci-operator/config/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev.yamlci-operator/config/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev.yamlci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-dev.yaml
|
/test all Note Responses generated with Claude |
48f6123 to
0b8ef64
Compare
|
/test all Note Responses generated with Claude |
openshift-ci
Bot
removed
the
needs-rebase
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
/pj-rehearse pull-ci-migtools-kubevirt-datamover-controller-oadp-dev-e2e-test-aws pull-ci-migtools-kubevirt-datamover-plugin-oadp-dev-e2e-test-aws pull-ci-openshift-oadp-operator-oadp-dev-ci-index Note Responses generated with Claude |
|
@kaovilai: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@ci-operator/config/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev.yaml`:
- Around line 62-66: Add --request-timeout=10s to the oc get invocation in the
retry loop so each request is bounded and the existing 60-iteration deadline
remains enforceable.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: b4ec95dc-6677-49a4-9dba-ad5a10e72fc1
⛔ Files ignored due to path filters (4)
ci-operator/jobs/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev-postsubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev-presubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev-postsubmits.yamlis excluded by!ci-operator/jobs/**ci-operator/jobs/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev-presubmits.yamlis excluded by!ci-operator/jobs/**
📒 Files selected for processing (2)
ci-operator/config/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev.yamlci-operator/config/migtools/kubevirt-datamover-plugin/migtools-kubevirt-datamover-plugin-oadp-dev.yaml
| for i in $(seq 1 60); do | ||
| CURRENT=$(oc get deployment/openshift-adp-controller-manager -n "${OO_INSTALL_NAMESPACE}" -o jsonpath="{.spec.template.spec.containers[?(@.name=='manager')].env[?(@.name=='RELATED_IMAGE_KUBEVIRT_DATAMOVER_CONTROLLER')].value}" 2>/dev/null || true) | ||
| [ "${CURRENT}" = "${KDM_CONTROLLER_IMAGE}" ] && break | ||
| sleep 5 | ||
| done |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
oc options 2>&1 | grep -F -- '--request-timeout'Repository: openshift/release
Length of output: 155
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file='ci-operator/config/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev.yaml'
printf '%s\n' '--- target lines ---'
sed -n '45,80p' "$file"
printf '%s\n' '--- related timeout and oc usage ---'
rg -n -C 3 --fixed-strings 'openshift-adp-controller-manager' .
rg -n -C 2 'oc (get|wait)|request-timeout|timeout [0-9].*oc|timeout --' "$file" .github ci-operator 2>/dev/null | head -n 240Repository: openshift/release
Length of output: 50375
🌐 Web query:
OpenShift oc CLI documentation for --request-timeout, including whether oc supports the kubectl request-timeout option and its default behavior
💡 Result:
The OpenShift CLI (oc) supports the --request-timeout option, which functions similarly to the equivalent option in kubectl [1][2][3]. Documentation and Behavior: The --request-timeout flag specifies the length of time the client waits before giving up on a single server request [1][4]. It requires a value with a corresponding time unit (e.g., 1s, 2m, 3h) if a non-zero value is provided [1][3]. Default Behavior: The default value for --request-timeout is "0", which signifies that the client will not timeout requests [1][3]. Compatibility with kubectl: Because oc is built upon the Kubernetes client libraries, it supports the --request-timeout option in the same manner as kubectl [3]. Both tools interpret the flag to control the timeout duration for API server interactions [1][3]. While most commands consistently respect this flag, historical issues have been noted where specific sub-commands (such as oc login in older versions) did not always honor the timeout correctly, necessitating patches to ensure the configuration is properly passed to the underlying REST client [5][6][7].
Citations:
- 1: https://manpages.opensuse.org/Tumbleweed/oc/oc.1.en.html
- 2: https://manpages.opensuse.org/Tumbleweed/oc/oc-config.1.en.html
- 3: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_options/
- 4: https://manpages.opensuse.org/Tumbleweed/oc/oc-create-job.1.en.html
- 5: oc login does not honor --request-timeout option origin#18159
- 6: oc login does not honor
--request-timeoutoption origin#12059 - 7: https://github.com/ardaguclu/oc/blob/v4.2.0-alpha.0/pkg/cli/login/loginoptions.go
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- oc references and installation/version evidence ---'
rg -n -C 3 '\boc\b|openshift-client|ocp|OPENSHIFT_VERSION|CLUSTER_VERSION' \
ci-operator/config/migtools/kubevirt-datamover-controller \
ci-operator/jobs/migtools/kubevirt-datamover-controller \
.github 2>/dev/null | head -n 300
printf '%s\n' '--- file metadata and nearby job structure ---'
wc -l ci-operator/config/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev.yaml
sed -n '1,120p' ci-operator/config/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev.yamlRepository: openshift/release
Length of output: 4329
🌐 Web query:
site:docs.openshift.com oc request-timeout oc get
💡 Result:
There is no global --request-timeout flag for the oc get command [1][2]. The --timeout option available with oc get is specifically used to set the length of time to wait for a specific operation to complete, such as waiting for a node or a resource to reach a specific state [1]. If you are looking to manage timeouts for network traffic or application routes, you must use different methods depending on the context: 1. Route Timeouts: You can configure timeouts for specific routes using the oc annotate command to add a timeout value to the route's configuration: oc annotate route <route_name> --overwrite haproxy.router.openshift.io/timeout=<time_unit> Supported time units include ms, s, m, h, and d [3][4]. 2. Ingress Controller Timeouts: For global ingress settings, you can configure timeout values within the Ingress Controller's configuration, such as clientTimeout or serverTimeout [5]. If you were referring to a different CLI tool, such as roxctl, that tool does feature a --timeout flag for API requests [6], but this does not apply to the standard oc CLI.
Citations:
- 1: https://docs.openshift.com/container-platform/4.18/nodes/nodes/nodes-sno-worker-nodes.html
- 2: https://docs.openshift.com/container-platform/4.18/getting_started/openshift-cli.html
- 3: https://docs.openshift.com/container-platform/4.16/networking/routes/route-configuration.html
- 4: https://docs.openshift.com/container-platform/3.5/install_config/configuring_routing.html
- 5: https://docs.openshift.com/container-platform/4.9/networking/ingress-operator.html
- 6: https://docs.openshift.com/acs/4.3/cli/debugging-issues.html
Bound each oc request.
Line 63 can block indefinitely because oc get has no request timeout. Add --request-timeout=10s so the loop can enforce its retry deadline.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@ci-operator/config/migtools/kubevirt-datamover-controller/migtools-kubevirt-datamover-controller-oadp-dev.yaml`
around lines 62 - 66, Add --request-timeout=10s to the oc get invocation in the
retry loop so each request is bounded and the existing 60-iteration deadline
remains enforceable.
Source: MCP tools
kaovilai
changed the title
|
/test all Note Responses generated with Claude |
|
/pj-rehearse ack Note Responses generated with Claude |
|
@kaovilai: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
openshift-merge-bot
Bot
added
rehearsals-ack
|
/pj-rehearse ack Jobs cannot rehearse yet need images which will come post merge |
|
@kaovilai: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
openshift-merge-bot
Bot
added
the
rehearsals-ack
|
@kaovilai: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
f909713 to
87b26ea
Compare
|
@kaovilai: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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 kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
/pj-rehearse pull-ci-migtools-kubevirt-datamover-controller-oadp-dev-e2e-test-aws pull-ci-migtools-kubevirt-datamover-controller-oadp-1.6-e2e-test-aws pull-ci-migtools-kubevirt-datamover-plugin-oadp-dev-e2e-test-aws pull-ci-migtools-kubevirt-datamover-plugin-oadp-1.6-e2e-test-aws Note Responses generated with Claude |
|
@kaovilai: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
87b26ea to
54041a2
Compare
|
/pj-rehearse pull-ci-migtools-kubevirt-datamover-controller-oadp-dev-e2e-test-aws pull-ci-migtools-kubevirt-datamover-controller-oadp-1.6-e2e-test-aws pull-ci-migtools-kubevirt-datamover-plugin-oadp-dev-e2e-test-aws pull-ci-migtools-kubevirt-datamover-plugin-oadp-1.6-e2e-test-aws Note Responses generated with Claude |
|
@kaovilai: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
migtools/kubevirt-datamover-controller and migtools/kubevirt-datamover-plugin (oadp-dev branch) had zero CI test coverage — only image builds. Both ship a self-contained `make test` (envtest for the controller, plain go test for the plugin), so wire that up as a standard unit-test presubmit. disable_sparse_checkout is required: without it prowgen defaults these repos to a Dockerfile-only sparse checkout (fine for the image-build job, but it starves `make test` of the Makefile/go source it needs). Partial step toward openshift/oadp-operator#1832 (Group A2: controllers reconciled by the operator, gated on a DPA feature flag). The harder half — installing oadp-operator via OLM against the PR-built kdm image and running its e2e suite — is blocked on there being no reusable oadp-dev catalog/index image (oadp-operator's ci-index is built ephemeral, per-PR, and never promoted), so that part isn't in this PR. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
The unit-test presubmit added in the previous commit was redundant with kubevirt-datamover-controller's existing GitHub Actions test.yml, and missed the actual goal: gating these repos' PRs on oadp-operator's real e2e suite (openshift/oadp-operator#1832, Group A2), not local unit tests. Adds the real integration: - oadp-operator's own oadp-dev config now builds an operator bundle/index (operator.bundles) and the ci-Dockerfile e2e test binary, promoting both (as oadp-operator-index / oadp-operator-e2e-tests) on every merge. This is what kdm-controller/plugin need to install oadp-operator via OLM and run its e2e suite — previously only the operator binary was promoted; the bundle/index/test-binary were built ephemeral, per-PR, and only inside oadp-operator's own job. - kdm-controller/plugin presubmits: install oadp-operator via optional-operators-ci-aws from that promoted index, patch the running operator deployment's RELATED_IMAGE_KUBEVIRT_DATAMOVER_CONTROLLER / RELATED_IMAGE_KUBEVIRT_DATAMOVER_PLUGIN env to the PR-built image (oc set env, not the subscribe ref's OO_CONFIG_ENVVARS -- that can only override dependencies a step already declares, not inject a new one), then run `make TEST_VIRT=true test-e2e` from the promoted test binary. TEST_VIRT=true makes the suite install community KubeVirt/HCO itself and run the kubevirt-datamover-labeled specs (incl. VM backup/restore), so no separate CNV step-registry chain is needed. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Patching the Deployment directly (oc set env deployment/...) doesn't survive OLM's own reconciliation: CSV.spec is what OLM continuously reconciles the Deployment from, so a direct Deployment edit would very plausibly get reverted mid-test. Subscription.spec.config.env is OLM's documented, supported override mechanism instead -- it wins over a same-named CSV env var and is designed to persist across reconciliation and upgrades. Patch that instead of hand-editing the CSV's deployment array. Also point releases.latest at the 5.0 nightly candidate instead of 4.22, matching the actual current oadp-dev target. (Resource sizing for the e2e step was cross-checked against oadp-operator's own existing e2e-test-kubevirt-aws-periodic job -- already an exact match, no change needed there.) Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
oc patch subscription ... followed immediately by oc rollout status was racy: rollout status can report the existing rollout as already-complete before OLM has even noticed the Subscription change and pushed a new Deployment generation, letting the e2e suite start against the original promoted image instead of the PR's. Poll the Deployment's own env value until it reflects the override before checking rollout status. Also drop prowgen.disable_sparse_checkout: true -- it was only needed for the unit-test job's `from: src` step, which no longer exists (the e2e steps run from `cli` and `test-oadp-operator`, not `src`). Removing it reverts the images/postsubmit jobs to their original Dockerfile-only sparse checkout, avoiding unrelated churn and CI runtime. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
additional_images maps {destination-name: pipeline-source-tag} -- I had
it backwards (ci-index: oadp-operator-index instead of
oadp-operator-index: ci-index), and had it on the wrong promotion.to[]
entry. Confirmed via ci-tools source (ImageTargets() inserts the *value*
as a required build target) and two working examples elsewhere in this
repo (quay-operator, vertical-pod-autoscaler-operator): the value must be
a real pipeline tag. With the original ordering, the postsubmit's
generated promote targets were `oadp-operator-e2e-tests`/
`oadp-operator-index` -- neither is a real pipeline image in this config,
so the actual postsubmit run would have failed outright once merged.
Also: the original single promotion.to[] entry has an explicit `name`
(shared-imagestream mode), where each promoted image becomes a *tag*
under that one name rather than its own imagestream -- fine for the
existing lone "oadp-operator" image, but wrong for what I actually want
(oadp-operator-index and oadp-operator-e2e-tests as their own separate
imagestreams, matching the kdm repos' base_images references). Moved
additional_images to a second to[] entry with no `name` and an explicit
`tag: latest`, which is the tag-mode that produces per-key imagestreams
instead. Added excluded_images to the original entry so it doesn't also
try to sweep the newly-added test-oadp-operator image into the shared
"oadp-operator" stream.
Verified: generated postsubmit promote targets are now `ci-index` and
`test-oadp-operator` -- real pipeline tags -- instead of the bogus names.
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
oadp-dev and oadp-1.6 both promoting oadp-operator-index/ oadp-operator-e2e-tests to the same konveyor namespace under tag "latest" would collide -- whichever branch's postsubmit ran last would clobber the other's promoted image. Give oadp-dev's entry an explicit tag: oadp-dev instead, matching the branch-specific-tag/shared-name convention the kdm repos' own promotion already uses. Updated their base_images tag references to match. Replicates the same real oadp-operator e2e wiring (see prior commits on this branch) for the oadp-1.6 branch: - oadp-operator's oadp-1.6 base config: same two-entry promotion split (existing name-mode entry + excluded_images, new tag-mode entry for oadp-operator-index/oadp-operator-e2e-tests tagged oadp-1.6). - kdm-controller/kdm-plugin oadp-1.6 configs: same e2e-test-aws presubmit, adjusted for this branch: OO_CHANNEL: stable (matching oadp-operator's own oadp-1.6 e2e jobs, vs "dev" for oadp-dev), and dependency names pointing at this branch's own local build names (kubevirt-datamover-controller-oadp-1.6 / -plugin-oadp-1.6). Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
CodeRabbit flagged the single-quoted @.name=='manager' style filter comparisons as risky. Kubernetes' JSONPath implementation documents double-quoted string literals in filter expressions; switch to that form (escaped, since the outer jsonpath argument is itself double-quoted) to remove any doubt about whether the polling loop's match would silently fail to parse. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
…undle The promoted oadp-operator-index bakes in a reference to the bundle image from its own building job's ephemeral namespace, which becomes unreachable once that namespace is torn down - BundleUnpackFailed on rehearsal confirmed this. Promote the bundle itself instead (skip_building_index) and install it directly via operator-sdk run bundle, which needs no index/catalog at all. Also fixes a self-referential OO_INSTALL_MODE bug in the shared optional-operators-operator-sdk-non-ci-bundle-image step that silently dropped the install-mode flag for every consumer. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
If the Deployment env poll times out, we can't yet tell whether OLM failed to propagate Subscription.spec.config.env to an already-Succeeded CSV (the likely cause) versus the Subscription patch having gone to the wrong object. Capture both objects as artifacts so a re-run isn't needed to distinguish them. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
dnf install -y skopeo fails in the step pod's non-root user: error: Failed to create: /var/cache/yum/metadata Confirmed on an actual rehearsal run (kubevirt-datamover-plugin oadp-dev e2e-test-aws). Extract a pre-built skopeo binary directly from the public quay.io/skopeo/stable image instead, via oc image extract -- the same established pattern already used by hypershift-install-commands.sh, aws-load-balancer-pre-install-rosa-commands.sh, and the cucushift upgrade steps for pulling a single binary (ccoctl, hypershift) out of an image without needing package management or root. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
oc registry login's default write location (/run/containers/...) isn't
writable by the step pod's non-root user:
error: mkdir /run/containers: permission denied
Confirmed on an actual rehearsal run (kubevirt-datamover-plugin oadp-dev
e2e-test-aws) -- opm/umoci/skopeo installation all succeeded this time,
this was the next blocker.
Pass an explicit writable --to= path and reuse it via skopeo's
--authfile flag for both copy invocations, matching the existing
--to="${auth_file}" pattern already used elsewhere in this repo
(quay-omr-v3-install-commands.sh and others).
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Confirmed on an actual rehearsal run (kubevirt-datamover-controller oadp-dev e2e-test-aws): opm index add failed to resolve OO_BUNDLE (registry.ci.openshift.org/konveyor/oadp-operator-bundle:oadp-dev) with "not found" -- oc registry login only authenticates against whatever THIS build-farm cluster's own registry route is (registry.build11.ci.openshift.org in that run), which is unrelated to registry.ci.openshift.org, the separate cross-cluster/cross-repo registry hosting the promoted bundle. Two separate fixes: 1. Extract the TEST cluster's own global pull secret (secret/pull-secret in openshift-config, via the default KUBECONFIG at this point in the pre chain, which already points at the test cluster) and export it as REGISTRY_AUTH_FILE, the standard env var opm's underlying containers/image library respects. This is the same pull secret operator-sdk run bundle already successfully used to pull this exact OO_BUNDLE pullspec in the prior design. 2. Read the actual authenticated hostname back out of oc registry login's own auth file (jq '.auths | keys[0]') instead of hardcoding registry.ci.openshift.org for INDEX_DESTINATION -- the two are not interchangeable, and the hardcoded value would have broken the later publish step too even once the pull was fixed. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Confirmed on an actual rehearsal run (kubevirt-datamover-plugin oadp-dev e2e-test-aws): oc extract + oc registry login both succeeded this time, but the subsequent jq call to read the registry hostname back out of the auth file failed with "jq: command not found" -- the cli base image doesn't ship jq. Install it the same way as opm/umoci in this same script (and the same way gather-extra-commands.sh already does elsewhere in this repo): a static jq-1.6 binary via curl into TOOLS_DIR. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Confirmed on an actual rehearsal run (kubevirt-datamover-controller oadp-1.6 e2e-test-aws): opm index add still failed to resolve OO_BUNDLE from registry.ci.openshift.org/konveyor/... even after exporting REGISTRY_AUTH_FILE to the extracted cluster-wide pull secret -- operator-registry issue openshift#935 notes opm's in-process containerd-based registry client has had auth-handling quirks distinct from podman/skopeo, particularly with complex multi-entry auth files (the cluster-wide pull-secret merges many registries' credentials). Sidestep this entirely: skopeo (already proven working, with explicit --src-authfile/--dest-authfile) mirrors OO_BUNDLE into this job's own, single-entry-auth build-farm namespace first, then opm index add pulls from that simpler, already-authenticated destination instead of touching registry.ci.openshift.org directly. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Confirmed on an actual rehearsal run (kubevirt-datamover-controller oadp-dev e2e-test-aws): the skopeo binary extracted via oc image extract from quay.io/skopeo/stable is dynamically linked and fails immediately at its first invocation: skopeo: error while loading shared libraries: libsubid.so.5: cannot open shared object file: No such file or directory Extracting just the binary (not its shared-library dependencies) from a foreign image doesn't work for a dynamically-linked binary. dnf install -y skopeo pulls in the correct dependency chain automatically, but plain dnf install failed earlier in this same script's iteration with "Failed to create: /var/cache/yum/metadata" (the non-root step-pod user can't write there). Redirect only dnf's own cache directory to /tmp via --setopt=cachedir, leaving the actual package install at its normal system paths (/usr/bin, /usr/lib64, etc, which appear to be writable, unlike /var/cache specifically). Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Confirmed on an actual rehearsal run (kubevirt-datamover-plugin
oadp-1.6 e2e-test-aws): dnf install -y --setopt=cachedir=/tmp/dnf-cache
skopeo still failed identically to plain dnf install ("Failed to
create: /var/cache/yum/metadata") -- the cachedir override wasn't
honored (this dnf/yum appears to hardcode that path via config,
unaffected by the CLI setopt).
Rather than keep chasing dnf/yum permission quirks, or extracting just
the binary again (which failed at runtime on a missing shared library,
libsubid.so.5, not present in this image), extract the ENTIRE
quay.io/skopeo/stable filesystem via oc image extract --path /:...,
and wrap the binary with a small script that points LD_LIBRARY_PATH at
that same extracted tree's own lib directories. This guarantees every
runtime dependency comes from one single, official, already-trusted
source, instead of chasing missing .so files one at a time or
depending on an unofficial third-party static build.
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
54041a2 to
377e3a9
Compare
|
/pj-rehearse pull-ci-migtools-kubevirt-datamover-controller-oadp-dev-e2e-test-aws pull-ci-migtools-kubevirt-datamover-controller-oadp-1.6-e2e-test-aws pull-ci-migtools-kubevirt-datamover-plugin-oadp-dev-e2e-test-aws pull-ci-migtools-kubevirt-datamover-plugin-oadp-1.6-e2e-test-aws Note Responses generated with Claude |
|
@kaovilai: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
[REHEARSALNOTIFIER]
A total of 999 jobs have been affected by this change. The above listing is non-exhaustive and limited to 25 jobs. A full list of affected jobs can be found here Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
The OWNERS file contains untrusted users, which makes it INVALID. The following users are mentioned in OWNERS file(s) but are untrusted for the following reasons. One way to make the user trusted is to add them as members of the openshift org. You can then trigger verification by writing
|
2 participants
Summary
Adds real oadp-operator e2e coverage for
migtools/kubevirt-datamover-controllerandmigtools/kubevirt-datamover-plugin, on bothoadp-devandoadp-1.6, per openshift/oadp-operator#1832 (Group A2: operator-reconciled controllers gated on a DPA feature flag). Each repo's presubmit installs oadp-operator directly from its promoted bundle image viaoperator-sdk run bundle, substitutes the PR-built controller/plugin image into the running operator, and runs oadp-operator's own e2e suite — including the KubeVirt VM backup/restore specs already in that suite (e.g. openshift/oadp-operator#2350).This depends on openshift/release#83110 (merged), which first added the promoted
oadp-operator-index/oadp-operator-e2e-testsimages. This PR replaces the index half of that with a promoted bundle instead — see "Why not an index" below for why the original index-based design didn't actually work.Design
openshift/oadp-operator(base config for each branch)operator.bundles[].skip_building_index: true(as: oadp-operator-bundle) builds and promotes just the bundle image (oadp-operator-bundle), no index/catalog at all — see rationale below.oadp-operator-e2e-tests(the e2e test binary) is unchanged.migtools/kubevirt-datamover-controller+kubevirt-datamover-plugin(oadp-devandoadp-1.6)e2e-test-awspresubmit per branch (run_if_changed, not always-on):ipi-aws-pre→optional-operators-operator-sdk-non-ci-bundle-imageinstalls oadp-operator directly from the promoted bundle (OO_BUNDLE: registry.ci.openshift.org/konveyor/oadp-operator-bundle:{oadp-dev,oadp-1.6}) viaoperator-sdk run bundle— no index/CatalogSource image involved. (operator-sdkstill creates a CatalogSource/OperatorGroup/Subscription under the hood — it just serves the catalog from a bundle-backed pod it manages itself, inopenshift-adp, rather than pointing at a pre-built index image. The prior index-based design's CatalogSource also lived inopenshift-adp, so this isn't a new namespace footprint; verified oadp-operator's e2e suite has no unfiltered pod-count assertions or namespace teardown that this would disturb — its one pod check is scoped byLabelSelector: "component=velero".)set-related-image: discovers the Subscription OLM created (oc get subscription -n ${OO_INSTALL_NAMESPACE} -o jsonpath=...—operator-sdk run bundledoesn't write a SHARED_DIR marker for it the wayoptional-operators-subscribedoes; the namespace is created fresh by this same step script if it doesn't exist, so exactly one Subscription is expected), thenoc patch subscription ... RELATED_IMAGE_KUBEVIRT_DATAMOVER_CONTROLLER=(_PLUGINfor the plugin repo) viaSubscription.spec.config.env, OLM's supported override mechanism: per OLM's own design doc, values set here overwrite same-named CSV env vars and survive reconciliation, unlike patching the Deployment directly. Polls the Deployment's own env value before callingoc rollout status(checking immediately after the patch is racy — can report the pre-existing rollout as already complete before OLM notices the Subscription change).make TEST_VIRT=true test-e2efrom the promotedtest-oadp-operatorimage, same as before.Also fixes a real bug in the shared
optional-operators-operator-sdk-non-ci-bundle-imagestep:INSTALL_MODE_ARG=--install-mode="${INSTALL_MODE_ARG}"was self-referential and silently droppedOO_INSTALL_MODEfor every consumer of that step. Fixed to reference${OO_INSTALL_MODE}. Note: for oadp-operator specifically this isn't load-bearing — its CSV only declaresOwnNamespaceas a supported install mode, sooperator-sdk's own fallback logic (pick the first supported mode when none is explicitly forced) would land onOwnNamespaceregardless of the bug. It's still a real bug worth fixing (and we setOO_INSTALL_MODE: OwnNamespaceexplicitly regardless, so behavior here is pinned rather than incidental) — just correcting the record that it wasn't actually blocking this PR.Why not an index
The original design (this PR's earlier revisions, and #83110) promoted an
oadp-operator-indexbuilt via ci-operator'soperator.bundles(noskip_building_index). Rehearsing against the real promoted images failed withBundleUnpackFailed: Bundle image pull failed. Root cause, confirmed from oadp-operator's own promotion postsubmit log: ci-operator builds the bundle as an image inside the building job's own namespace, then bakes a reference to that bundle's pullspec into the generated index. That reference is reachable only while the building job's namespace is still alive (same-job consumption, e.g. oadp-operator's own periodic e2e, works fine) — we'd promoted only the index, never the bundle, so once oadp-operator's build namespace was torn down, the baked-in bundle reference became permanently unreachable from any other job's namespace.Fix: promote the bundle itself (precedent:
quay/quay-operatoruses the sameskip_building_index: truepattern) and install directly from it viaoperator-sdk run bundle(precedent:openshift-file-integrity-operator, which already installs cross-repo from a bundle image this way, no index/catalog needed at all). Confirmed the bundle pull itself is not a concern — the failed rehearsal'sCatalogSourcealready reachedREADYpulling fromregistry.ci.openshift.org/konveyor/...(same host, same namespace, same cluster pull secret the bundle now uses).OLMv1 compatibility
Unaffected by the above — this PR doesn't produce an FBC catalog either. Same underlying gap as before: the bundle is legacy
registry+v1format, and oadp-operator's CSV hasn't yet declaredAllNamespacesinstall mode, both tracked separately for OLMv1 adoption.Testing
make ci-operator-config/make jobspass cleanly for all 6 changed configs. Generated job diff confirms the oadp-operator postsubmit's promotion target changed fromci-indextooadp-operator-bundle(and the standaloneci-indexpresubmit is nowci-bundle-oadp-operator-bundle) — the kdm-side job files are unchanged since multi-stage step graphs (pre/post/workflow) resolve from config at ci-operator runtime, not the static Prow job YAML.coderabbit review --agentagainstupstream/mainreports 0 findings.Test plan
make ci-operator-config/make jobspass for all 6 changed configs.ci-index→oadp-operator-bundle) took effect correctly./pj-rehearseagainst the new bundle-direct install path — noBundleUnpackFailed, CSV reachesSucceeded,set-related-imagefinds exactly one Subscription and its override actually applies (not yet exercised by any prior rehearsal — the previous run died at bundle-unpack, before reaching this step).Note
Responses generated with Claude