Skip to content
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

task engine: centralize getting docker ID, check it's not blank #2608

Merged
merged 2 commits into from
Sep 3, 2020

Conversation

sparrc
Copy link
Contributor

@sparrc sparrc commented Sep 3, 2020

Summary

In 5 different places we were mapping from our internal apicontainer object to the dockercontainer object in order to obtain the docker ID, though never in exactly the same way. This centralizes it into a single function (getDockerID) that also tries to first just grab the dockerID from the apicontainer object if it exists.

Will also fallback to the DockerName attribute on the dockercontainer obj if DockerID doesnt exist.

New tests cover the changes: no

Description for the changelog

Licensing

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

func (engine *DockerTaskEngine) inspectContainerByName(taskArn, containerName string) (*types.ContainerJSON, error) {
containers, ok := engine.state.ContainerMapByArn(taskArn)
if !ok {
return nil, errors.New("engine: failed to find the pause container, no containers in the task")
Copy link
Contributor Author

@sparrc sparrc Sep 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also fixes this inaccurate error message, seems like maybe this function was originally written to only inspect the pause container.

@sparrc sparrc force-pushed the more-resilient-docker-id branch 2 times, most recently from e87342c to 5d562ce Compare September 3, 2020 00:22
pauseContainer, ok := containers[containerName]
if !ok {
return nil, errors.New("engine: failed to find the pause container")
func (engine *DockerTaskEngine) inspectContainer(taskArn, container *apicontainer.Container) (*types.ContainerJSON, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

taskArn should be a string?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

}
containerMap, ok := engine.state.ContainerMapByArn(task.Arn)
if !ok {
return "", errors.Errorf("Container name=%s belongs to unrecognized task taskArn=%s", container.Name, task.Arn)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

error message should start with lower case, same below

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

if !ok {
return nil, errors.New("engine: failed to find the pause container")
func (engine *DockerTaskEngine) inspectContainer(taskArn, container *apicontainer.Container) (*types.ContainerJSON, error) {
dockerID, err := engine.getDockerID(task, container)
Copy link
Contributor

@angelcar angelcar Sep 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this one. I think this is misleading. getDockerID sometimes returns name?

Also, I am not certain that the logic isn't changed here. This code used to retrieve the container using the name of the container, but now by invoking getDockerID it will try to first attempt to get the docker runtime id. So, if pauseContainer also has a runtime id (now or in the future) this will break right?

Copy link
Contributor Author

@sparrc sparrc Sep 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it's true, getDockerID could sometimes return the name, I'm not sure how to call the function to indicate that.

You are correct that this would change to mostly calling the docker API using the docker runtime ID. The docker API f is very liberal in what it accepts as a "docker id". You can pass in the name, full runtime id, short name, or short runtime ID. That is part of why I wanted to make this change, so that it is more standardized on using a single type of "docker id".

Copy link
Contributor Author

@sparrc sparrc Sep 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for example, previous to this PR we were called RemoveContainer using DockerName, but if you look at the implementation it is referred to as DockerID in our code, and then ultimately containerID in the docker client codebase:

func (dg *dockerGoClient) RemoveContainer(ctx context.Context, dockerID string, timeout time.Duration) error {

ContainerRemove(ctx context.Context, containerID string, options types.ContainerRemoveOptions) error

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I'd prefer to either only use DockerConainer everywhere or to add these attributes directly to the container struct. But that's a much larger change. I guess this is a good iteration

@sparrc sparrc force-pushed the more-resilient-docker-id branch 2 times, most recently from 3ddd3ab to e865e9c Compare September 3, 2020 04:07
@sparrc sparrc added the bot/test label Sep 3, 2020
@sparrc sparrc added the bot/test label Sep 3, 2020
@sparrc sparrc changed the title Centralize DockerID getting, make it more resilient task engine: centralize getting docker ID, check it's not blank Sep 3, 2020
@sparrc sparrc merged commit 4d8115f into aws:dev Sep 3, 2020
@sparrc sparrc deleted the more-resilient-docker-id branch September 3, 2020 15:54
@mssrivas mssrivas added this to the 1.44.4 milestone Sep 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants