Merge pull request #589 from austinvazquez/doc-update

doc: update branch name references

Author: austinvazquez

docs/design-approaches.md

@@ -25,7 +25,7 @@ definitions.
 
 * Containerd - OCI compatible container runtime. Receives container lifecycle/management requests and performs them
   using configured plugins/options.
-* Runtime - An implementation of the runtime v2 [spec](https://github.com/containerd/containerd/tree/master/runtime/v2)
+* Runtime - An implementation of the runtime v2 [spec](https://github.com/containerd/containerd/tree/main/runtime/v2)
   for containerd. Unlike the default implementation which runs runc directly, our runtime will be responsible for
   managing Firecracker instances as well as communicating container requests to the inside-the-vm-agent.
 * Agent - A process inside of the running VM. Manages containers, handles communication with the Runtime and utilizes
@@ -42,8 +42,8 @@ definitions.
 ![design-overview](img/design-overview.png)
 
 1. Orchestrator accepts task definition request from control-plane and breaks it into sub-requests suitable for sending to
-   containerd (using `CreateTaskRequest` [struct](https://github.com/containerd/containerd/blob/master/api/services/tasks/v1/tasks.pb.go#L79),
-   additional parameters can be passed to runtime though `Options` [field](https://github.com/containerd/containerd/blob/master/api/services/tasks/v1/tasks.pb.go#L93))
+   containerd (using `CreateTaskRequest` [struct](https://github.com/containerd/containerd/blob/main/api/services/tasks/v1/tasks.pb.go#L79),
+   additional parameters can be passed to runtime though `Options` [field](https://github.com/containerd/containerd/blob/main/api/services/tasks/v1/tasks.pb.go#L93))
 2. containerd uses firecracker-containerd runtime and block device snapshotter. Requests are passed to runtime. Runtime
    is responsible for communicating with Agent, attaching/managing block devices and controlling container execution
    lifecycle.
@@ -94,9 +94,9 @@ any communication protocol can be chosen (ttrpc, grpc, http, ...) for exchanging
 The orchestrator knows about task definitions (e.g. aware about high level picture), makes decisions based on given
 information, and submits requests to containerd.
 
-The orchestrator talks to all subsystems using containerd's [APIs](https://github.com/containerd/containerd/tree/master/api).
-In order to manage containers lifecycle it can use [task](https://github.com/containerd/containerd/tree/master/services/tasks)
-service, extra configuration can be specified thought option [fields](https://github.com/containerd/containerd/blob/master/api/services/tasks/v1/tasks.proto#L74).
+The orchestrator talks to all subsystems using containerd's [APIs](https://github.com/containerd/containerd/tree/main/api).
+In order to manage containers lifecycle it can use [task](https://github.com/containerd/containerd/tree/main/services/tasks)
+service, extra configuration can be specified thought option [fields](https://github.com/containerd/containerd/blob/main/api/services/tasks/v1/tasks.proto#L74).
 Missing functionality (like firecracker control service) can be added as an extension to `containerd`.
 Containerd supports GRPC plugins, so FC control can reuse existing GRPC [server](https://github.com/containerd/containerd/blob/a15b6e2097c48b632dbdc63254bad4c62b69e709/services/server/server.go#L78)
 and live in same process as `containerd`. Orchestrator's client uses same GRPC connection (`containerd` has
@@ -165,7 +165,7 @@ Firecracker team is exploring options around Firecracker handling some aspects o
 
 Because there is no way to attach block devices upon request, the suggested approach is to use fake block devices (`/dev/null` or
 sparse files) to reserve drive ids before running Firecracker instance. When container needs to be run, fake device is
-replaced (via [PatchGuestDriveByID](https://github.com/firecracker-microvm/firecracker-go-sdk/blob/master/firecracker.go#L238))
+replaced (via [PatchGuestDriveByID](https://github.com/firecracker-microvm/firecracker-go-sdk/blob/main/firecracker.go#L238))
 with real container image received as [mount](https://github.com/firecracker-microvm/firecracker-containerd/blob/0e39b738ab466358b1059bb283b19726476310a1/runtime/service.go#L651)
 from snapshotter. Fake device can be represented by `/dev/null`, however Firecracker doesn't allow to attach same block
 device more than once (even with different drive ids). So alias should be used. Another approach is to use sparse files

docs/shim-design.md

@@ -48,9 +48,9 @@ The purpose of this doc is to determine which model best fits our use case in te
     * A unique identifier associated with each firecracker microVM that's used to reference which VM a given container is intended to run in.
         * In practice, there will likely be a 1-to-1 mapping between each ECS task or each EKS Pod to a `vm_id`.
 * (containerd) **Container**
-    * In containerd, a “[Container](https://github.com/containerd/containerd/blob/master/api/services/containers/v1/containers.proto#L38)” refers not to a running container but the metadata configuring a container.
+    * In containerd, a “[Container](https://github.com/containerd/containerd/blob/main/api/services/containers/v1/containers.proto#L38)” refers not to a running container but the metadata configuring a container.
 * (containerd) **Task**
-    * In containerd, a “[Task](https://github.com/containerd/containerd/blob/master/api/services/tasks/v1/tasks.proto#L56)” (not to be confused with an ECS Task), essentially refers to a running container; it is a running process using the configuration as specified in a previously defined Container object
+    * In containerd, a “[Task](https://github.com/containerd/containerd/blob/main/api/services/tasks/v1/tasks.proto#L56)” (not to be confused with an ECS Task), essentially refers to a running container; it is a running process using the configuration as specified in a previously defined Container object
 * **“shim start” routine**
     * In the runtime v2 model, when containerd starts a new Task, it will always invoke the runtime binary specified in the Container object and run its “shim start” routine. This is the point where the runtime shim will decide whether it should keep running or if containerd should instead use a different, pre-existing shim process.
     * [Our current shim start routine is here.](https://github.com/firecracker-microvm/firecracker-containerd/blob/3f204844eed9b70f25e062f3a947dda582809757/runtime/service.go#L106)
@@ -61,14 +61,14 @@ The purpose of this doc is to determine which model best fits our use case in te
 
 ## Containerd Runtime v2 Essentials
 
-There's a few details of containerd's runtime v2 model that are essential to understand before diving into how it can fit into our use case. [The runtime v2 docs](https://github.com/containerd/containerd/blob/master/runtime/v2/README.md) and their [getting started guide](https://github.com/containerd/containerd/blob/master/docs/getting-started.md) have more details, but the important parts of the typical flow in creating a container within the runtime v2 model are summarized below:
+There's a few details of containerd's runtime v2 model that are essential to understand before diving into how it can fit into our use case. [The runtime v2 docs](https://github.com/containerd/containerd/blob/main/runtime/v2/README.md) and their [getting started guide](https://github.com/containerd/containerd/blob/main/docs/getting-started.md) have more details, but the important parts of the typical flow in creating a container within the runtime v2 model are summarized below:
 
 ![containerd runtime v2 model](img/runtimev2-flow.png)
 
-1. The client makes a [CreateContainerRequest](https://github.com/containerd/containerd/blob/master/api/services/containers/v1/containers.proto#L38), which includes metadata for the intended container configuration (i.e. OCI runtime spec), which runtime the container should be spawned with (i.e. `aws.firecracker`) and a unique `container_id`
+1. The client makes a [CreateContainerRequest](https://github.com/containerd/containerd/blob/main/api/services/containers/v1/containers.proto#L38), which includes metadata for the intended container configuration (i.e. OCI runtime spec), which runtime the container should be spawned with (i.e. `aws.firecracker`) and a unique `container_id`
     1. This stores the metadata for the container definition within containerd, **but it does not actually spawn the container yet**
-2. The client now wants to actually create a running task for the container it just defined, which it does by issuing a [CreateTaskRequest](https://github.com/containerd/containerd/blob/master/api/services/tasks/v1/tasks.proto#L56) that includes the `container_id` provided in the previous `CreateContainerRequest`
-3. Containerd will now always `fork/exec` to the runtime's shim binary and invoke the “start” routine. **The shim is expected to [“either start a new shim or return an address to an existing shim based on the shim's logic.”](https://github.com/containerd/containerd/blob/master/runtime/v2/README.md#start)**
+2. The client now wants to actually create a running task for the container it just defined, which it does by issuing a [CreateTaskRequest](https://github.com/containerd/containerd/blob/main/api/services/tasks/v1/tasks.proto#L56) that includes the `container_id` provided in the previous `CreateContainerRequest`
+3. Containerd will now always `fork/exec` to the runtime's shim binary and invoke the “start” routine. **The shim is expected to [“either start a new shim or return an address to an existing shim based on the shim's logic.”](https://github.com/containerd/containerd/blob/main/runtime/v2/README.md#start)**
     1. (code) [containerd starting the shim binary](https://github.com/containerd/containerd/blob/9b882c44f8834613e53fc11045c10397a7d94e61/runtime/v2/manager.go#L126)
 4. At this point, the shim can optionally retrieve some more metadata if needed to make a decision on how to proceed. It has a few IDs/paths available to it that can be used to retrieve that metadata:
     1. The `container_id` for the container that is going to be spawned into a running task. The `container_id` is the “id” field in [our shim's NewService func](https://github.com/firecracker-microvm/firecracker-containerd/blob/3f204844eed9b70f25e062f3a947dda582809757/runtime/service.go#L79). It can be used to make a [GetContainerRequest](https://github.com/containerd/containerd/blob/68c44f8cc8a3a4990928c96f8207688ecf6df2f9/api/services/containers/v1/containers.proto#L30) to containerd, which will return all available container metadata.
@@ -85,7 +85,7 @@ There's a few details of containerd's runtime v2 model that are essential to und
 
 The requirements for our use case are:
 
-1. [Containerd's requirements for runtime v2 shims](https://github.com/containerd/containerd/tree/master/runtime/v2)
+1. [Containerd's requirements for runtime v2 shims](https://github.com/containerd/containerd/tree/main/runtime/v2)
 2. Ability to group containers into a single microVM via an identifier for the microVM (`vm_id`). Containers must be able to be created within the microVM after the VM has already started.
 
 # Decisions to be Made
@@ -102,7 +102,7 @@ The high-level issues this docs will address (each gets its own section):
 
 1. Fine grain details of how microVMs will be configured other than that running VMs can be specified with a `vm_id`.
 2. Details on exactly which field we will use to specify which `vm_id` a given container is using. There are multiple possibilities, all of which work with the options being presented here:
-    1. [OCI Config Annotation](https://github.com/opencontainers/runtime-spec/blob/master/config.md#annotations)
+    1. [OCI Config Annotation](https://github.com/opencontainers/runtime-spec/blob/main/config.md#annotations)
     2. [CreateContainerRequest.Container.Extensions](https://github.com/containerd/containerd/blob/68c44f8cc8a3a4990928c96f8207688ecf6df2f9/api/services/containers/v1/containers.proto#L100)
     3. [CreateTaskRequest.Options](https://github.com/containerd/containerd/blob/68c44f8cc8a3a4990928c96f8207688ecf6df2f9/api/services/tasks/v1/tasks.proto#L74)
 3. Details on how vsock communication will work. This doc will not make assumptions on which of the host or guest shim will be the listener/connector.

firecracker-control/cmd/containerd/main.go

@@ -21,7 +21,7 @@ import (
 	"github.com/containerd/containerd/pkg/seed"
 
 	// Register containerd builtins
-	// See https://github.com/containerd/containerd/blob/master/cmd/containerd/builtins.go
+	// See https://github.com/containerd/containerd/blob/main/cmd/containerd/builtins.go
 	_ "github.com/containerd/containerd/diff/walking/plugin"
 	_ "github.com/containerd/containerd/events/plugin"
 	_ "github.com/containerd/containerd/gc/scheduler"
@@ -41,7 +41,7 @@ import (
 	_ "github.com/containerd/containerd/services/version"
 
 	// Linux specific builtins
-	// See https://github.com/containerd/containerd/blob/master/cmd/containerd/builtins_linux.go
+	// See https://github.com/containerd/containerd/blob/main/cmd/containerd/builtins_linux.go
 	_ "github.com/containerd/containerd/metrics/cgroups"
 	_ "github.com/containerd/containerd/runtime/v1/linux"
 	_ "github.com/containerd/containerd/runtime/v2"

runtime/README.md

@@ -3,7 +3,7 @@
 This is the runtime component enabling containerd to control the Firecracker
 VMM.  This component runs on the host, outside your microVM. In general, it
 strives for
-[OCI runtime](https://github.com/opencontainers/runtime-spec/blob/master/spec.md)
+[OCI runtime](https://github.com/opencontainers/runtime-spec/blob/main/spec.md)
 compliance within the bounds of Firecracker's feature set.
 
 ## Building
@@ -20,7 +20,7 @@ installed and configured.
 
 Copy `containerd-shim-aws-firecracker` to /bin (or something else on the PATH)
 following the naming guidelines for a containerd
-[runtime v2](https://github.com/containerd/containerd/blob/master/runtime/v2/README.md)
+[runtime v2](https://github.com/containerd/containerd/blob/main/runtime/v2/README.md)
 shim:
 
 	* If the runtime is invoked as aws.firecracker