HOSTEDCP-1416: Hosted Control Planes ETCD Backup API

[jparrill]

This PR contains the definition of a new API under the hostedcluster.spec.etcd group which it's called backup and it will help to perform automated etcd backups using the Hypershift API.

We are reusing the ETCD backup API, which will help on the homogenisation in the backups for Openshift and Hypershift.

[openshift-ci-robot]

@jparrill: This pull request references HOSTEDCP-1416 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set.

In response to this:

This PR contains the definition of a new API under the hostedcluster.spec.etcd group which it's called backup and it will help to perform automated etcd backups using the Hypershift API.

We are reusing the ETCD backup API, which will help on the homogenisation in the backups for Openshift and Hypershift.

Instructions 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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign sjenning for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• enhancements/hypershift/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dhellmann]

#1555 is changing the enhancement template in a way that will cause the header check in the linter job to fail for existing PRs. If this PR is merged within the development period for 4.16 you may override the linter if the only failures are caused by issues with the headers (please make sure the markdown formatting is correct). If this PR is not merged before 4.16 development closes, please update the enhancement to conform to the new template.

[jparrill]

Hey @dhellmann thanks for the heads up, I will take that in mind before the final submission :).

[jparrill]

Mentioning the Hypershift team in order to review and add their thoughts (sorry in advance for the spam):

/cc @csrwng @sjenning @muraee @enxebre @derekwaynecarr @imain @bryan-cox @Patryk-Stefanski @celebdor

[Patryk-Stefanski]

Just a few typos and nitpicks. Otherwise lgtm

[csrwng]

some comments

[jparrill]

I would double-check with the field, but S3 is not very common on-prem. Traditional on-prem is more likely to have NFS.

Yep, me too but I prefer to have an MVP with smaller footprint and then add new storage providers.

[openshift-ci]

@jparrill: all tests passed!

Full PR test history. Your PR dashboard.

Instructions 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/test-infra repository. I understand the commands that are listed here.

[stevekuznetsov]

Overall the direction here seems reasonable, but I would like to see some more detail on the responsibilities of the controllers and how and where we re-use OCP core functionality versus where we're adding on top or re-implementing.

[jparrill]

Overall the direction here seems reasonable, but I would like to see some more detail on the responsibilities of the controllers and how and where we re-use OCP core functionality versus where we're adding on top or re-implementing.

Agree, in this case we are adapting the controllers of the ETCD Operator in our code because we don't want to get the whole ETCD Operator as part of the ControlPlane (for scalability reasons) (apart that in their case, this is using a separated CRD). So the responsibility relies on us and we can follow the direction they followed.

[jparrill]

After a team call discussion we decided to go through a couple of spikes regarding OADP and vol-synk from ACM/MCE. I will update the design afterwards.

[openshift-bot]

Inactive enhancement proposals go stale after 28d of inactivity.

See https://github.com/openshift/enhancements#life-cycle for details.

Mark the proposal as fresh by commenting /remove-lifecycle stale.
Stale proposals rot after an additional 7d of inactivity and eventually close.
Exclude this proposal from closing by commenting /lifecycle frozen.

If this proposal is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale enhancement proposals rot after 7d of inactivity.

See https://github.com/openshift/enhancements#life-cycle for details.

Mark the proposal as fresh by commenting /remove-lifecycle rotten.
Rotten proposals close after an additional 7d of inactivity.
Exclude this proposal from closing by commenting /lifecycle frozen.

If this proposal is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[jparrill]

The decision over this enhancement is basically cover the functionality with OADP. We will develop the internals in a document instead of en enhancement, which IMHO makes more sense.

[dhellmann]

(automated message) This pull request is closed with lifecycle/rotten. The associated Jira ticket, HOSTEDCP-1370, has status "Closed, Obsolete". Should the PR be reopened, updated, and merged? If not, removing the lifecycle/rotten label will tell this bot to ignore it in the future.

[dhellmann]

(automated message) This pull request is closed with lifecycle/rotten. The associated Jira ticket, HOSTEDCP-1370, has status "Closed, Obsolete". Should the PR be reopened, updated, and merged? If not, removing the lifecycle/rotten label will tell this bot to ignore it in the future.