docs: remove shim/proxy topics and fix docs links

And also change links from old documentation to docs sub-directory.

Fixes #444

Signed-off-by: bin liu <bin@hyper.sh>

docs/how-to/containerd-kata.md

@@ -57,7 +57,7 @@ use `RuntimeClass` instead of the deprecated annotations.
 
 ### Containerd Runtime V2 API: Shim V2 API
 
-The [`containerd-shim-kata-v2` (short as `shimv2` in this documentation)](https://github.com/kata-containers/runtime/tree/master/containerd-shim-v2) 
+The [`containerd-shim-kata-v2` (short as `shimv2` in this documentation)](../../src/runtime/containerd-shim-v2) 
 implements the [Containerd Runtime V2 (Shim API)](https://github.com/containerd/containerd/tree/master/runtime/v2) for Kata.
 With `shimv2`, Kubernetes can launch Pod and OCI-compatible containers with one shim per Pod. Prior to `shimv2`, `2N+1` 
 shims (i.e. a `containerd-shim` and a `kata-shim` for each container and the Pod sandbox itself) and no standalone `kata-proxy` 
@@ -72,7 +72,7 @@ is implemented in Kata Containers v1.5.0.
 
 ### Install Kata Containers
 
-Follow the instructions to [install Kata Containers](https://github.com/kata-containers/documentation/blob/master/install/README.md).
+Follow the instructions to [install Kata Containers](../install/README.md).
 
 ### Install containerd with CRI plugin
 

docs/how-to/how-to-import-kata-logs-with-fluentd.md

@@ -33,7 +33,7 @@ also applies to the Kata `shimv2` runtime.  Differences pertaining to Kata `shim
 
 Kata generates logs. The logs can come from numerous parts of the Kata stack (the runtime, proxy, shim
 and even the agent). By default the logs
-[go to the system journal](https://github.com/kata-containers/runtime#logging),
+[go to the system journal](../../src/runtime/README.md#logging),
 but they can also be configured to be stored in files.
 
 The logs default format is in [`logfmt` structured logging](https://brandur.org/logfmt), but can be switched to
@@ -256,7 +256,7 @@ directly from Kata, that should make overall import and processing of the log en
 
 There are potentially two things we can do with Kata here:
 
-- Get Kata to [output its logs in `JSON` format](https://github.com/kata-containers/runtime#logging) rather
+- Get Kata to [output its logs in `JSON` format](../../src/runtime/README.md#logging) rather
   than `logfmt`.
 - Get Kata to log directly into a file, rather than via the system journal. This would allow us to not need
   to parse the systemd format files, and capture the Kata log lines directly. It would also avoid Fluentd

docs/how-to/how-to-load-kernel-modules-with-kata.md

@@ -103,6 +103,6 @@ spec:
 
 > **Note**: To pass annotations to Kata containers, [cri must to be configurated correctly](how-to-set-sandbox-config-kata.md#cri-configuration)
 
-[1]: https://github.com/kata-containers/runtime
-[2]: https://github.com/kata-containers/agent
+[1]: ../../src/runtime
+[2]: ../../src/agent
 [3]: https://kubernetes.io/docs/concepts/workloads/pods/pod/

docs/how-to/how-to-use-k8s-with-cri-containerd-and-kata.md

@@ -177,7 +177,7 @@ $ sudo -E kubectl taint nodes --all node-role.kubernetes.io/master-
 By default, all pods are created with the default runtime configured in CRI containerd plugin.
 
 If a pod has the `io.kubernetes.cri.untrusted-workload` annotation set to `"true"`, the CRI plugin runs the pod with the
-[Kata Containers runtime](https://github.com/kata-containers/runtime/blob/master/README.md).
+[Kata Containers runtime](../../src/runtime/README.md).
 
 - Create an untrusted pod configuration
 

docs/how-to/how-to-use-kata-containers-with-acrn.md

@@ -49,7 +49,7 @@ This document requires the presence of the ACRN hypervisor and Kata Containers o
   $ sudo sed -i "s/$kernel_img/bzImage/g" /mnt/loader/entries/$conf_file
   $ sync && sudo umount /mnt && sudo reboot
   ```
-- Kata Containers installation: Automated installation does not seem to be supported for Clear Linux, so please use [manual installation](https://github.com/kata-containers/documentation/blob/master/Developer-Guide.md) steps.
+- Kata Containers installation: Automated installation does not seem to be supported for Clear Linux, so please use [manual installation](../Developer-Guide.md) steps.
 
 > **Note:** Create rootfs image and not initrd image.
 
@@ -82,7 +82,7 @@ $ sudo systemctl daemon-reload
 $ sudo systemctl restart docker
 ```
 
-4. Configure [Docker](https://github.com/kata-containers/documentation/blob/master/Developer-Guide.md#update-the-docker-systemd-unit-file) to use `kata-runtime`.
+4. Configure [Docker](../Developer-Guide.md#update-the-docker-systemd-unit-file) to use `kata-runtime`.
 
 ## Configure Kata Containers with ACRN
 

docs/how-to/how-to-use-kata-containers-with-nemu.md

@@ -19,7 +19,7 @@ Kata Containers relies by default on the QEMU hypervisor in order to spawn the v
 This document describes how to run Kata Containers with NEMU, first by explaining how to download, build and install it. Then it walks through the steps needed to update your Kata Containers configuration in order to run with NEMU. 
 
 ## Pre-requisites
-This document requires Kata Containers to be [installed](https://github.com/kata-containers/documentation/blob/master/install/README.md) on your system.
+This document requires Kata Containers to be [installed](../install/README.md) on your system.
 
 Also, it's worth noting that NEMU only supports `x86_64` and `aarch64` architecture.
 

docs/how-to/how-to-use-virtio-fs-with-kata.md

@@ -25,14 +25,14 @@ This document describes how to get Kata Containers to work with virtio-fs.
 
 ## Install Kata Containers with virtio-fs support
 
-The Kata Containers NEMU configuration, the NEMU VMM and the `virtiofs` daemon are available in the [Kata Container release](https://github.com/kata-containers/runtime/releases) artifacts starting with the 1.7 release. While the feature is experimental, distribution packages are not supported, but installation is available through [`kata-deploy`](https://github.com/kata-containers/packaging/tree/master/kata-deploy).
+The Kata Containers NEMU configuration, the NEMU VMM and the `virtiofs` daemon are available in the [Kata Container release](https://github.com/kata-containers/kata-containers/releases) artifacts starting with the 1.7 release. While the feature is experimental, distribution packages are not supported, but installation is available through [`kata-deploy`](../../tools/packaging/kata-deploy).
 
 Install the latest release of Kata as follows:
 ```
 docker run --runtime=runc -v /opt/kata:/opt/kata -v /var/run/dbus:/var/run/dbus -v /run/systemd:/run/systemd -v /etc/docker:/etc/docker -it katadocker/kata-deploy kata-deploy-docker install
 ```
 
-This will place the Kata release artifacts in `/opt/kata`, and update Docker's configuration to include a runtime target, `kata-nemu`. Learn more about `kata-deploy` and how to use `kata-deploy` in Kubernetes [here](https://github.com/kata-containers/packaging/tree/master/kata-deploy#kubernetes-quick-start).
+This will place the Kata release artifacts in `/opt/kata`, and update Docker's configuration to include a runtime target, `kata-nemu`. Learn more about `kata-deploy` and how to use `kata-deploy` in Kubernetes [here](../../tools/packaging/kata-deploy/README.md#kubernetes-quick-start).
 
 
 ## Run a Kata Container utilizing virtio-fs

docs/how-to/privileged.md

@@ -75,5 +75,5 @@ See below example config:
   privileged_without_host_devices = true
 ```
 
- - [Kata Containers with CRI-O](https://github.com/kata-containers/documentation/blob/master/how-to/run-kata-with-k8s.md#cri-o)
+ - [Kata Containers with CRI-O](../how-to/run-kata-with-k8s.md#cri-o)
   

docs/how-to/run-kata-with-k8s.md

@@ -14,7 +14,7 @@
   * [Run a Kubernetes pod with Kata Containers](#run-a-kubernetes-pod-with-kata-containers)
 
 ## Prerequisites
-This guide requires Kata Containers available on your system, install-able by following [this guide](https://github.com/kata-containers/documentation/blob/master/install/README.md).
+This guide requires Kata Containers available on your system, install-able by following [this guide](../install/README.md).
 
 ## Install a CRI implementation
 
@@ -28,7 +28,7 @@ After choosing one CRI implementation, you must make the appropriate configurati
 to ensure it integrates with Kata Containers.
 
 Kata Containers 1.5 introduced the `shimv2` for containerd 1.2.0, reducing the components
-required to spawn pods and containers, and this is the preferred way to run Kata Containers with Kubernetes ([as documented here](https://github.com/kata-containers/documentation/blob/master/how-to/how-to-use-k8s-with-cri-containerd-and-kata.md#configure-containerd-to-use-kata-containers)).
+required to spawn pods and containers, and this is the preferred way to run Kata Containers with Kubernetes ([as documented here](../how-to/how-to-use-k8s-with-cri-containerd-and-kata.md#configure-containerd-to-use-kata-containers)).
 
 An equivalent shim implementation for CRI-O is planned.
 
@@ -78,7 +78,7 @@ a runtime to be used when the workload cannot be trusted and a higher level of s
 is required. An additional flag can be used to let CRI-O know if a workload
 should be considered _trusted_ or _untrusted_ by default.
 For further details, see the documentation
-[here](https://github.com/kata-containers/documentation/blob/master/design/architecture.md#mixing-vm-based-and-namespace-based-runtimes).
+[here](../design/architecture.md#mixing-vm-based-and-namespace-based-runtimes).
 
 ```toml
 # runtime is the OCI compatible runtime used for trusted container workloads.
@@ -132,7 +132,7 @@ to properly install it.
 
 To customize containerd to select Kata Containers runtime, follow our
 "Configure containerd to use Kata Containers" internal documentation
-[here](https://github.com/kata-containers/documentation/blob/master/how-to/how-to-use-k8s-with-cri-containerd-and-kata.md#configure-containerd-to-use-kata-containers).
+[here](../how-to/how-to-use-k8s-with-cri-containerd-and-kata.md#configure-containerd-to-use-kata-containers).
 
 ## Install Kubernetes
 
@@ -160,7 +160,7 @@ Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --runtime-request-tim
 Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock"
 ```
 For more information about containerd see the "Configure Kubelet to use containerd"
-documentation [here](https://github.com/kata-containers/documentation/blob/master/how-to/how-to-use-k8s-with-cri-containerd-and-kata.md#configure-kubelet-to-use-containerd).
+documentation [here](../how-to/how-to-use-k8s-with-cri-containerd-and-kata.md#configure-kubelet-to-use-containerd).
 
 ## Run a Kubernetes pod with Kata Containers
 

docs/how-to/service-mesh.md

@@ -48,7 +48,7 @@ as the proxy starts.
 
 ### Kata and Kubernetes
 
-Follow the [instructions](https://github.com/kata-containers/documentation/blob/master/install/README.md)
+Follow the [instructions](../install/README.md)
 to get Kata Containers properly installed and configured with Kubernetes.
 You can choose between CRI-O and CRI-containerd, both are supported
 through this document.

docs/how-to/what-is-vm-cache-and-how-do-I-use-it.md

@@ -10,7 +10,7 @@
 VMCache is a new function that creates VMs as caches before using it.
 It helps speed up new container creation.  
 The function consists of a server and some clients communicating
-through Unix socket.  The protocol is gRPC in [`protocols/cache/cache.proto`](https://github.com/kata-containers/runtime/blob/master/protocols/cache/cache.proto).  
+through Unix socket.  The protocol is gRPC in [`protocols/cache/cache.proto`](../../src/runtime/protocols/cache/cache.proto).  
 The VMCache server will create some VMs and cache them by factory cache.
 It will convert the VM to gRPC format and transport it when gets
 requested from clients.  
@@ -21,9 +21,9 @@ a new sandbox.
 
 ### How is this different to VM templating
 
-Both [VM templating](https://github.com/kata-containers/documentation/blob/master/how-to/what-is-vm-templating-and-how-do-I-use-it.md) and VMCache help speed up new container creation.  
+Both [VM templating](../how-to/what-is-vm-templating-and-how-do-I-use-it.md) and VMCache help speed up new container creation.  
 When VM templating enabled, new VMs are created by cloning from a pre-created template VM, and they will share the same initramfs, kernel and agent memory in readonly mode.  So it saves a lot of memory if there are many Kata Containers running on the same host.  
-VMCache is not vulnerable to [share memory CVE](https://github.com/kata-containers/documentation/blob/master/how-to/what-is-vm-templating-and-how-do-I-use-it.md#what-are-the-cons) because each VM doesn't share the memory.
+VMCache is not vulnerable to [share memory CVE](../how-to/what-is-vm-templating-and-how-do-I-use-it.md#what-are-the-cons) because each VM doesn't share the memory.
 
 ### How to enable VMCache
 

docs/how-to/what-is-vm-templating-and-how-do-I-use-it.md

@@ -8,7 +8,7 @@ same initramfs, kernel and agent memory in readonly mode. It is very
 much like a process fork done by the kernel but here we *fork* VMs.
 
 ### How is this different from VMCache
-Both [VMCache](https://github.com/kata-containers/documentation/blob/master/how-to/what-is-vm-cache-and-how-do-I-use-it.md) and VM templating help speed up new container creation.  
+Both [VMCache](../how-to/what-is-vm-cache-and-how-do-I-use-it.md) and VM templating help speed up new container creation.  
 When VMCache enabled, new VMs are created by the VMCache server.  So it is not vulnerable to share memory CVE because each VM doesn't share the memory.  
 VM templating saves a lot of memory if there are many Kata Containers running on the same host.