Merge pull request containerd#9496 from mxpv/links

Add nighly job to verify doc links (and fix broken links)

Author: samuelkarp

.github/workflows/links.yml

@@ -0,0 +1,26 @@
+name: Links
+
+on:
+  workflow_dispatch:
+  schedule:
+    - cron: "0 0 * * *" # Every day at midnight
+  pull_request:
+    paths:
+      - ".github/workflows/links.yml"
+
+jobs:
+  check:
+    runs-on: ubuntu-latest
+    name: lychee
+    timeout-minutes: 15
+    steps:
+      - uses: actions/checkout@v3
+
+      - uses: lycheeverse/[email protected]
+        with:
+          # Fail action on broken links
+          fail: true
+          args: --exclude-path vendor --exclude-path releases --timeout 30 --no-progress './**/*.md'
+          format: markdown
+          # Write GitHub job summary
+          jobSummary: true

.lycheeignore

@@ -0,0 +1,8 @@
+# This file accompanies links verification nightly CI job. Add links to ignore here.
+
+# These fail often due its popularity
+https://packages.debian.org/buster-backports/libseccomp2
+https://packages.ubuntu.com/trusty-backports/libseccomp2
+
+# Fails often with 'Too Many Requests', easy to scare
+https://tanzu.vmware.com/kubernetes-grid

README.md

@@ -6,6 +6,7 @@
 [![Nightlies](https://github.com/containerd/containerd/workflows/Nightly/badge.svg)](https://github.com/containerd/containerd/actions?query=workflow%3ANightly)
 [![Go Report Card](https://goreportcard.com/badge/github.com/containerd/containerd/v2)](https://goreportcard.com/report/github.com/containerd/containerd/v2)
 [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/1271/badge)](https://bestpractices.coreinfrastructure.org/projects/1271)
+[![Check Links](https://github.com/containerd/containerd/actions/workflows/links.yml/badge.svg)](https://github.com/containerd/containerd/actions/workflows/links.yml)
 
 containerd is an industry-standard container runtime with an emphasis on simplicity, robustness, and portability. It is available as a daemon for Linux and Windows, which can manage the complete container lifecycle of its host system: image transfer and storage, container execution and supervision, low-level storage and network attachments, etc.
 
@@ -309,7 +310,7 @@ The `cri` plugin has reached GA status, representing that it is:
 * Passes all [node e2e tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md).
 * Passes all [e2e tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/e2e-tests.md).
 
-See results on the containerd k8s [test dashboard](https://k8s-testgrid.appspot.com/sig-node-containerd)
+See results on the containerd k8s [test dashboard](https://testgrid.k8s.io/containerd)
 
 #### Validating Your `cri` Setup
 A Kubernetes incubator project, [cri-tools](https://github.com/kubernetes-sigs/cri-tools), includes programs for exercising CRI implementations. More importantly, cri-tools includes the program `critest` which is used for running [CRI Validation Testing](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/cri-validation.md).

docs/cri/installation.md

@@ -106,7 +106,7 @@ sudo apt-get update
 sudo apt-get install libseccomp2
 ```
 Note that:
-1) If you are using Ubuntu <=Trusty or Debian <=jessie, a backported version of `libseccomp2` is needed. (See the [trusty-backports](https://packages.ubuntu.com/trusty-backports/libseccomp2) and [jessie-backports](https://packages.debian.org/jessie-backports/libseccomp2)).
+1) If you are using Ubuntu <=Trusty or Debian <=jessie, a backported version of `libseccomp2` is needed. (See the [trusty-backports](https://packages.ubuntu.com/trusty-backports/libseccomp2) and [buster-backports](https://packages.debian.org/buster-backports/libseccomp2)).
 ## Step 1: Download Release Tarball
 Download release tarball for the `containerd` version you want to install from the GCS bucket.
 ```bash

docs/historical/cri/proposal.md

@@ -23,7 +23,7 @@ Containerd is one potential alternative to Docker as the runtime for Kubernetes
 ### Cons
 * **User Adoption**:
   * Ideally, Kubernetes users don't interact with the underlying container runtime directly. However, for the lack of debug toolkits, sometimes users still need to login the node to debug with Docker CLI directly.
-  * Containerd provides barebone CLIs [ctr](https://github.com/containerd/containerd/tree/main/cmd/ctr) and [dist](https://github.com/containerd/containerd/tree/main/cmd/dist) for development and debugging purpose, but they may not be sufficient and necessary. Additionally, presuming these are sufficient and necessary tools, a plan and time would be needed to sufficiently document these CLIs and educate users in their use.
+  * Containerd provides barebone CLI [ctr](https://github.com/containerd/containerd/tree/main/cmd/ctr) for development and debugging purpose, but it may not be sufficient and necessary. Additionally, presuming these are sufficient and necessary tools, a plan and time would be needed to sufficiently document these CLIs and educate users in their use.
 * **Maturity**: The rescoped containerd is pretty new, and it's still under heavy development.
 ## Goals
 * Make sure containerd meets the requirement of Kubernetes, now and into the foreseeable future.
@@ -44,8 +44,8 @@ Containerd doesn't provide persistent container log. It redirects container STDI
 
 CRI-containerd should start a goroutine (process/container in the future) to:
 * Continuously drain the FIFO;
-* Decorate the log line into [CRI-defined format](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/kubelet-cri-logging.md#proposed-solution);
-* Write the log into [CRI-defined log path](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/kubelet-cri-logging.md#proposed-solution).
+* Decorate the log line into [CRI-defined format](https://github.com/kubernetes/design-proposals-archive/blob/main/node/kubelet-cri-logging.md#proposed-solution);
+* Write the log into [CRI-defined log path](https://github.com/kubernetes/design-proposals-archive/blob/main/node/kubelet-cri-logging.md#proposed-solution).
 ### Container Streaming
 Containerd supports creating a process in the container with `Exec`, and the STDIO is also exposed as FIFOs. Containerd also supports resizing console of a specific process with `Pty`.
 
@@ -61,10 +61,10 @@ Containerd doesn't provide container networking, but OCI runtime spec supports j
 
 CRI-containerd should:
 * Create a network namespace for a sandbox;
-* Call [network plugin](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/network/plugins.go) to update the options of the network namespace;
+* Call [network plugin](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) to update the options of the network namespace;
 * Let the user containers in the same sandbox share the network namespace.
 ### Container Metrics
-Containerd provides [container cgroup metrics](https://github.com/containerd/containerd/blob/main/reports/2017-03-17.md#metrics), and plans to provide [container writable layer disk usage](https://github.com/containerd/containerd/issues/678).
+Containerd provides [container cgroup metrics](https://github.com/containerd/containerd/blob/main/docs/historical/reports/2017-03-17.md#metrics), and plans to provide [container writable layer disk usage](https://github.com/containerd/containerd/issues/678).
 
 CRI container metrics api needs to be defined ([#27097](https://github.com/kubernetes/kubernetes/issues/27097)). After that, CRI-containerd should translate containerd container metrics into CRI container metrics.
 ### Image Management
@@ -77,7 +77,7 @@ CRI image filesystem metrics needs to be defined ([#33048](https://github.com/ku
 ### Out of Scope
 Following items are out of the scope of this design, we may address them in future version as enhancement or optimization.
 * **Debuggability**: One of the biggest concern of CRI-containerd is debuggability. We should provide equivalent debuggability with Docker CLI through `kubectl`, [`cri-tools`](https://github.com/kubernetes-sigs/cri-tools) or containerd CLI.
-* **Built-in CRI support**: The [plugin model](https://github.com/containerd/containerd/blob/main/design/plugins.md) provided by containerd makes it possible to directly build CRI support into containerd as a plugin, which will eliminate one more hop from the stack. But because of the [limitation of golang plugin](https://github.com/containerd/containerd/issues/563), we have to either maintain our own branch or push CRI plugin upstream.
+* **Built-in CRI support**: The [plugin model](https://github.com/containerd/containerd/blob/main/docs/PLUGINS.md) provided by containerd makes it possible to directly build CRI support into containerd as a plugin, which will eliminate one more hop from the stack. But because of the [limitation of golang plugin](https://github.com/containerd/containerd/issues/563), we have to either maintain our own branch or push CRI plugin upstream.
 * **Seccomp**: ([#36997](https://github.com/kubernetes/kubernetes/issues/36997)) Seccomp is supported in OCI runtime spec. However, current seccomp implementation in Kubernetes is experimental and docker specific, the api needs to be defined in CRI first before CRI-containerd implements it.
 * **Streaming server authentication**: ([#36666](https://github.com/kubernetes/kubernetes/issues/36666)) CRI-containerd will be out-of-process with Kubelet, so it could not reuse Kubelet authentication. Its streaming server should implement its own authentication mechanism.
 * **Move container facilities into pod cgroup**: Container facilities including container image puller, container streaming handler, log handler and containerd-shim serve a specific container. They should be moved to the corresponding pod cgroup, and the overhead introduced by them should be charged to the pod.

docs/historical/reports/2017-01-13.md

@@ -41,6 +41,6 @@ We finished porting over the shim from the existing containerd implementation th
 
 Next week we will be working towards a full PoC with the runtime, storage, and fetching of images.  Getting the core functionality up and running quickly is important to us to ensure that integration between the different subsystems in the core flow well together.  We want to make sure the responsibilities of pulling an image from a remote source do not spill into the storage layer and vice-versa.
 
-We still have more documentation work to do on the design and lifecycle of components in the core which is another focus for next week.  You can find the current design docs in the [repo here](https://github.com/containerd/containerd/tree/main/design).
+We still have more documentation work to do on the design and lifecycle of components in the core which is another focus for next week.  You can find the current design docs in the [repo here](https://github.com/containerd/containerd/tree/main/docs).
 
 I hope this status report helps.  If you are looking for ways to contribute, check out the issues on the current milestone.

releases/v1.1.0.toml

@@ -102,7 +102,7 @@ In terms of testing, we've passed:
 
 The containerd test coverage on GCE is equivalent with Docker now.
 
-All the test results are public: https://k8s-testgrid.appspot.com/sig-node-containerd.
+All the test results are public: https://prow.k8s.io/?repo=containerd%2Fcontainerd.
 
 ### Performance