From a8ae48d94f595cccf060f83fdfa169e5813af28b Mon Sep 17 00:00:00 2001 From: Akihiro Suda Date: Wed, 24 Jun 2020 19:56:28 +0900 Subject: [PATCH] project: remove obviously outdated docs Remove the following files: - ARM.md (ARM hosts including ARM64 are fully supported now) - IRC-ADMINISTRATION.md (IRC has gone) - PACKAGE-REPO-MAINTENANCE.md (deb/rpm has moved to https://github.com/docker/docker-ce-packaging) - TOOLS.md (most tools except Jenkins are unused/unmaintained) Signed-off-by: Akihiro Suda --- project/ARM.md | 45 ------------------ project/IRC-ADMINISTRATION.md | 37 --------------- project/PACKAGE-REPO-MAINTENANCE.md | 74 ----------------------------- project/TOOLS.md | 63 ------------------------ 4 files changed, 219 deletions(-) delete mode 100644 project/ARM.md delete mode 100644 project/IRC-ADMINISTRATION.md delete mode 100644 project/PACKAGE-REPO-MAINTENANCE.md delete mode 100644 project/TOOLS.md diff --git a/project/ARM.md b/project/ARM.md deleted file mode 100644 index c876231d1e..0000000000 --- a/project/ARM.md +++ /dev/null @@ -1,45 +0,0 @@ -# ARM support - -The ARM support should be considered experimental. It will be extended step by step in the coming weeks. - -Building a Docker Development Image works in the same fashion as for Intel platform (x86-64). -Currently we have initial support for 32bit ARMv7 devices. - -To work with the Docker Development Image you have to clone the Docker/Docker repo on a supported device. -It needs to have a Docker Engine installed to build the Docker Development Image. - -From the root of the Docker/Docker repo one can use make to execute the following make targets: -- make validate -- make binary -- make build -- make deb -- make bundles -- make default -- make shell -- make test-unit -- make test-integration -- make - -The Makefile does include logic to determine on which OS and architecture the Docker Development Image is built. -Based on OS and architecture it chooses the correct Dockerfile. -For the ARM 32bit architecture it uses `Dockerfile.armhf`. - -So for example in order to build a Docker binary one has to: -1. clone the Docker/Docker repository on an ARM device `git clone https://github.com/docker/docker.git` -2. change into the checked out repository with `cd docker` -3. execute `make binary` to create a Docker Engine binary for ARM - -## Kernel modules -A few libnetwork integration tests require that the kernel be -configured with "dummy" network interface and has the module -loaded. However, the dummy module may be not loaded automatically. - -To load the kernel module permanently, run these commands as `root`. - - modprobe dummy - echo "dummy" >> /etc/modules - -On some systems you also have to sync your kernel modules. - - oc-sync-kernel-modules - depmod diff --git a/project/IRC-ADMINISTRATION.md b/project/IRC-ADMINISTRATION.md deleted file mode 100644 index 824a14bd51..0000000000 --- a/project/IRC-ADMINISTRATION.md +++ /dev/null @@ -1,37 +0,0 @@ -# Freenode IRC Administration Guidelines and Tips - -This is not meant to be a general "Here's how to IRC" document, so if you're -looking for that, check Google instead. ♥ - -If you've been charged with helping maintain one of Docker's now many IRC -channels, this might turn out to be useful. If there's information that you -wish you'd known about how a particular channel is organized, you should add -deets here! :) - -## `ChanServ` - -Most channel maintenance happens by talking to Freenode's `ChanServ` bot. For -example, `/msg ChanServ ACCESS LIST` will show you a list of everyone -with "access" privileges for a particular channel. - -A similar command is used to give someone a particular access level. For -example, to add a new maintainer to the `#docker-maintainers` access list so -that they can contribute to the discussions (after they've been merged -appropriately in a `MAINTAINERS` file, of course), one would use `/msg ChanServ -ACCESS #docker-maintainers ADD maintainer`. - -To setup a new channel with a similar `maintainer` access template, use a -command like `/msg ChanServ TEMPLATE maintainer +AV` (`+A` for letting -them view the `ACCESS LIST`, `+V` for auto-voice; see `/msg ChanServ HELP FLAGS` -for more details). - -## Troubleshooting - -The most common cause of not-getting-auto-`+v` woes is people not being -`IDENTIFY`ed with `NickServ` (or their current nickname not being `GROUP`ed with -their main nickname) -- often manifested by `ChanServ` responding to an `ACCESS -ADD` request with something like `xyz is not registered.`. - -This is easily fixed by doing `/msg NickServ IDENTIFY OldNick SecretPassword` -followed by `/msg NickServ GROUP` to group the two nicknames together. See -`/msg NickServ HELP GROUP` for more information. diff --git a/project/PACKAGE-REPO-MAINTENANCE.md b/project/PACKAGE-REPO-MAINTENANCE.md deleted file mode 100644 index 458384a3d9..0000000000 --- a/project/PACKAGE-REPO-MAINTENANCE.md +++ /dev/null @@ -1,74 +0,0 @@ -# Apt & Yum Repository Maintenance -## A maintainer's guide to managing Docker's package repos - -### How to clean up old experimental debs and rpms - -We release debs and rpms for experimental nightly, so these can build up. -To remove old experimental debs and rpms, and _ONLY_ keep the latest, follow the -steps below. - -1. Checkout docker master - -2. Run clean scripts - -```bash -docker build --rm --force-rm -t docker-dev:master . -docker run --rm -it --privileged \ - -v /path/to/your/repos/dir:/volumes/repos \ - -v $HOME/.gnupg:/root/.gnupg \ - -e GPG_PASSPHRASE \ - -e DOCKER_RELEASE_DIR=/volumes/repos \ - docker-dev:master hack/make.sh clean-apt-repo clean-yum-repo generate-index-listing sign-repos -``` - -3. Upload the changed repos to `s3` (if you host on s3) - -4. Purge the cache, PURGE the cache, PURGE THE CACHE! - -### How to get out of a sticky situation - -Sh\*t happens. We know. Below are steps to get out of any "hash-sum mismatch" or -"gpg sig error" or the likes error that might happen to the apt repo. - -**NOTE:** These are apt repo specific, have had no experience with anything similar -happening to the yum repo in the past so you can rest easy. - -For each step listed below, move on to the next if the previous didn't work. -Otherwise CELEBRATE! - -1. Purge the cache. - -2. Did you remember to sign the debs after releasing? - -Re-sign the repo with your gpg key: - -```bash -docker build --rm --force-rm -t docker-dev:master . -docker run --rm -it --privileged \ - -v /path/to/your/repos/dir:/volumes/repos \ - -v $HOME/.gnupg:/root/.gnupg \ - -e GPG_PASSPHRASE \ - -e DOCKER_RELEASE_DIR=/volumes/repos \ - docker-dev:master hack/make.sh sign-repos -``` - -Upload the changed repo to `s3` (if that is where you host) - -PURGE THE CACHE. - -3. Run Jess' magical, save all, only in case of extreme emergencies, "you are -going to have to break this glass to get it" script. - -```bash -docker build --rm --force-rm -t docker-dev:master . -docker run --rm -it --privileged \ - -v /path/to/your/repos/dir:/volumes/repos \ - -v $HOME/.gnupg:/root/.gnupg \ - -e GPG_PASSPHRASE \ - -e DOCKER_RELEASE_DIR=/volumes/repos \ - docker-dev:master hack/make.sh update-apt-repo generate-index-listing sign-repos -``` - -4. Upload the changed repo to `s3` (if that is where you host) - -PURGE THE CACHE. diff --git a/project/TOOLS.md b/project/TOOLS.md deleted file mode 100644 index dda0fc0342..0000000000 --- a/project/TOOLS.md +++ /dev/null @@ -1,63 +0,0 @@ -# Tools - -This page describes the tools we use and infrastructure that is in place for -the Docker project. - -### CI - -The Docker project uses [Jenkins](https://jenkins.dockerproject.org/) as our -continuous integration server. Each Pull Request to Docker is tested by running the -equivalent of `make all`. We chose Jenkins because we can host it ourselves and -we run Docker in Docker to test. - -#### Leeroy - -Leeroy is a Go application which integrates Jenkins with -GitHub pull requests. Leeroy uses -[GitHub hooks](https://developer.github.com/v3/repos/hooks/) -to listen for pull request notifications and starts jobs on your Jenkins -server. Using the Jenkins -[notification plugin](https://wiki.jenkins-ci.org/display/JENKINS/Notification+Plugin), -Leeroy updates the pull request using GitHub's -[status API](https://developer.github.com/v3/repos/statuses/) -with pending, success, failure, or error statuses. - -The leeroy repository is maintained at -[github.com/docker/leeroy](https://github.com/docker/leeroy). - -#### GordonTheTurtle IRC Bot - -The GordonTheTurtle IRC Bot lives in the -[#docker-maintainers](https://botbot.me/freenode/docker-maintainers/) channel -on Freenode. He is built in Go and is based off the project at -[github.com/fabioxgn/go-bot](https://github.com/fabioxgn/go-bot). - -His main command is `!rebuild`, which rebuilds a given Pull Request for a repository. -This command works by integrating with Leroy. He has a few other commands too, such -as `!gif` or `!godoc`, but we are always looking for more fun commands to add. - -The gordon-bot repository is maintained at -[github.com/docker/gordon-bot](https://github.com/docker/gordon-bot) - -### NSQ - -We use [NSQ](https://github.com/bitly/nsq) for various aspects of the project -infrastructure. - -#### Hooks - -The hooks project, -[github.com/crosbymichael/hooks](https://github.com/crosbymichael/hooks), -is a small Go application that manages web hooks from github, hub.docker.com, or -other third party services. - -It can be used for listening to github webhooks & pushing them to a queue, -archiving hooks to rethinkdb for processing, and broadcasting hooks to various -jobs. - -#### Docker Master Binaries - -One of the things queued from the Hooks are the building of the Master -Binaries. This happens on every push to the master branch of Docker. The -repository for this is maintained at -[github.com/docker/docker-bb](https://github.com/docker/docker-bb).