-
Notifications
You must be signed in to change notification settings - Fork 34
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
Endpoint resource: address failed update scenarios #7
Endpoint resource: address failed update scenarios #7
Conversation
d0b64cb
to
23f4bf9
Compare
terminalCondition = &ackv1alpha1.Condition{ | ||
Type: ackv1alpha1.ConditionTypeTerminal, | ||
} | ||
ko.Status.Conditions = append(ko.Status.Conditions, terminalCondition) | ||
} |
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.
Need an else statement to find the existing terminal condition (if it exists but is set to ConditionFalse)?
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.
Good question!
- If a terminal condition is already set we do not want to override that, see Create Failed terminal condition Feature Group Creating requeue #51-54
- If an error did not occur, this part of code will never execute and the condition will be cleared by this part of code. Hence the else does not exist
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.
The terminal condition may be set, but set to False (that case is not covered on lines 51-54)?
23f4bf9
to
fdaf6dc
Compare
- set RetainAllVariantProperties True
fdaf6dc
to
378b6b0
Compare
// "Request to service failed" means update failed because of ISE and can be retried | ||
(latestStatus != nil && failureReason != nil && lastEndpointConfigForUpdate != nil && | ||
!strings.HasPrefix(*failureReason, FailureReasonInternalServiceErrorPrefix) && | ||
*desiredEndpointConfig != *latestEndpointConfig && |
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.
*desiredEndpointConfig != *latestEndpointConfig is not necessary since you are checking for *desiredEndpointConfig == *lastEndpointConfigForUpdate
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.
good question! both are needed
- FailureReason alone does mean an update failed it can appear because of other reasons(patching/scaling failed)
*desiredEndpointConfig == *lastEndpointConfigForUpdate
only tells us an update was tried withlastEndpointConfigForUpdate
but does not tell us anything if the update was successful or not in the past because it is set if updateEndpoint returns 200 (remember aync operation).- Now, sdkUpdate executes because of change in any field in Spec (like tags/deploymentConfig in future)
1&2 does not guarantee an update Failed. Hence we need to look at *latestEndpointConfigName
to determine if the update was unsuccessful
*desiredEndpointConfig != *latestEndpointConfig
+ *desiredEndpointConfig == *lastEndpointConfigForUpdate
+ FailureReason != nil
indicate that an update is needed, has already been tried and failed.
That being said. I will add this information in the comments because I will forget it as well
terminalCondition = &ackv1alpha1.Condition{ | ||
Type: ackv1alpha1.ConditionTypeTerminal, | ||
} | ||
ko.Status.Conditions = append(ko.Status.Conditions, terminalCondition) | ||
} |
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.
The terminal condition may be set, but set to False (that case is not covered on lines 51-54)?
378b6b0
to
1e07022
Compare
|
Will this conditional check require any additional attention if we start using autogenerated names (I don't think so, but bringing it up so we don't miss it.) |
I don't think so because those would be generated before creation |
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.
Overall looks ok since I have been working with this code and it works as expected.
…8s#7) * endpoint: address failed update scenarios - set RetainAllVariantProperties True - Remove tags field from all the resources because these are only created but we don't have an update path. Tagging experience across ACK is being worked on separately - upgrade to latest code-generator and runtime - v0.0.5 and refactor code to use Delta functionality
…8s#7) * endpoint: address failed update scenarios - set RetainAllVariantProperties True - Remove tags field from all the resources because these are only created but we don't have an update path. Tagging experience across ACK is being worked on separately - upgrade to latest code-generator and runtime - v0.0.5 and refactor code to use Delta functionality
Description of Changes
InService
state with aFailureReason
about the error. Currently, the controller will be stuck in a loop to keep applying the desired endpoint config and keep on failing with a little window for the customer to notice that the update failed because the failure reason only stays if the endpoint is inInService
state and disappears as soon as a new update is applied.Status.LastEndpointConfigNameForUpdate
and only retry an update if theFailureReason
was related to an internal server error or if the user has submitted a new endpointConfigName. Additionally, it sets aACK.Terminal
condition toTrue
and stops reconciling if either of these conditions is not met. User is expected to check thefailureReason
and re-submit the resource with a new endpointConfigName if they wish to update the endpoint.Status.LatestEndpointConfigName
so the user can check the current endpoint config name. This is needed in addition toSpec.endpointConfigName
(desired) for them to have full visibility over the current state of the endpointFailed
state. Once the endpoint is inFailed
state. The only option for the user is to delete and recreate the endpoint.Failed
state as a pre-check-in sdkUpdate and blocks the update. Additionally, it setsACK.Terminal
condition to True so that the controller stops reconciling.pkg/resource/endpoint/custom_*.go
for related implementation details of the above two scenariosCode-generator is now adding description to the fields in CRDs and hence the PR looks long but actual changes which need to be reviewed closely are listed above
Testing
aws-controllers-k8s/community#730
Dependent PR: aws-controllers-k8s/code-generator#34