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

Feature/container: new Container type & unit tests #340

Merged
merged 13 commits into from
Aug 9, 2018
Merged

Conversation

ilgooz
Copy link
Contributor

@ilgooz ilgooz commented Aug 5, 2018

closes #283.
related with #337, #268.

  • It would be much simpler to review this PR by reviewing each commit individually.
  • Run tests with integration tag to enable integration tests: go test -tags=integration
  • new dockertest package provided within this PR is used while unit testing of container package and will be used by its consumer packages to mock Docker API.
  • Container type is introduced.
  • Minor improvements done on the container package.
  • All contexts replaced with WithTimeout contexts.

@ilgooz ilgooz changed the title Feature/container Feature/container: new Container type & unit tests Aug 5, 2018
@ilgooz ilgooz added this to the v1.1.0 milestone Aug 5, 2018
@ilgooz ilgooz force-pushed the feature/container branch 6 times, most recently from 7a21585 to a6edac2 Compare August 7, 2018 09:32
@ilgooz ilgooz force-pushed the feature/container branch 3 times, most recently from 799e332 to 6a04217 Compare August 7, 2018 14:11
@ilgooz ilgooz requested review from antho1404, NicolasMahe and a team and removed request for antho1404 August 7, 2018 14:16
@ilgooz ilgooz requested review from antho1404 and removed request for antho1404 August 7, 2018 14:19
@NicolasMahe
Copy link
Member

I will review first thing tomorrow morning ;)

@ilgooz If you want to start another dev from this branch before it's merged, you can start a new branch from your last commit ;)

Copy link
Member

@NicolasMahe NicolasMahe left a comment

Choose a reason for hiding this comment

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

Impressive PR 👍 one typo away from approval!

serviceInspectWithRaw chan serviceInspectWithRawResponse
serviceRemove chan serviceRemoveResponse
serviceLogs chan serviceLogsResponse
contanerInspect chan containerInspectResponse
Copy link
Member

Choose a reason for hiding this comment

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

typo on contanerInspect. Should be containerInspect.
This typo is also at 3 other places.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

err := createSwarmIfNeeded(client)
assert.Nil(t, err)
}

// TODO: this tests break other tests on my machine
Copy link
Member

Choose a reason for hiding this comment

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

Let's remove completely this file. I don't think we really need integration test on the createSwarm functionality.
@antho1404 what do you think?

Copy link
Member

Choose a reason for hiding this comment

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

Why would you want to remove it ? if the test is ok let's keep it, after I agree swarm tests are not absolutely necessary but I think it's still really good to keep these tests except if there is a good reason to remove them

Copy link
Member

@NicolasMahe NicolasMahe Aug 8, 2018

Choose a reason for hiding this comment

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

They are already commented out....
Let's remove the pollution.

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

my bad you're right

Copy link
Contributor Author

@ilgooz ilgooz Aug 8, 2018

Choose a reason for hiding this comment

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

I'm removing core/container/client_test.go file. @antho1404 are you ok with this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i think we should refactor our integration tests too #351. So maybe we should keep this one as a reminder to create an integration test from it.

}
containers, err := client.ContainerList(context.Background(), types.ContainerListOptions{
ctx, cancel = context.WithTimeout(context.Background(), c.callTimeout)
defer cancel()
Copy link
Member

Choose a reason for hiding this comment

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

is it ok to assign cancel multiple time and call it using defer?
Is defer will really execute the 2 cancel or the last cancel 2 times?

Copy link
Contributor Author

@ilgooz ilgooz Aug 8, 2018

Choose a reason for hiding this comment

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

yes it is ok. please see: https://play.golang.org/p/UeNDuSXbZz7

if err != nil {
log.Fatal(err)
}
defaultContainer = c
Copy link
Member

Choose a reason for hiding this comment

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

I think this is to initialize a defaultContainer in the CLI but this file is the file for the command mesg-core service init so that might not make sense to put it here but maybe more in the utils where it's used

Also if it's only used one time in the service/utils#buildDockerImage why not initialize it in this function directly

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We are going to remove these lines after service package refactored. *Container will be initialized once and stored in the *Service struct. I don't mind where to put this temporary code, want me to move to utils for now?

Copy link
Member

Choose a reason for hiding this comment

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

yes that would be good, I'm afraid to forget it here because it's not really related to this command

err := createSwarmIfNeeded(client)
assert.Nil(t, err)
}

// TODO: this tests break other tests on my machine
Copy link
Member

Choose a reason for hiding this comment

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

my bad you're right

}

// LastContainerList returns a channel that receives call arguments of last *Client.ContainerList call.
func (t *Testing) LastContainerList() <-chan ContainerListRequest {
Copy link
Member

Choose a reason for hiding this comment

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

I don't like much the naming with Last but i'm definitely not against it

"github.com/mesg-foundation/core/container"
)

var defaultContainer *container.Container
Copy link
Member

Choose a reason for hiding this comment

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

Isn't it better to create an instance every time we need it instead of creating it an init function ?
It would be good to avoid init functions that save a state.
This container is totally stateless so we can re-create it all the time and it will not change anything except some memory/cpu optimization but that are negligible for these features

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After daemon refactored, *Container will be initialized only once and stored in the *Daemon struct. Until the refactor we have to initialize a Container type and store it in the package level to be able to use it. I won't recommend -also don't like- initializing Container every time it's needed because it makes additional Docker API calls in the initialization time. Please see here.

Copy link
Member

Choose a reason for hiding this comment

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

ok let's keep it like that for now, and for the initialization of the container every time, you're right with the docker api calls even if we could add a singleton on that or some stuff like that but we will think about this kind of optimization later
So this is ok now :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I directly changed the corresponding commit from the history as you liked. This way we'll not see an irrelevant code in the init.go file.

var defaultContainer *container.Container

func init() {
c, err := container.New()
Copy link
Member

Choose a reason for hiding this comment

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

same remark here, do we really need a state and an init function ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, until we refactor service. This is just a temporary solution.

* move integration tests to their own files called with _integration_test.go
* add dockertest package to easily test methods that calls Docker API
* add more unit tests to container_test.go, build_test.go, network_test.go
* extend dockertest API accordingly
@NicolasMahe NicolasMahe removed this from the v1.1.0 milestone Aug 9, 2018
Copy link
Member

@NicolasMahe NicolasMahe left a comment

Choose a reason for hiding this comment

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

👍 Good to merge 🌮

@antho1404 antho1404 merged commit 8c48040 into dev Aug 9, 2018
@antho1404 antho1404 deleted the feature/container branch August 9, 2018 10:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

convert to unit tests
3 participants