-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design for Velero uploader configuration integration and extensibility #7005
Design for Velero uploader configuration integration and extensibility #7005
Conversation
Codecov Report
@@ Coverage Diff @@
## main #7005 +/- ##
==========================================
+ Coverage 61.03% 61.05% +0.01%
==========================================
Files 251 251
Lines 26837 26846 +9
==========================================
+ Hits 16381 16390 +9
Misses 9303 9303
Partials 1153 1153 |
c402333
to
c03a96c
Compare
c03a96c
to
9bca1b8
Compare
``` | ||
|
||
The process is as follows: Users pass the ParallelFilesUpload parameter and its value through the Velero CLI. This parameter and its value are stored as a sub-option within UploaderConfig and then placed into the Backup CR. When users perform file-system level backups, UploaderConfig is passed to the PodVolumeBackup CR. When users use the Data-mover for backups, it is passed to the DataUpload CR. Each respective controller within the CRs calls the uploader, and the ParallelFilesUpload from UploaderConfig in CRs is passed to the uploader. When the uploader subsequently calls the Kopia API, it can use the ParallelFilesUpload to set the MaxParallelFileReads parameter. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's mention the situation for Restic here --- this option is not supported by Restic uploader.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
modified
} | ||
``` | ||
|
||
The process is as follows: Users pass the ParallelFilesUpload parameter and its value through the Velero CLI. This parameter and its value are stored as a sub-option within UploaderConfig and then placed into the Backup CR. When users perform file-system level backups, UploaderConfig is passed to the PodVolumeBackup CR. When users use the Data-mover for backups, it is passed to the DataUpload CR. Each respective controller within the CRs calls the uploader, and the ParallelFilesUpload from UploaderConfig in CRs is passed to the uploader. When the uploader subsequently calls the Kopia API, it can use the ParallelFilesUpload to set the MaxParallelFileReads parameter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
file-system level backups -> file system backups. file system backup is a particular term of Velero, let's make it consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
modified
``` | ||
|
||
### Configuration Propagated to Different CRDs | ||
The configuration specified in `UploaderConfig` needs to be effective for both file-system level backups and data-mover backups. Therefore, the `UploaderConfig` field value from the backup CRD should be propagated to `PodVolumeBackup` and `DataUpload` CRDs: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
file-system level backups -> file system backups. file system backup is a particular term of Velero, let's make it consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
modified
``` | ||
|
||
### Configuration Propagated to Different CRDs | ||
The configuration specified in `UploaderConfig` needs to be effective for both file-system level backups and data-mover backups. Therefore, the `UploaderConfig` field value from the backup CRD should be propagated to `PodVolumeBackup` and `DataUpload` CRDs: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add Restore the UploaderConfig to Restore CRD as well and propagate it to PodVolumeRestore and DataDownload CRDs, considering an option may be for restores
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated
9bca1b8
to
b9a37ee
Compare
Signed-off-by: Ming <mqiu@vmware.com>
b9a37ee
to
a86b394
Compare
below the sub-option `ParallelFilesUpload` is added into UploaderConfig: | ||
|
||
```go | ||
type UploaderConfig struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it safe to assume most attributes to be added to this configuration, applies to both backup and restore workflow?
i.e. there won't be an attribute xyz
that only makes sense in backup but not restore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think here the plan is to have the backup options and restore options mingling in this UploaderConfig struct, so that we don't need to introduce separate struct for backups and restores.
Actually, quite lots of options are for either backups or restores, not for the both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it does not matter even if we have one attribute 'xyz' both make sense in backup and restore.
As the command created by Velero CLI could not take effect both in backup and restore at the same time. The command may backup or restore, the UploaderConfig will store in Backup
or Restore
accordingly
|
||
```go | ||
type UploaderConfig struct { | ||
ParallelFilesUpload int `json:"parallelFilesUpload,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it is left unset the value will be 0
, does 0
has the same meaning as 1
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0
means use the default policy and treaded as not assigned value if the user specifies with 0
.
it's different from 1
below are the key steps that should be added to support this new feature. | ||
|
||
#### Velero CLI | ||
The Velero CLI will support a `--parallel-files-upload` flag, allowing users to set the `ParallelFilesUpload` value when creating backups. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it only for backup?
We should be careful with the doc to explain this parm only impacts the flow when the files are handled by uploader
like kopia
and restic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it's only for backup. and in --parallel-files-upload
flag usage clearly states that it can only be used for backups using kopia
type of uploader
This design looks good to me. I am guessing that we can add a boolean field called "sparseRestore" to implement #6664. If you agree, how do you want to proceed with the work? Do you want to update this proposal itself with the new field or perhaps check this in first and then write a different proposal? |
@draghuram > This design looks good to me. I am guessing that we can add a boolean field called "sparseRestore" to implement #6664. If you agree, how do you want to proceed with the work? Do you want to update this proposal itself with the new field or perhaps check this in first and then write a different proposal?
once this proposal is merged, I think you could add a new sub-section in this design about the configuration |
Thank you for contributing to Velero!
Please add a summary of your change
Does your change fix a particular issue?
Fixes #(issue)
#6607
Please indicate you've done the following:
/kind changelog-not-required
as a comment on this pull request.site/content/docs/main
.