Running nimbusapp to upgrade sv 5.1 to 5.1.1 gave extra text

[msteffensen19]

When I ran a nimbusapp (1.2.2) command to update my SV server from 5.1 to 5.1.1 I got the following (Do we need all the extra text on Usage, Options, etc.?):

[demo@nimbusserver ~]$ nimbusapp sv:5.1.1 up
Validate and view the Compose file.

Usage: config [options]

Options:
--resolve-image-digests Pin image tags to digests.
-q, --quiet Only validate the configuration, don't print
anything.
--services Print the service names, one per line.
--volumes Print the volume names, one per line.
Validate and view the Compose file.

Usage: config [options]

Options:
--resolve-image-digests Pin image tags to digests.
-q, --quiet Only validate the configuration, don't print
anything.
--services Print the service names, one per line.
--volumes Print the volume names, one per line.
Validate and view the Compose file.

Usage: config [options]

Options:
--resolve-image-digests Pin image tags to digests.
-q, --quiet Only validate the configuration, don't print
anything.
--services Print the service names, one per line.
--volumes Print the volume names, one per line.
Validate and view the Compose file.

Usage: config [options]

Options:
--resolve-image-digests Pin image tags to digests.
-q, --quiet Only validate the configuration, don't print
anything.
--services Print the service names, one per line.
--volumes Print the volume names, one per line.

This action will cause one or more of your containers to be DELETED and RECREATED.

Recreating containers is normal when changing their configuration, such as image, tag and ports.

You may wish to use `nimbusapp ... start' to start your existing containers.

The following containers will be recreated:

• /sv-db
• /sv-lab-server
• /sv-server
• /sv-svm

Recreate the listed containers? [y/n] y
Starting sv-db ... done
Starting sv-svm ... done
Starting sv-lab-server ... done
Starting sv-server ... done
[demo@nimbusserver ~]$

[jasoncorlett]

Thanks @msteffensen19 , could you provide output from the following commands:

1. docker version
2. docker-compose version
3. docker-app version
4. nimbusapp version

[msteffensen19]

1. Docker version
   Client:
   Version: 18.09.6
   API version: 1.39
   Go version: go1.10.8
   Git commit: 481bc77156
   Built: Sat May 4 02:34:58 2019
   OS/Arch: linux/amd64
   Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.6
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 02:02:43 2019
OS/Arch: linux/amd64
Experimental: false

Client:
Version: 18.09.6
API version: 1.39
Go version: go1.10.8
Git commit: 481bc77156
Built: Sat May 4 02:34:58 2019
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.6
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 481bc77
Built: Sat May 4 02:02:43 2019
OS/Arch: linux/amd64
Experimental: false
[demo@nimbusserver ~]$ docker-compose version
docker-compose version 1.22.0, build f46880f
docker-py version: 3.5.0
CPython version: 2.7.5
OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017

3. docker-app version
   Version: v0.6.0
   Git commit: 9f9c6680
   Built: Thu Oct 4 13:30:33 2018
   OS/Arch: linux/amd64
   Experimental: off
   Renderers: none

4. nimbusapp version
   nimbusapp version 1.2.2
   Released on 2019-09-04

5. docker-compose version

[jasoncorlett]

@msteffensen19 the output of docker-compose version above seems to have been cut off

[msteffensen19]

5. docker-compose - version
   docker-compose version 1.22.0, build f46880f

[jasoncorlett]

@msteffensen19 We use a feature of compose introduced in 1.23.0 to check if containers will be recreated. Upgrading to the most recent version of compose should resolve the issue.

[jhrabi]

@jasoncorlett Should we be checking for compose versions?

[jasoncorlett]

@jhrabi Yes, we should probably check both docker-compose and docker-app versions