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

"Operating system not supported" #382

Closed
mikesir87 opened this Issue Sep 16, 2018 · 8 comments

Comments

Projects
None yet
3 participants
@mikesir87

mikesir87 commented Sep 16, 2018

Description

When pulling the docker app bundle, getting an error indicating "operating system not supported". I used the exact steps below and pushed to a repo at mikesir87/dockerappbug.dockerapp. You can look at either latest or master tags.

Does seem to be timed with a recent update to the 18.09.0-ce-beta1 update for the engine, but haven't had a chance to dig in on what changes might be causing this.

Steps to reproduce the issue:

  1. Run docker-app init to create a new app
  2. Push the app using docker-app push
  3. Pull the image using docker pull mikesir87/dockerappbug.dockerapp.

Describe the results you received:

See error "operating system not supported"

Describe the results you expected:

Image pull to be successful

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client: Docker Engine - Community
 Version:           18.09.0-ce-beta1
 API version:       1.39
 Go version:        go1.10.4
 Git commit:        78a6bdb
 Built:             Thu Sep  6 22:41:53 2018
 OS/Arch:           darwin/amd64
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          18.09.0-ce-beta1
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       78a6bdb
  Built:            Thu Sep  6 22:49:35 2018
  OS/Arch:          linux/amd64
  Experimental:     true

Output of docker-app version:

Version:      v0.5.0
Git commit:   aef230ad
Built:        Fri Sep 14 11:42:46 2018
OS/Arch:      darwin/amd64
Experimental: off
Renderers:    none

Output of docker info:

Containers: 25
 Running: 0
 Paused: 0
 Stopped: 25
Images: 285
Server Version: 18.09.0-ce-beta1
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: active
 NodeID: dloojq1emf9sml8mwolhu1ud0
 Is Manager: true
 ClusterID: aw5wrijih10r44b1y75yg525j
 Managers: 1
 Nodes: 1
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 10
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Autolock Managers: false
 Root Rotation In Progress: false
 Node Address: 192.168.65.3
 Manager Addresses:
  192.168.65.3:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.125-linuxkit
Operating System: Docker for Mac
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 3.855GiB
Name: linuxkit-025000000001
ID: MJUL:QLSQ:3RCO:RBGI:OJ5N:SBVZ:MKJQ:WIRT:LRFG:2Y53:OHHW:XD3A
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 42
 Goroutines: 166
 System Time: 2018-09-16T02:34:22.5753156Z
 EventsListeners: 2
HTTP Proxy: gateway.docker.internal:3128
HTTPS Proxy: gateway.docker.internal:3129
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine

Additional environment details (AWS, VirtualBox, physical, etc.):

As noted in Docker info, this is on Docker Desktop (Mac) on latest beta.

For kicks, a cute animal

Sleeping puppy

@mikesir87

This comment has been minimized.

Show comment
Hide comment
@mikesir87

mikesir87 Sep 16, 2018

FWIW... I tried the pull on PWD (which is on 18.03.1-ce) and it had the same error there.

mikesir87 commented Sep 16, 2018

FWIW... I tried the pull on PWD (which is on 18.03.1-ce) and it had the same error there.

@mikesir87

This comment has been minimized.

Show comment
Hide comment
@mikesir87

mikesir87 Sep 16, 2018

Some additional testing... if I revert back to docker-app 0.4.1, the push and pull work as expected. So, seems to be something added with the 0.5.0 release.

The mikesir87/dockerappbug.dockerapp:app-0.4.1 tag was pushed with 0.4.1, in case anyone wants to look.

mikesir87 commented Sep 16, 2018

Some additional testing... if I revert back to docker-app 0.4.1, the push and pull work as expected. So, seems to be something added with the 0.5.0 release.

The mikesir87/dockerappbug.dockerapp:app-0.4.1 tag was pushed with 0.4.1, in case anyone wants to look.

@mikesir87

This comment has been minimized.

Show comment
Hide comment
@mikesir87

mikesir87 Sep 16, 2018

Running docker manifest inspect -v on the breaking image, it looks like the os and architecture are set to config/config. 🤔

{
	"Ref": "docker.io/mikesir87/dockerappbug.dockerapp:latest",
	"Descriptor": {
		"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
		"digest": "sha256:e6cef6242312dba3f2738b1087aee6ce745ff9f7ec52835195ab17839728d03c",
		"size": 523,
		"platform": {
			"architecture": "config",
			"os": "config"
		}
	},
        ...

mikesir87 commented Sep 16, 2018

Running docker manifest inspect -v on the breaking image, it looks like the os and architecture are set to config/config. 🤔

{
	"Ref": "docker.io/mikesir87/dockerappbug.dockerapp:latest",
	"Descriptor": {
		"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
		"digest": "sha256:e6cef6242312dba3f2738b1087aee6ce745ff9f7ec52835195ab17839728d03c",
		"size": 523,
		"platform": {
			"architecture": "config",
			"os": "config"
		}
	},
        ...
@vdemeester

This comment has been minimized.

Show comment
Hide comment
@vdemeester

vdemeester Sep 17, 2018

Member

@mikesir87 thanks for the issue. The reason is #314

cc @chris-crone @garethr

Member

vdemeester commented Sep 17, 2018

@mikesir87 thanks for the issue. The reason is #314

cc @chris-crone @garethr

@mnottale

This comment has been minimized.

Show comment
Hide comment
@mnottale

mnottale Sep 17, 2018

Contributor

To clarify, docker-app images no longer go through your local docker daemon. All docker-app command accept an image name as app input, so there should be no need for that. You should be able to adapt your workflow to skip the docker pull step. Let us now if you need any assistance with that.

Contributor

mnottale commented Sep 17, 2018

To clarify, docker-app images no longer go through your local docker daemon. All docker-app command accept an image name as app input, so there should be no need for that. You should be able to adapt your workflow to skip the docker pull step. Let us now if you need any assistance with that.

@mikesir87

This comment has been minimized.

Show comment
Hide comment
@mikesir87

mikesir87 Sep 17, 2018

Ok. That’s fine. But then how do I ensure I have the latest version, as I don’t see a docker-app pull or equivalent? I’m pushing the app images as part of my CI pipeline, tagged with the source branch.

If this is just an image, shouldn’t a docker pull still work? I think it’s a bad idea to have certain images in the registry not pull-able by the standard tooling and only accessible using special tools. I can see a lot of confusion coming up that way.

mikesir87 commented Sep 17, 2018

Ok. That’s fine. But then how do I ensure I have the latest version, as I don’t see a docker-app pull or equivalent? I’m pushing the app images as part of my CI pipeline, tagged with the source branch.

If this is just an image, shouldn’t a docker pull still work? I think it’s a bad idea to have certain images in the registry not pull-able by the standard tooling and only accessible using special tools. I can see a lot of confusion coming up that way.

@mnottale

This comment has been minimized.

Show comment
Hide comment
@mnottale

mnottale Sep 17, 2018

Contributor

Ok. That’s fine. But then how do I ensure I have the latest version, as I don’t see a docker-app pull or equivalent?

If you specify an image name to any docker-app command it will always pull. If you want a local copy on your filesystem you can docker-app split <IMAGE> for instance.

I agree with your comment that this is not ideal, but it's currently the best compromise to get portability. Support for Docker Applications in all the existing Docker tools&products is being planned.

Contributor

mnottale commented Sep 17, 2018

Ok. That’s fine. But then how do I ensure I have the latest version, as I don’t see a docker-app pull or equivalent?

If you specify an image name to any docker-app command it will always pull. If you want a local copy on your filesystem you can docker-app split <IMAGE> for instance.

I agree with your comment that this is not ideal, but it's currently the best compromise to get portability. Support for Docker Applications in all the existing Docker tools&products is being planned.

@mikesir87

This comment has been minimized.

Show comment
Hide comment
@mikesir87

mikesir87 Sep 17, 2018

If you specify an image name to any docker-app command it will always pull.

Ok. If that's the case, I can still do what I was planning to do. 👍

I agree with your comment that this is not ideal, but it's currently the best compromise to get portability.

After thinking about it some more, it does actually make sense to have the docker-app images architecture-agnostic, as the services being referenced could span across several architectures.

In the future, would be nice if there was a note about it in the release notes (and I recognize that this could be an unintended side effect as you probably weren't envisioning someone trying to use docker image pull). All good!

mikesir87 commented Sep 17, 2018

If you specify an image name to any docker-app command it will always pull.

Ok. If that's the case, I can still do what I was planning to do. 👍

I agree with your comment that this is not ideal, but it's currently the best compromise to get portability.

After thinking about it some more, it does actually make sense to have the docker-app images architecture-agnostic, as the services being referenced could span across several architectures.

In the future, would be nice if there was a note about it in the release notes (and I recognize that this could be an unintended side effect as you probably weren't envisioning someone trying to use docker image pull). All good!

@mikesir87 mikesir87 closed this Sep 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment