Add Velero e2e tests

[simonklb]

[!warning] This is a public repository, ensure not to disclose:

• [ ] personal data beyond what is necessary for interacting with this pull request, nor
• [ ] business confidential information, such as customer names.

What kind of PR is this?

Required: Mark one of the following that is applicable:

• [ ] kind/feature
• [x] kind/improvement
• [ ] kind/deprecation
• [ ] kind/documentation
• [ ] kind/clean-up
• [ ] kind/bug
• [ ] kind/other

Optional: Mark one or more of the following that are applicable:

[!important] Breaking changes should be marked kind/admin-change or kind/dev-change depending on type Critical security fixes should be marked with kind/security

• [ ] kind/admin-change
• [ ] kind/dev-change
• [ ] kind/security
• [ ] kind/adr

What does this PR do / why do we need this PR?

• Fixes #1850

Information to reviewers

Added all QA and Velero GOTOs so that I get feedback from both parties. Does the tests look correct, does the test fixes look correct, am I testing Velero correctly and does it cover everything we want tested with Velero?

Me and @aarnq talked offline and decided that modifying the cluster config during the tests isn't a good idea. So to test both Restic and Kopia it's up to the tester to reconfigure the cluster and run the tests twice.

Checklist

• [x] Proper commit message prefix on all commits
• Change checks:
  • [ ] The change is transparent
  • [ ] The change is disruptive
  • [ ] The change requires no migration steps
  • [ ] The change requires migration steps
  • [ ] The change upgrades CRDs
  • [ ] The change updates the config and the schema
• Metrics checks:
  • [ ] The metrics are still exposed and present in Grafana after the change
  • [ ] The metrics names didn't change (Grafana dashboards and Prometheus alerts are not affected)
  • [ ] The metrics names did change (Grafana dashboards and Prometheus alerts were fixed)
• Logs checks:
  • [ ] The logs do not show any errors after the change
• Pod Security Policy checks:
  • [ ] Any changed pod is covered by Pod Security Admission
  • [ ] Any changed pod is covered by Gatekeeper Pod Security Policies
  • [ ] The change does not cause any pods to be blocked by Pod Security Admission or Policies
• Network Policy checks:
  • [ ] Any changed pod is covered by Network Policies
  • [ ] The change does not cause any dropped packets in the NetworkPolicy Dashboard
• Audit checks:
  • [ ] The change does not cause any unnecessary Kubernetes audit events
  • [ ] The change requires changes to Kubernetes audit policy
• Falco checks:
  • [ ] The change does not cause any alerts to be generated by Falco
• Bug checks:
  • [ ] The bug fix is covered by regression tests

[simonklb]

@Pavan-Gunda @OlleLarsson @viktor-f I'd like at least one from the Velero GOTO to also review this before I merge. Does it cover what you want to see tested?

[Pavan-Gunda]

I think this is good. I agree that we don't need to test both restic and kopia here, we can just use whatever is available in the cluster.

restic is going to get deprecated soon anyway, we can just test kopia.

[aarnq]

I think this is good. I agree that we don't need to test both restic and kopia here, we can just use whatever is available in the cluster.

restic is going to get deprecated soon anyway, we can just test kopia.

We don't really want end-to-end tests to modify and apply changes, so that is up to changing default config and templates to move to Kopia. The tests doesn't seem to make any differences regardless, so they don't really need to be adapted.

[Ajarmar]

@simonklb Since this PR is approved, I think it would be good to merge it and create a new issue for the issue you found around subnamespaces.

[simonklb]

@simonklb Since this PR is approved, I think it would be good to merge it and create a new issue for the issue you found around subnamespaces.

https://github.com/elastisys/compliantkubernetes-apps/issues/2321