Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Start dockerd without experimental flag #9157

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

Closed
Furisto wants to merge 1 commit into main from fo/dockerd-exp-flag
Closed

Conversation

@Furisto
Copy link
Member

@Furisto Furisto commented Apr 6, 2022
edited by kylos101
Loading

Description

Start dockerd in the workspace without --experimental flag. We originally needed this to support rootless, but it graduated in v20.10

Related Issue(s)

n.a.

How to test

Release Notes

None

@Furisto Furisto requested a review from a team April 6, 2022 16:08
@github-actions github-actions bot added the team: workspace Issue belongs to the Workspace team label Apr 6, 2022
Copy link
Contributor

kylos101 commented Apr 6, 2022

@Furisto what sort of output would you expect for docker version?

I ask because of (version and experimental do not match):

gitpod /workspace/gitpod (fo/dockerd-exp-flag) $ docker version
Client: Docker Engine - Community
 Version: 20.10.12
 API version: 1.41
 Go version: go1.16.12
 Git commit: e91ed57
 Built: Mon Dec 13 11:45:33 2021
 OS/Arch: linux/amd64
 Context: default
 Experimental: true
Server: Docker Engine - Community
 Engine:
 Version: 20.10.12
 API version: 1.41 (minimum version 1.12)
 Go version: go1.16.12
 Git commit: 459d0df
 Built: Mon Dec 13 11:43:42 2021
 OS/Arch: linux/amd64
 Experimental: true
 containerd:
 Version: 1.4.13
 GitCommit: 9cc61520f4cd876b86e77edfeb88fbcd536d1f9d
 gitpod:
 Version: 1.1.0
 GitCommit: v1.1.0-0-g067aaf85
 docker-init:
 Version: 0.19.0
 GitCommit: de40ad0

Copy link
Contributor

sagor999 commented Apr 6, 2022

Do we have any tests to verify docker functionality? I am asking because we are upgrading major version of docker here, and there could be unexpected breaking changes or side effects.

kylos101 reacted with eyes emoji

Copy link
Contributor

@kylos101 kylos101 left a comment

Choose a reason for hiding this comment

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

Updated the instructions to specify to use this preview environment for testing . ;)

When testing from the preview environment, I see experimental is off on the server (woo hoo!), on for the client (dang), and the versions do not match 20.10.14. 🤔

gitpod /workspace/template-python-flask (main) $ which docker
/usr/bin/docker
gitpod /workspace/template-python-flask (main) $ docker version
Client: Docker Engine - Community
 Version: 20.10.12
 API version: 1.41
 Go version: go1.16.12
 Git commit: e91ed57
 Built: Mon Dec 13 11:45:33 2021
 OS/Arch: linux/amd64
 Context: default
 Experimental: true
Server: Docker Engine - Community
 Engine:
 Version: 20.10.12
 API version: 1.41 (minimum version 1.12)
 Go version: go1.16.12
 Git commit: 459d0df
 Built: Mon Dec 13 11:43:42 2021
 OS/Arch: linux/amd64
 Experimental: false
 containerd:
 Version: 1.4.13
 GitCommit: 9cc61520f4cd876b86e77edfeb88fbcd536d1f9d
 gitpod:
 Version: 1.1.0
 GitCommit: v1.1.0-0-g067aaf85
 docker-init:
 Version: 0.19.0
 GitCommit: de40ad0
gitpod /workspace/template-python-flask (main) $ docker run busybox sh
Unable to find image 'busybox:latest' locally
latest: Pulling from library/busybox
554879bb3004: Pull complete 
Digest: sha256:caa382c432891547782ce7140fb3b7304613d3b0438834dce1cad68896ab110a
Status: Downloaded newer image for busybox:latest

Tested with docker that ships with workspace-images too:

gitpod /workspace/template-python-flask (main) $ /bin/docker version
Client: Docker Engine - Community
 Version: 20.10.12
 API version: 1.41
 Go version: go1.16.12
 Git commit: e91ed57
 Built: Mon Dec 13 11:45:33 2021
 OS/Arch: linux/amd64
 Context: default
 Experimental: true
Server: Docker Engine - Community
 Engine:
 Version: 20.10.12
 API version: 1.41 (minimum version 1.12)
 Go version: go1.16.12
 Git commit: 459d0df
 Built: Mon Dec 13 11:43:42 2021
 OS/Arch: linux/amd64
 Experimental: false
 containerd:
 Version: 1.4.13
 GitCommit: 9cc61520f4cd876b86e77edfeb88fbcd536d1f9d
 gitpod:
 Version: 1.1.0
 GitCommit: v1.1.0-0-g067aaf85
 docker-init:
 Version: 0.19.0
 GitCommit: de40ad0

References:
docker cli
dockerd cli

@sagor999 I recall @utam0k made some docker integration tests recently, but last time I ran them I believe they failed. That said, given the version info I am seeing, I do not think it's a truly a major version upgrade, persay.

@Furisto is there a burning need to change this now, or can it wait? I feel like even though this file suggests that we're using 19, we may actually be using 20.

utam0k reacted with eyes emoji
Copy link
Contributor

utam0k commented Apr 7, 2022

This version specification is the version that will be installed when these binaries aren't present in the user's workspace. Therefore, if the workspace image contains a docker, the specified version will not be installed.

for cmd, pkg := range prerequisites {
if pth, _ := exec.LookPath(cmd); pth == "" {
log.WithField("command", cmd).Warn("missing prerequisite")
pkgs = append(pkgs, pkg)
}
}
kylos101 reacted with thumbs up emoji

Copy link
Contributor

utam0k commented Apr 7, 2022

We can guarantee our version by using the binaries we find, performing a version check and overwriting them if they are below the specified version. However, there may be a better way.

Copy link
Contributor

iQQBot commented Apr 7, 2022

I want to know if we continue use --experimental, will there be any impact?

Copy link
Contributor

I want to know if we continue use --experimental, will there be any impact?

Totally agree with this. The driver for this change primarily is optics, which is not enough of a reason to incur complexity. If this had been an easy/straight forward change it would have been worth it. Doesn't look like that though.

I'd vote for closing this now and revisiting the change in a month or two.

kylos101 and iQQBot reacted with thumbs up emoji

Copy link
Contributor

kylos101 commented Apr 7, 2022

Closing in favor of #9181, which is currently in our inbox. @Furisto thank you very much for socializing this and sharing with the team. 🙏

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

Reviewers

@kylos101 kylos101 kylos101 requested changes

Assignees

No one assigned

Labels

release-note-none size/XS team: workspace Issue belongs to the Workspace team

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /