2017-03-26 02:23:24 -04:00
|
|
|
package stack
|
|
|
|
|
|
|
|
import (
|
|
|
|
"errors"
|
2017-06-09 11:58:42 -04:00
|
|
|
"io/ioutil"
|
2017-03-26 02:23:24 -04:00
|
|
|
"strings"
|
|
|
|
"testing"
|
|
|
|
|
2017-08-21 16:30:09 -04:00
|
|
|
"github.com/docker/cli/internal/test"
|
2018-03-05 18:53:52 -05:00
|
|
|
"github.com/gotestyourself/gotestyourself/assert"
|
|
|
|
is "github.com/gotestyourself/gotestyourself/assert/cmp"
|
2017-03-26 02:23:24 -04:00
|
|
|
)
|
|
|
|
|
2017-07-12 11:37:35 -04:00
|
|
|
func fakeClientForRemoveStackTest(version string) *fakeClient {
|
2017-03-26 02:23:24 -04:00
|
|
|
allServices := []string{
|
|
|
|
objectName("foo", "service1"),
|
|
|
|
objectName("foo", "service2"),
|
|
|
|
objectName("bar", "service1"),
|
|
|
|
objectName("bar", "service2"),
|
|
|
|
}
|
|
|
|
allNetworks := []string{
|
|
|
|
objectName("foo", "network1"),
|
|
|
|
objectName("bar", "network1"),
|
|
|
|
}
|
|
|
|
allSecrets := []string{
|
|
|
|
objectName("foo", "secret1"),
|
|
|
|
objectName("foo", "secret2"),
|
|
|
|
objectName("bar", "secret1"),
|
|
|
|
}
|
2017-05-26 20:30:33 -04:00
|
|
|
allConfigs := []string{
|
|
|
|
objectName("foo", "config1"),
|
|
|
|
objectName("foo", "config2"),
|
|
|
|
objectName("bar", "config1"),
|
|
|
|
}
|
2017-07-12 11:37:35 -04:00
|
|
|
return &fakeClient{
|
|
|
|
version: version,
|
2017-03-26 02:23:24 -04:00
|
|
|
services: allServices,
|
|
|
|
networks: allNetworks,
|
|
|
|
secrets: allSecrets,
|
2017-05-26 20:30:33 -04:00
|
|
|
configs: allConfigs,
|
2017-03-26 02:23:24 -04:00
|
|
|
}
|
2017-07-12 11:37:35 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestRemoveStackVersion124DoesNotRemoveConfigsOrSecrets(t *testing.T) {
|
|
|
|
client := fakeClientForRemoveStackTest("1.24")
|
|
|
|
cmd := newRemoveCommand(test.NewFakeCli(client))
|
2017-03-26 02:23:24 -04:00
|
|
|
cmd.SetArgs([]string{"foo", "bar"})
|
|
|
|
|
2018-03-06 15:13:00 -05:00
|
|
|
assert.NilError(t, cmd.Execute())
|
2018-03-05 18:53:52 -05:00
|
|
|
assert.Check(t, is.DeepEqual(buildObjectIDs(client.services), client.removedServices))
|
|
|
|
assert.Check(t, is.DeepEqual(buildObjectIDs(client.networks), client.removedNetworks))
|
|
|
|
assert.Check(t, is.Len(client.removedSecrets, 0))
|
|
|
|
assert.Check(t, is.Len(client.removedConfigs, 0))
|
2017-07-12 11:37:35 -04:00
|
|
|
}
|
Don't attempt to remove unsupported resources on older daemon
When running `docker stack rm <some stack>` against an older daemon,
a warning was printed for "configs" being ignored;
WARNING: ignoring "configs" (requires API version 1.30, but the Docker daemon API version is 1.26)
Given that an old daemon cannot _have_ configs, there should not be
a need to warn, or _attempt_ to remove these resources.
This patch removes the warning, and skips fetching (and removing)
configs.
A check if _secrets_ are supported by the daemon is also added,
given that this would result in an error when attempted against
an older (pre 1.13) daemon.
There is one situation where this could lead to secrets or
configs being left behind; if the client is connecting to a
daemon that _does_ support secrets, configs, but the API version
is overridden using `DOCKER_API_VERSION`, no warning is printed,
and secrets and configs are not attempted to be removed.
Given that `DOCKER_API_VERSION` is regarded a feature for
debugging / "power users", it should be ok to ignore this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2017-06-30 20:00:16 -04:00
|
|
|
|
2017-07-12 11:37:35 -04:00
|
|
|
func TestRemoveStackVersion125DoesNotRemoveConfigs(t *testing.T) {
|
|
|
|
client := fakeClientForRemoveStackTest("1.25")
|
|
|
|
cmd := newRemoveCommand(test.NewFakeCli(client))
|
Don't attempt to remove unsupported resources on older daemon
When running `docker stack rm <some stack>` against an older daemon,
a warning was printed for "configs" being ignored;
WARNING: ignoring "configs" (requires API version 1.30, but the Docker daemon API version is 1.26)
Given that an old daemon cannot _have_ configs, there should not be
a need to warn, or _attempt_ to remove these resources.
This patch removes the warning, and skips fetching (and removing)
configs.
A check if _secrets_ are supported by the daemon is also added,
given that this would result in an error when attempted against
an older (pre 1.13) daemon.
There is one situation where this could lead to secrets or
configs being left behind; if the client is connecting to a
daemon that _does_ support secrets, configs, but the API version
is overridden using `DOCKER_API_VERSION`, no warning is printed,
and secrets and configs are not attempted to be removed.
Given that `DOCKER_API_VERSION` is regarded a feature for
debugging / "power users", it should be ok to ignore this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2017-06-30 20:00:16 -04:00
|
|
|
cmd.SetArgs([]string{"foo", "bar"})
|
|
|
|
|
2018-03-06 15:13:00 -05:00
|
|
|
assert.NilError(t, cmd.Execute())
|
2018-03-05 18:53:52 -05:00
|
|
|
assert.Check(t, is.DeepEqual(buildObjectIDs(client.services), client.removedServices))
|
|
|
|
assert.Check(t, is.DeepEqual(buildObjectIDs(client.networks), client.removedNetworks))
|
|
|
|
assert.Check(t, is.DeepEqual(buildObjectIDs(client.secrets), client.removedSecrets))
|
|
|
|
assert.Check(t, is.Len(client.removedConfigs, 0))
|
2017-07-12 11:37:35 -04:00
|
|
|
}
|
Don't attempt to remove unsupported resources on older daemon
When running `docker stack rm <some stack>` against an older daemon,
a warning was printed for "configs" being ignored;
WARNING: ignoring "configs" (requires API version 1.30, but the Docker daemon API version is 1.26)
Given that an old daemon cannot _have_ configs, there should not be
a need to warn, or _attempt_ to remove these resources.
This patch removes the warning, and skips fetching (and removing)
configs.
A check if _secrets_ are supported by the daemon is also added,
given that this would result in an error when attempted against
an older (pre 1.13) daemon.
There is one situation where this could lead to secrets or
configs being left behind; if the client is connecting to a
daemon that _does_ support secrets, configs, but the API version
is overridden using `DOCKER_API_VERSION`, no warning is printed,
and secrets and configs are not attempted to be removed.
Given that `DOCKER_API_VERSION` is regarded a feature for
debugging / "power users", it should be ok to ignore this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2017-06-30 20:00:16 -04:00
|
|
|
|
2017-07-12 11:37:35 -04:00
|
|
|
func TestRemoveStackVersion130RemovesEverything(t *testing.T) {
|
|
|
|
client := fakeClientForRemoveStackTest("1.30")
|
|
|
|
cmd := newRemoveCommand(test.NewFakeCli(client))
|
Don't attempt to remove unsupported resources on older daemon
When running `docker stack rm <some stack>` against an older daemon,
a warning was printed for "configs" being ignored;
WARNING: ignoring "configs" (requires API version 1.30, but the Docker daemon API version is 1.26)
Given that an old daemon cannot _have_ configs, there should not be
a need to warn, or _attempt_ to remove these resources.
This patch removes the warning, and skips fetching (and removing)
configs.
A check if _secrets_ are supported by the daemon is also added,
given that this would result in an error when attempted against
an older (pre 1.13) daemon.
There is one situation where this could lead to secrets or
configs being left behind; if the client is connecting to a
daemon that _does_ support secrets, configs, but the API version
is overridden using `DOCKER_API_VERSION`, no warning is printed,
and secrets and configs are not attempted to be removed.
Given that `DOCKER_API_VERSION` is regarded a feature for
debugging / "power users", it should be ok to ignore this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2017-06-30 20:00:16 -04:00
|
|
|
cmd.SetArgs([]string{"foo", "bar"})
|
|
|
|
|
2018-03-06 15:13:00 -05:00
|
|
|
assert.NilError(t, cmd.Execute())
|
2018-03-05 18:53:52 -05:00
|
|
|
assert.Check(t, is.DeepEqual(buildObjectIDs(client.services), client.removedServices))
|
|
|
|
assert.Check(t, is.DeepEqual(buildObjectIDs(client.networks), client.removedNetworks))
|
|
|
|
assert.Check(t, is.DeepEqual(buildObjectIDs(client.secrets), client.removedSecrets))
|
|
|
|
assert.Check(t, is.DeepEqual(buildObjectIDs(client.configs), client.removedConfigs))
|
2017-03-26 02:23:24 -04:00
|
|
|
}
|
|
|
|
|
2017-07-05 13:32:54 -04:00
|
|
|
func TestRemoveStackSkipEmpty(t *testing.T) {
|
2017-03-26 02:23:24 -04:00
|
|
|
allServices := []string{objectName("bar", "service1"), objectName("bar", "service2")}
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
allServiceIDs := buildObjectIDs(allServices)
|
2017-03-26 02:23:24 -04:00
|
|
|
|
|
|
|
allNetworks := []string{objectName("bar", "network1")}
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
allNetworkIDs := buildObjectIDs(allNetworks)
|
2017-03-26 02:23:24 -04:00
|
|
|
|
|
|
|
allSecrets := []string{objectName("bar", "secret1")}
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
allSecretIDs := buildObjectIDs(allSecrets)
|
2017-03-26 02:23:24 -04:00
|
|
|
|
2017-05-26 20:30:33 -04:00
|
|
|
allConfigs := []string{objectName("bar", "config1")}
|
|
|
|
allConfigIDs := buildObjectIDs(allConfigs)
|
|
|
|
|
2017-07-05 13:32:54 -04:00
|
|
|
fakeClient := &fakeClient{
|
Don't attempt to remove unsupported resources on older daemon
When running `docker stack rm <some stack>` against an older daemon,
a warning was printed for "configs" being ignored;
WARNING: ignoring "configs" (requires API version 1.30, but the Docker daemon API version is 1.26)
Given that an old daemon cannot _have_ configs, there should not be
a need to warn, or _attempt_ to remove these resources.
This patch removes the warning, and skips fetching (and removing)
configs.
A check if _secrets_ are supported by the daemon is also added,
given that this would result in an error when attempted against
an older (pre 1.13) daemon.
There is one situation where this could lead to secrets or
configs being left behind; if the client is connecting to a
daemon that _does_ support secrets, configs, but the API version
is overridden using `DOCKER_API_VERSION`, no warning is printed,
and secrets and configs are not attempted to be removed.
Given that `DOCKER_API_VERSION` is regarded a feature for
debugging / "power users", it should be ok to ignore this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2017-06-30 20:00:16 -04:00
|
|
|
version: "1.30",
|
2017-03-26 02:23:24 -04:00
|
|
|
services: allServices,
|
|
|
|
networks: allNetworks,
|
|
|
|
secrets: allSecrets,
|
2017-05-26 20:30:33 -04:00
|
|
|
configs: allConfigs,
|
2017-03-26 02:23:24 -04:00
|
|
|
}
|
2017-07-05 14:19:52 -04:00
|
|
|
fakeCli := test.NewFakeCli(fakeClient)
|
2017-07-05 13:32:54 -04:00
|
|
|
cmd := newRemoveCommand(fakeCli)
|
2017-03-26 02:23:24 -04:00
|
|
|
cmd.SetArgs([]string{"foo", "bar"})
|
|
|
|
|
2018-03-06 15:13:00 -05:00
|
|
|
assert.NilError(t, cmd.Execute())
|
2017-08-31 22:42:34 -04:00
|
|
|
expectedList := []string{"Removing service bar_service1",
|
|
|
|
"Removing service bar_service2",
|
|
|
|
"Removing secret bar_secret1",
|
|
|
|
"Removing config bar_config1",
|
|
|
|
"Removing network bar_network1\n",
|
|
|
|
}
|
2018-03-05 18:53:52 -05:00
|
|
|
assert.Check(t, is.Equal(strings.Join(expectedList, "\n"), fakeCli.OutBuffer().String()))
|
|
|
|
assert.Check(t, is.Contains(fakeCli.ErrBuffer().String(), "Nothing found in stack: foo\n"))
|
|
|
|
assert.Check(t, is.DeepEqual(allServiceIDs, fakeClient.removedServices))
|
|
|
|
assert.Check(t, is.DeepEqual(allNetworkIDs, fakeClient.removedNetworks))
|
|
|
|
assert.Check(t, is.DeepEqual(allSecretIDs, fakeClient.removedSecrets))
|
|
|
|
assert.Check(t, is.DeepEqual(allConfigIDs, fakeClient.removedConfigs))
|
2017-03-26 02:23:24 -04:00
|
|
|
}
|
|
|
|
|
2017-06-20 14:00:01 -04:00
|
|
|
func TestRemoveContinueAfterError(t *testing.T) {
|
2017-03-26 02:23:24 -04:00
|
|
|
allServices := []string{objectName("foo", "service1"), objectName("bar", "service1")}
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
allServiceIDs := buildObjectIDs(allServices)
|
2017-03-26 02:23:24 -04:00
|
|
|
|
|
|
|
allNetworks := []string{objectName("foo", "network1"), objectName("bar", "network1")}
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
allNetworkIDs := buildObjectIDs(allNetworks)
|
2017-03-26 02:23:24 -04:00
|
|
|
|
|
|
|
allSecrets := []string{objectName("foo", "secret1"), objectName("bar", "secret1")}
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
allSecretIDs := buildObjectIDs(allSecrets)
|
2017-03-26 02:23:24 -04:00
|
|
|
|
2017-05-26 20:30:33 -04:00
|
|
|
allConfigs := []string{objectName("foo", "config1"), objectName("bar", "config1")}
|
|
|
|
allConfigIDs := buildObjectIDs(allConfigs)
|
|
|
|
|
2017-03-26 02:23:24 -04:00
|
|
|
removedServices := []string{}
|
|
|
|
cli := &fakeClient{
|
Don't attempt to remove unsupported resources on older daemon
When running `docker stack rm <some stack>` against an older daemon,
a warning was printed for "configs" being ignored;
WARNING: ignoring "configs" (requires API version 1.30, but the Docker daemon API version is 1.26)
Given that an old daemon cannot _have_ configs, there should not be
a need to warn, or _attempt_ to remove these resources.
This patch removes the warning, and skips fetching (and removing)
configs.
A check if _secrets_ are supported by the daemon is also added,
given that this would result in an error when attempted against
an older (pre 1.13) daemon.
There is one situation where this could lead to secrets or
configs being left behind; if the client is connecting to a
daemon that _does_ support secrets, configs, but the API version
is overridden using `DOCKER_API_VERSION`, no warning is printed,
and secrets and configs are not attempted to be removed.
Given that `DOCKER_API_VERSION` is regarded a feature for
debugging / "power users", it should be ok to ignore this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2017-06-30 20:00:16 -04:00
|
|
|
version: "1.30",
|
2017-03-26 02:23:24 -04:00
|
|
|
services: allServices,
|
|
|
|
networks: allNetworks,
|
|
|
|
secrets: allSecrets,
|
2017-05-26 20:30:33 -04:00
|
|
|
configs: allConfigs,
|
2017-03-26 02:23:24 -04:00
|
|
|
|
|
|
|
serviceRemoveFunc: func(serviceID string) error {
|
|
|
|
removedServices = append(removedServices, serviceID)
|
|
|
|
|
|
|
|
if strings.Contains(serviceID, "foo") {
|
|
|
|
return errors.New("")
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
},
|
|
|
|
}
|
2017-07-05 14:43:39 -04:00
|
|
|
cmd := newRemoveCommand(test.NewFakeCli(cli))
|
2017-06-09 11:58:42 -04:00
|
|
|
cmd.SetOutput(ioutil.Discard)
|
2017-03-26 02:23:24 -04:00
|
|
|
cmd.SetArgs([]string{"foo", "bar"})
|
|
|
|
|
2018-03-06 15:54:24 -05:00
|
|
|
assert.Error(t, cmd.Execute(), "Failed to remove some resources from stack: foo")
|
2018-03-05 18:53:52 -05:00
|
|
|
assert.Check(t, is.DeepEqual(allServiceIDs, removedServices))
|
|
|
|
assert.Check(t, is.DeepEqual(allNetworkIDs, cli.removedNetworks))
|
|
|
|
assert.Check(t, is.DeepEqual(allSecretIDs, cli.removedSecrets))
|
|
|
|
assert.Check(t, is.DeepEqual(allConfigIDs, cli.removedConfigs))
|
2017-03-26 02:23:24 -04:00
|
|
|
}
|