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

Support for debian-jessie on aarch64 #31193

Merged
merged 3 commits into from Mar 14, 2017

Conversation

@docbobo
Contributor

docbobo commented Feb 20, 2017

This is similar to PR #30168. It does use a golang package from jessie-backports instead of a custom build one though.

- What I did

  • Added build of package for debian-jessie on aarch64.

- How I did it

  • Added debian-jessie to generate.sh script. In order to properly build Go 1.7.5 from source, golang-1.6-go from jessie-backports is required.

- How to verify it
You just need to build the Debian packages on an aarch64. As mentioned in PR #30168, this can be done with 2A machines at packet.net.

- Description for the changelog
Added support for debian-jessie as make deb output for aarch64.

@docbobo

This comment has been minimized.

Contributor

docbobo commented Feb 20, 2017

@vielmetti If I understand your correctly, all Go versions in this PR should be updated to 1.8.0, right?

@vielmetti

This comment has been minimized.

vielmetti commented Feb 20, 2017

@docbobo - I know that all of the mainline Docker versions are at 1.7.5 now

The alternative is to apply this backported patch to the Go sources to address the problem with page sizes:

fancybits/go@release-branch.go1.7...arm-pagesize-64k

All that said, I am good with going to Go 1.8.0 release (and then dealing with the consequences, if any).

@docbobo docbobo force-pushed the docbobo:master-aarch64 branch from 388e595 to c7a6a59 Feb 20, 2017

@GordonTheTurtle GordonTheTurtle removed the dco/no label Feb 20, 2017

@docbobo

This comment has been minimized.

Contributor

docbobo commented Feb 20, 2017

Okay, I've updated the PR. I am also building on packet.net myself right now.

@tophj-ibm

This comment has been minimized.

Contributor

tophj-ibm commented Feb 20, 2017

IMO this should be two PRs, one for the fix for manpages + validate which is more of a needed bug fix, and another for adding in debian:jessie support.

cc @justincormack although this doesn't have seccomp support so I know you aren't going to like it 😄

@docbobo

This comment has been minimized.

Contributor

docbobo commented Feb 20, 2017

@tophj-ibm are you also ok with raising GO_VERSION to 1.8? And should I be opening a new PR for the commit w/o the manpages? Or rather force update this one on my end?

@tophj-ibm

This comment has been minimized.

Contributor

tophj-ibm commented Feb 20, 2017

@docbobo I would open a new one for the dockerfile.aarch64 and the man/dockerfile.aarch64 change. And then leave this one as all the contrib/* changes. That way #31061 can be fixed ASAP.

I would leave the GO_VERSION in dockerfile.aarch64 and in the manpages as 1.7.5 for now just so it's consistent across all the GO_VERSIONS and there is already a PR that updates them #29030. It's probably fine to leave it as 1.8 in the actual contrib files though, because that's more of a feature request.

@docbobo docbobo force-pushed the docbobo:master-aarch64 branch from c7a6a59 to de991e6 Feb 20, 2017

@justincormack

This comment has been minimized.

Contributor

justincormack commented Feb 20, 2017

@docbobo

This comment has been minimized.

Contributor

docbobo commented Feb 20, 2017

Okay. I've update this PR:

  • No Go 1.8 for now, everything stays at 1.7.5
  • Removed everything regarding golint, manpages, etc.

So this PR just contains the changes needed to support debian:jessie. As described, this is done by bootstraping Go 1.7.5 via golang-1.6-go. Let me know if there's anything else.

@docbobo docbobo referenced this pull request Feb 20, 2017

Merged

Improved aarch64 build #31198

@docbobo

This comment has been minimized.

Contributor

docbobo commented Feb 20, 2017

Anyone having an idea how my change could've affected the Windows build? Flaky test?

Added debian-jessie for aarch64
Adding debian-jessie as output for running make deb on aarch64. Also
update GO_VERSION to 1.8 to fix issues with incorrect pagesize.-

Signed-off-by: Boris Pruessmann <boris@pruessmann.org>
@DieterReuter

This comment has been minimized.

Contributor

DieterReuter commented Feb 21, 2017

I just tested this PR on a Packet.net 2A server with building Docker v1.13.1, works like a charme!
👍

@vieux

This comment has been minimized.

Collaborator

vieux commented Feb 27, 2017

Are we good to merge this one ?

@tophj-ibm

This comment has been minimized.

Contributor

tophj-ibm commented Feb 28, 2017

@justincormack thoughts on this seeing as jessie doesn't have the proper seccomp support?

On the other hand x86 jessie doesn't have it either, so a reasonable solution might be to require it in all versions later than this, wdyt.

@justincormack

This comment has been minimized.

Contributor

justincormack commented Feb 28, 2017

I don't really see why anyone would sanely run jessie on arm64, we should at least start with stretch which would be a plausible install target.

libseccomp 2.2.3 is available in jessie backports - again if you are foolish enough to run jessie on arm64 you should have backports enabled or nothing is going to work well.

@docbobo

This comment has been minimized.

Contributor

docbobo commented Mar 2, 2017

@justincormack I just looked at the other builders for debian packages. Here's the current state:

  • aarch64: ubuntu:trusty without seccomp.
  • amd64: debian:jessie, debian:wheezy without seccomp. ubuntu:precis, ubuntu:trusty without seccomp.
  • armhf: debian:jessie, raspbian:jessie without seccomp. ubuntu:trusty without seccomp.
  • ppc64le: ubuntu:trusty without seccomp.
  • s390x: ubuntu:xenial without seccomp.

None of the other architectures currently has a debian:jessie package with seccomp support. From that perspective, I find the PR in line with the other architectures.

How about this: I'll do another PR for debian:strech (aarch64) and we keep debian:jessie aligned with the already existing builders?

Added support for debian-stretch (aarch64)
Signed-off-by: Boris Pruessmann <boris@pruessmann.org>
@justincormack

This comment has been minimized.

Contributor

justincormack commented Mar 3, 2017

@docbobo I guess we can say we arent adding another version without seccomp as it is still just jessie, ok. Thanks for adding stretch, thats what people should be running...

The CI failures are unrelated, will do a rebuild once the fix is merged to master.

@coolljt0725

This comment has been minimized.

Contributor

coolljt0725 commented Mar 7, 2017

ping @tianon

@tianon

Generally seems OK to me, but I agree with @justincormack that jessie probably ought to be removed for aarch64. 👍

;;
*)
;;
esac

This comment has been minimized.

@tianon

tianon Mar 8, 2017

Member

This block appears to be indented with spaces instead of tabs (which is what the rest of this file uses), although should probably just be removed instead along with the other jessie references per @justincormack's comment.

This comment has been minimized.

@docbobo

docbobo Mar 8, 2017

Contributor

Please help me out here. Stretch is currently in "testing" (according to https://wiki.debian.org/DebianStretch). Why exactly is this preferable over Jessie?

This comment has been minimized.

@tianon

tianon Mar 8, 2017

Member

Stretch is frozen, meaning no new packages without an explicit unblock from the release team (in preparation for Stretch becoming the next stable release), so it's a pretty safe target these days, but IMO more importantly, Jessie on aarch64 is not a great/safe experience (as noted in the discussion above).

Seccomp is a really important part of Docker's overall security model, so I'm definitely +1 on @justincormack's suggestion that we not add any more platforms for which it cannot be supported, and would even be +1 on either finding a way to get libseccomp working for them or deprecating support for them too (via the normal project-wide deprecation process of several releases).

This comment has been minimized.

@docbobo

docbobo Mar 8, 2017

Contributor

ok. adding libseccomp support for jessie is rather straightforward, and I have that change done (just need to reverify). I'd rather add that than completely removing jessie.

ENV AUTO_GOPATH 1
ENV DOCKER_BUILDTAGS apparmor pkcs11 selinux

This comment has been minimized.

@tophj-ibm

tophj-ibm Mar 8, 2017

Contributor

don't forget the tags

This comment has been minimized.

@docbobo

docbobo Mar 8, 2017

Contributor

argh. that was supposed to go to my testing branch first. Let me fix that quickly.

seccomp support for debian jessie
Based on jessie-backports.

Signed-off-by: Boris Pruessmann <boris@pruessmann.org>

@docbobo docbobo force-pushed the docbobo:master-aarch64 branch from 26ebb3f to fcadb77 Mar 8, 2017

@docbobo

This comment has been minimized.

Contributor

docbobo commented Mar 8, 2017

$ docker info
Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 43
Server Version: 17.04.0-dev
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 43
 Dirperm1 Supported: true
Logging Driver: journald
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: 
containerd version: 665e84e6c28653a9c29a6db601636a92d46896f3
runc version: a01dafd48bc1c7cc12bdb01206f9fea7dd6feb70
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 3.14.79-108
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 1.928GiB
Name: dockeroid01
ID: SLSX:MAEN:2PA4:LETD:C36P:YAZK:W5BA:OLE7:QHHS:JOWV:BKAJ:Z2PZ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
@docbobo

This comment has been minimized.

Contributor

docbobo commented Mar 10, 2017

I am having a hard time understanding why the test were failing (and why two builder seem to be stuck). Were those test failures legit? Is there any way to restart tests?

@justincormack

This comment has been minimized.

Contributor

justincormack commented Mar 10, 2017

rebuilding janky to see

@justincormack

This comment has been minimized.

Contributor

justincormack commented Mar 10, 2017

Jessie with compulsory backports seems more sane (but I still recommend people use stretch!)

@justincormack

This comment has been minimized.

Contributor

justincormack commented Mar 13, 2017

ok tests passed, LGTM

@tophj-ibm

This comment has been minimized.

Contributor

tophj-ibm commented Mar 13, 2017

P+Z tests should be fine too

@tianon

tianon approved these changes Mar 13, 2017

LGTM

@thaJeztah is there someone we need to ping to make sure the "compulsory backports on jessie" gets documented appropriately?

@DieterReuter

This comment has been minimized.

Contributor

DieterReuter commented Mar 13, 2017

Cool. I really love this implementation. So we do have support for Stretch and Jessie. Great work @docbobo!

@justincormack

This comment has been minimized.

Contributor

justincormack commented Mar 14, 2017

ok, old P+Z builds from the jenkins update, ignoring

@justincormack justincormack merged commit 4108d62 into moby:master Mar 14, 2017

4 of 6 checks passed

powerpc Jenkins build is being scheduled
Details
z Jenkins build is being scheduled
Details
dco-signed All commits are signed
experimental Jenkins build Docker-PRs-experimental 31469 has succeeded
Details
janky Jenkins build Docker-PRs 40167 has succeeded
Details
windowsRS1 Jenkins build Docker-PRs-WoW-RS1 11160 has succeeded
Details

@GordonTheTurtle GordonTheTurtle added this to the 17.04.0 milestone Mar 14, 2017

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