-
Notifications
You must be signed in to change notification settings - Fork 20
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
BB-673 Fix retry for replication and notification #2633
Conversation
Hello nicolas2bert,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
* @param {Object} notifConfig.queueProcessor.retry - Object keyed by location type | ||
* (e.g., `aws_s3`, `azure`, `gcp`, `scality`), defining retry parameters for each location type. | ||
* @param {number} notifConfig.queueProcessor.retry.<locationType>.maxRetries - Maximum number of retry attempts. | ||
* @param {number} notifConfig.queueProcessor.retry.<locationType>.timeoutS - Timeout in seconds before giving up. | ||
* @param {Object} notifConfig.queueProcessor.retry.<locationType>.backoff - Exponential backoff configuration. | ||
* @param {number} notifConfig.queueProcessor.retry.<locationType>.backoff.min - Minimum backoff interval in ms. | ||
* @param {number} notifConfig.queueProcessor.retry.<locationType>.backoff.max - Maximum backoff interval in ms. | ||
* @param {number} notifConfig.queueProcessor.retry.<locationType>.backoff.jitter - Jitter factor. | ||
* @param {number} notifConfig.queueProcessor.retry.<locationType>.backoff.factor - Exponential backoff multiplier. |
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.
* @param {Object} notifConfig.queueProcessor.retry - Object keyed by location type | |
* (e.g., `aws_s3`, `azure`, `gcp`, `scality`), defining retry parameters for each location type. | |
* @param {number} notifConfig.queueProcessor.retry.<locationType>.maxRetries - Maximum number of retry attempts. | |
* @param {number} notifConfig.queueProcessor.retry.<locationType>.timeoutS - Timeout in seconds before giving up. | |
* @param {Object} notifConfig.queueProcessor.retry.<locationType>.backoff - Exponential backoff configuration. | |
* @param {number} notifConfig.queueProcessor.retry.<locationType>.backoff.min - Minimum backoff interval in ms. | |
* @param {number} notifConfig.queueProcessor.retry.<locationType>.backoff.max - Maximum backoff interval in ms. | |
* @param {number} notifConfig.queueProcessor.retry.<locationType>.backoff.jitter - Jitter factor. | |
* @param {number} notifConfig.queueProcessor.retry.<locationType>.backoff.factor - Exponential backoff multiplier. | |
* @param {Object} repConfig.queueProcessor.retry - Object keyed by location type | |
* (e.g., `aws_s3`, `azure`, `gcp`, `scality`), defining retry parameters for each location type. | |
* @param {number} repConfig.queueProcessor.retry.<locationType>.maxRetries - Maximum number of retry attempts. | |
* @param {number} repConfig.queueProcessor.retry.<locationType>.timeoutS - Timeout in seconds before giving up. | |
* @param {Object} repConfig.queueProcessor.retry.<locationType>.backoff - Exponential backoff configuration. | |
* @param {number} repConfig.queueProcessor.retry.<locationType>.backoff.min - Minimum backoff interval in ms. | |
* @param {number} repConfig.queueProcessor.retry.<locationType>.backoff.max - Maximum backoff interval in ms. | |
* @param {number} repConfig.queueProcessor.retry.<locationType>.backoff.jitter - Jitter factor. | |
* @param {number} repConfig.queueProcessor.retry.<locationType>.backoff.factor - Exponential backoff multiplier. |
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.
thanks, good catch. As you had guessed I copied/pasted it from the notification QueueProcessor.
Request integration branchesWaiting for integration branch creation to be requested by the user. To request integration branches, please comment on this pull request with the following command:
Alternatively, the |
timeoutS: | ||
rspState.repConfig.replicationStatusProcessor.retryTimeoutS, | ||
}); | ||
super(rspState.repConfig.replicationStatusProcessor.retry); |
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.
retryParams are already on line 34, what is the point of this change?
(a cleanup may be good indeed, to pass the retryParams through the constructor instead of overriding them: but this is not what you are implementing here, and would change most backbeat tasks)
super(rspState.repConfig.replicationStatusProcessor.retry); | |
super(); |
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, that was my point about passing it in the constructor. I overlooked the unnecessary redundancy and will remove this.retryParams = this.repConfig.replicationStatusProcessor.retry;
Thanks.
retryTimeoutS, skipSourceBucketCreation, log } = params; | ||
super({ timeoutS: retryTimeoutS }); | ||
repConfig, skipSourceBucketCreation, log } = params; | ||
super(repConfig.queueProcessor.retry.scality); |
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.
replication may target other backends (not just scality), and each "kind" (scality, aws, azure...) has its own retry params:
- seems weird to single-out the 'scality' retry params here
- due to these target-specific params, are the (proper) retry params not already used deeper in the code, when doing the actual replication, i.e. is it really needed to set it here?
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.
SetupReplication class fully configures CRR replication by performing all the housekeeping tasks needed for it to work (bucket existence/creation, versioning, IAM roles/policies, and the S3 replication configuration).
For internal replication (CRR), the type introduced is "scality".
super({ | ||
timeoutS: qpState.repConfig.queueProcessor.retryTimeoutS, | ||
}); | ||
super(); |
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.
should retryParams
assignment be moved from line 43-53 to constructor param, then?
26f5bae
to
722a572
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files
... and 5 files with indirect coverage changes
@@ Coverage Diff @@
## development/9.0 #2633 +/- ##
===================================================
+ Coverage 72.99% 73.39% +0.40%
===================================================
Files 201 201
Lines 13374 13373 -1
===================================================
+ Hits 9762 9815 +53
+ Misses 3602 3548 -54
Partials 10 10
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
if (this.destConfig && this.destConfig.bootstrapList) { | ||
const destination = this.destConfig.bootstrapList | ||
.find(endpoint => endpoint.site === this.site) || {}; | ||
this.destType = destination.type; |
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.
Removing this.destType
since it does not seem to be used anywhere.
@bert-e approve |
Integration data createdI have created the integration data for the additional destination branches.
The following branches will NOT be impacted:
You can set option
The following options are set: approve |
History mismatchMerge commit #8118c88d5262b48c3d3dafb9bf434121801b0eb9 on the integration branch It is likely due to a rebase of the branch Please use the The following options are set: approve |
722a572
to
6d87c9f
Compare
History mismatchMerge commit #722a5725b6cafcbbad1e641d5145f4abf8cb8708 on the integration branch It is likely due to a rebase of the branch Please use the The following options are set: approve |
@bert-e reset |
Reset completeI have successfully deleted this pull request's integration branches. The following options are set: approve |
Integration data createdI have created the integration data for the additional destination branches.
The following branches will NOT be impacted:
You can set option
The following options are set: approve |
I have successfully merged the changeset of this pull request
The following branches have NOT changed:
Please check the status of the associated issue BB-673. Goodbye nicolas2bert. The following options are set: approve |
No description provided.