Allow specified objects to be excluded from the deletion process that Trident-Protect executes.

[rsolsona1]

Subject

We would need Trident-Protect to incorporate a new functionality (RFE) that would allow us to exclude from the process of deleting objects when any of these tasks are executed:

• change status of AMR to "established".
• When running a "shutdownsnapshot".

Details:

Our environment consists of two Openshift clusters, one at the primary site and one at the replication (DR) site.

In our case we have two problems that we could solve if we could prevent the deletion of some objects:

1. - 3Scale Operator:

This controller deploys PVCs in the namespace, but configures in the PVCs an "ownerReferences" that points to the "apimanager" object that it also creates in the same namespace.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
.
..
ownerReferences:

• apiVersion: apps.3scale.net/v1alpha1
  blockOwnerDeletion: true
  controller: true
  kind: APIManager
  name: apimanager-example-ti
  uid: f63be68b-902c-4584-ad41-0e004fd810df
  resourceVersion: "2510363640"
  uid: 4843014c-a810-4e3d-b56a-bcbaabd7c0b0
  spec:
  .
  …

When the shutdownsnapshot is executed it deletes the “apimanager” object and immediately the PVCs are deleted by Openshift, then the shutdownsnapshot fails because it cannot generate the snapshots.
If we could prevent Trident-Protect from deleting the "apimanager" object, we would no longer have this problem.

2. - Openshift internal registry Images:

In Openshift, the namespace pods use images from the local Openshift registry. These images are uploaded to each namespace by the developer teams via a push.
When Trident-Protect deletes the native Openshift objects "ImageStreams, ImageStreamTag, ImageTag" the images in the local registry are no longer accessible.
In the event that a shutdownsnapshot is executed or an AMR changes to "established" these 3 objects are deleted.

When we perform a DR from the primary to the secondary site in the namespace of the primary cluster, these 3 objects are deleted, when we perform the failback from the secondary cluster to the primary, the pods do not start because they cannot access the images.
Even if the objects "ImageStreams, ImageStreamTag, ImageTag" have been restored via Trident-Protect in the primary cluster, it is not possible to access the images in the internal registry.
This forces us to re-upload (or build and upload) all the images that were previously in the namespace.
The same happens in the secondary cluster, when the AMR is changed to "established", the images that would have been uploaded to the local registry are lost and have to be re-uploaded.

If we could prevent Trident-Protect from deleting the "ImageStreams, ImageStreamTag, ImageTag" object, we would no longer have this problem.

We have tried exclude these objects in Application, but this not avoid deletion only exclude objects from backup.

apiVersion: protect.trident.netapp.io/v1
kind: Application
metadata:
.
…
spec:
includedNamespaces:

• namespace: 71129-3518-pip-3scale-pre-intra
  resourceFilter:
  resourceMatchers:
  • group: image.openshift.io
    kind: ImageStream
    version: v1
  • group: image.openshift.io
    kind: ImageStreamTag
    version: v1
  • group: image.openshift.io
    kind: ImageTag
    version: v1
    resourceSelectionCriteria: Exclude

Thanks.

[sjpeeris]

Hi @rsolsona1. Thanks for opening the issue. We will investigate and get back to you.