Automate velero secret deployment

[ShyamsundarR]

By adding a new policy and placement to deliver the secret from the ramen namespace on the managed cluster to the velero namespace on the managed cluster.

Using a single policy fails as that expects to be able to resolve the configuration policy before applying the same. As the velero secret is delivered using the delivered S3 secret in the ramen namespace, such a single policy scheme fails.

Related changes to protect the secret using additional finalizers and addressing upgrade cases are also covered in the commit.

Further to delivering the secret, update s3StoreAccessorsGet to process the new secret as the veleroNamespaceSecretKeyRef when the latter is not present in the config file

Signed-off-by: Shyamsundar Ranganathan srangana@redhat.com

[ShyamsundarR]

The policy related changes look good to me. I am a bit worried about adding velero field to the secretsUtil as it doesn't really belong there.

Shouldn't we send the velero details from the ramenconfig in the methods which are implemented by secretUtil?

Should be addressed in the latest set of changes. This part is good for a review.

[ShyamsundarR]

TODO:

• [x] Testing with imperative apps in e2e, to ensure changes are in working order
• [x] Any updates to default ramen config, to not configure veleroNamespaceSecretKeyRef
• [x] Updates to ramenctl, to ignore creating velero secrets in the required format and namespace

[ShyamsundarR]

The ramenctl changes looks good.

The first commit is huge and I don't fully understand it. Chang of this size is likely to contain bugs and regressions, I hope it is not targeted to 4.16.

It is for 4.16

Main issues:

* Why do we use the "v" prefix instead of creating a new clear ramen control name for the secret we generate?

To control overall name length in these cases (including the name length of the OCM policy)

* Why we need different finalizer for velero secerts? (not of code changes for this, not clear what is the benefit)

Answered inline

* I hope we don't adopt _any_ secret from velero namespace. I think we should protect only secrets labeled with ramen specific label. This will help to avoid issue like [Ramen controllers are caching secret/configmaps from all namespaces #1434](https://github.com/RamenDR/ramen/issues/1434)

No we do not, we deliver a secret to the Velero namespace and this is not related to the posted issue.