Backup: init backup, restore and migrate api #377
Conversation
✅ Deploy Preview for kurator-dev ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Xieql <xieqianglong@huawei.com>
Signed-off-by: Xieql <xieqianglong@huawei.com>
Signed-off-by: Xieql <xieqiangong@huawei.com> Signed-off-by: Xieql <xieqianglong@huawei.com>
|
@Xieql: The label(s) In response to this:
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. |
Xieql
changed the title
Xieql
changed the title
Xieql
force-pushed
the
backup-api
branch
3 times, most recently
from
9a1088b
to
bf1435f
Compare
|
/label tide/merge-method-squash |
| // ``` | ||
| // +optional | ||
| // +nullable | ||
| OrderedResources map[string]string `json:"orderedResources,omitempty"` |
There was a problem hiding this comment.
why do we need order for backup
There was a problem hiding this comment.
The resource backup order feature provided by Velero is primarily designed to address scenarios like primary-secondary database configurations.
In such setups, there's an inherent delay in data synchronization or state propagation.
To ensure data consistency and coherence after backup, it's imperative to first back up the 'source' resource upon which others depend, such as the master database, followed by the 'dependent' resources, like the slave database.
see the proposal about orderedResouces in velero: https://github.com/vmware-tanzu/velero/blob/c9e1ade1f7c3b52ac3a38ae853e79a507b33bf95/design/Implemented/backup-resources-order.md
| // If empty, it applies to all resources. | ||
| // +optional | ||
| // +nullable | ||
| IncludedResources []string `json:"includedResources,omitempty"` |
| // ExcludedResources specifies the resources to which will not restore the status. | ||
| // +optional | ||
| // +nullable | ||
| ExcludedResources []string `json:"excludedResources,omitempty"` |
pkg/apis/backups/v1alpha1/util.go
Outdated
| // Clusters determine a set of clusters as destination clusters. | ||
| // The field will only take effect when Fleet is not set. | ||
| // +optional | ||
| Clusters []*corev1.ObjectReference `json:"clusters,omitempty"` |
There was a problem hiding this comment.
so this means clusters will have lower priority
There was a problem hiding this comment.
yes.
Alternatively, we could allow both to coexist and then take the union.
There was a problem hiding this comment.
We can simplify the design by removing the ClusterSelector. If both Fleet and Clusters are specified, we will take their union as the final set of clusters.
ClusterSelector is confusing currently, we can consider reintroducing ClusterSelector in the future if the "selector" need arises.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hzxuzhonghu The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
done |
Signed-off-by: Xieql <xieqianglong@huawei.com>
Signed-off-by: Xieql <xieqianglong@huawei.com>
|
/lgtm |
Signed-off-by: Xieql <xieqianglong@huawei.com>
|
/lgtm |
What type of PR is this?
/kind api-change
/kind design
/kind documentation
What this PR does / why we need it:
add backup sync api
see #374
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: