-
Notifications
You must be signed in to change notification settings - Fork 617
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
CannotPullContainerError/ASM error message enhancements #4181
Conversation
5dd5027
to
65a2859
Compare
Improve CannotPullContainerError message
0a68d36
to
ffcd9bf
Compare
ffcd9bf
to
dc51281
Compare
agent/vendor/github.com/aws/amazon-ecs-agent/ecs-agent/api/errors/error_messages.go
Outdated
Show resolved
Hide resolved
470ee7c
to
ec5361e
Compare
ec5361e
to
5d7418b
Compare
* CannotPullContainerError: cleanup, renaming * ASM error: do not use added errormessages code - match on AWS SDK error directly, drop tracing prefix, fix/add more unit tests
Thanks for this change! Let's please add details about any manual tests performed to validate this changes. The new error messages seen in |
316f62e
to
a4ee7f4
Compare
@@ -1606,6 +1607,8 @@ func (engine *DockerTaskEngine) pullAndUpdateContainerReference(task *apitask.Ta | |||
|
|||
findCachedImage := false | |||
if !pullSucceeded { | |||
// Extend error message | |||
metadata.Error = apierrormsgs.AugmentNamedErrMsg(metadata.Error) |
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 seems like this is the only place where AugmentNamedErrMsg
is used? Is there some plan to add more errors to this?
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.
At this time, there are no plans to continue updating other messages using AugmentNamedErrMsg
. This function was implemented and applied to specifically for the scenarios we are trying to address. If future requirements necessitate similar enhancements for additional error messages, we can consider extending its usage then.
} | ||
|
||
// A map associating DockerErrorType with parser functions. | ||
var errorParsers = map[DockerErrorType]func(string) (DockerError, error){ |
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.
why is this a map? I don't see it's keys being used anywhere?
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.
You are right, not used right now. I did it just for symmetry with formatters and (arguably) slightly better readability of code. We can change it if you feel strongly. Let me know what you think. Thanks.
|
||
// An interface that provides means to reconstruct Named Errors. This is | ||
// used during error message augmentation process. | ||
type AugmentableNamedError interface { |
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'm not sure I fully understand the point of this interface. Why not just have a function in the errormessages
package that can take in a named error, augment the message if it can (using the available parser functions), and then return it? Why the need to create an interface and add this function to particular named errors?
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.
Excellent suggestion, Thanks. I considered this approach too. Once slight complication is that we would need to somehow rebuild NamedError
and return it. This creates dependencies on all modules that would need to be imported to bring error into scope.
The decision to create an interface was made to improve modularity. By doing this, we avoid the need to import all the specific error types into the errormessages
package. This design allows each error type to implement the interface independently, keeping the errormessages
package clean and free from dependencies. I felt this approach makes the codebase more maintainable and flexible, allowing new error types to be augmented without modifying the main parsing driver - AugmentNamedErrMsg
and AugmentMessage
function.
If you think it is an overkill - we can certainly change it, I am fine doing it either way.
Summary
This change does a few things:
CannotPullContainerError
, spefically the missing ECR pull permissions, broken or non-existent image repo url .asm_test.go
implementation to usegomock
Implementation details
error_messages.go
engine.pullAndUpdateContainerReference
we use new functionality to attempt to update error message when image pull failed due CannotPullContainerErrorTesting
error_messages_test.go
docker_task_engine_test.go
to capture augmented message.New tests cover the changes:
yes
Manual testing steps and describe-tasks outputs
ecr:BatchGetImage
from policy attached to task execution roleecr:BatchGetImage
from policy attached to task ec2 instance roleDescription for the changelog
Enhancement: update CannotPullContainerError error messages
Licensing
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.