Skip to content

Syncing latest changes from upstream main for ramen#768

Open
df-build-team wants to merge 5 commits into
mainfrom
sync_us--main
Open

Syncing latest changes from upstream main for ramen#768
df-build-team wants to merge 5 commits into
mainfrom
sync_us--main

Conversation

@df-build-team
Copy link
Copy Markdown

PR containing the latest commits from upstream main branch

asn1809 added 2 commits May 11, 2026 11:32
Add support for propagating Recipe resources from source cluster to
destination cluster during DR operations.

When a DRPC specifies a RecipeRef in KubeObjectProtection, the Recipe
is now automatically fetched from the source cluster using
ManagedClusterView and deployed to the destination cluster via
ManifestWork before VRG creation.

- Add `GetRecipeFromManagedCluster()` to MCV utility to fetch Recipe
  from managed clusters
- Add `CreateOrUpdateRecipeManifestWork()` to MW utility to create
  Recipe ManifestWork on destination clusters
- Add `ensureRecipeManifestWork()` to DRPC controller to orchestrate
  Recipe propagation during secondary replication setup
- Integrate Recipe propagation into VolSync secondary setup flow
- Add `MWTypeRecipe` constant for Recipe ManifestWork type
- Update test mocks to support Recipe MCV operations

The Recipe ManifestWork uses orphan deletion policy to preserve the
Recipe resource when the ManifestWork is deleted, allowing Recipe
reuse across DR operations.

Signed-off-by: Annaraya Narasagond <annarayanarasagond@gmail.com>
This commit implements a flexible, user-configurable approach for managing
Velero backup excluded resources through a ConfigMap.

1. On startup, VRG controller ensures default-excluded-resources ConfigMap exists
2. If missing, creates it with hardcoded defaults:
   - volumereplications.replication.storage.openshift.io
   - volumegroupreplications.replication.storage.openshift.io
   - replicationsources.volsync.backube
   - replicationdestinations.volsync.backube
   - persistentvolumeclaims
   - persistentvolumes
   - endpointslices.discovery.k8s.io
   - endpoints
   - volumesnapshots.snapshot.storage.k8s.io
   - volumegroupsnapshots.groupsnapshot.storage.k8s.io

3. Excluded resources are aggregated as: ConfigMap defaults ∪ Recipe exclusions
4. ConfigMap changes are detected and reloaded automatically
5. Validation warns if critical resources are removed.

Signed-off-by: Annaraya Narasagond <annarayanarasagond@gmail.com>
Assited-by: Claude AI
Signed-off-by: Annaraya Narasagond <annarayanarasagond@gmail.com>
@df-build-team df-build-team requested a review from a team May 12, 2026 08:06
@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented May 12, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: df-build-team

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

During relocate operations, PVCs were stuck in Terminating state because
VolSync mount Jobs were not being cleaned up before PVC deletion. The
kubernetes.io/pvc-protection finalizer blocks PVC deletion while Job pods
reference the PVC.

This fix adds mount job cleanup to the common UndoAfterFinalSync()
function, addressing both CG and non-CG workloads with a single
implementation.

Changes:
- Add cleanupMountJobForFinalSync() helper function to handle mount job
  deletion and wait for completion
- Update UndoAfterFinalSync() to call the helper before PVC cleanup
- Add 4 new mount job management methods: DeleteMountJob(),
  WaitForMountJobDeletion(), DeleteMountJobForFinalSync(),
  WaitForMountJobDeletionForFinalSync()

This addresses reviewer feedback to consolidate the fix in a common
function rather than maintaining separate CG and non-CG cleanup paths,
and keeps cognitive complexity within linter limits.

Fixes: DFBUGS-6677
Signed-off-by: raaizik <132667934+raaizik@users.noreply.github.com>
@df-build-team df-build-team force-pushed the sync_us--main branch 2 times, most recently from 9442ac5 to bf7093c Compare May 15, 2026 08:05
The ramen_progression_state metric was not being properly unset when
the DRPC progression state changed, causing stale metrics to persist
with value 1 even after transitioning to a different state.

Root cause: The metric label included the current progression state,
so when the state changed from "WaitOnUserToCleanUp" to "Cleaning Up",
a new metric series was created with the new state in the label, while
the old series remained unchanged at value 1.

Fix: Modified setDRProgressionStateMetric() to iterate through all
tracked states and explicitly set each to either 1 (current state) or
0 (all other states). This ensures no stale metrics persist across
state transitions.

Changes:
- Updated DRProgressionStateMetricLabels() to accept state as parameter
  instead of reading from drpc.Status.Progression
- Modified setDRProgressionStateMetric() to loop through trackedStates
  array and set each metric appropriately
- Ensures metric series are reused (set to 0) rather than left stale

The trackedStates array currently contains only WaitOnUserToCleanUp
but can be easily extended to track additional progression states.

Fixes: Metric persistence issue where ramen_progression_state remained
at 1 after DRPC transitioned from WaitOnUserToCleanUp to Cleaning Up

Signed-off-by: pruthvitd <prd@redhat.com>
@df-build-team df-build-team force-pushed the sync_us--main branch 3 times, most recently from 214644b to bd64d89 Compare May 18, 2026 08:03
…-main

Signed-off-by: DF Build Team <df-build-team@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants