Merge pull request #5146 from MsfPablo/fix-typos

Fix typos in docs and a comment

Author: AkihiroSuda

docs/dev/store.md

@@ -144,7 +144,7 @@ Users of the `namestore` do not have to bother with locking. These methods are s
 This is a good example of how to leverage core store primitives to implement a developer friendly, safe storage for
 "something" (in that case "names").
 
-Finaly note an important point - mentioned above: locking should be done to the smallest possible "segment" of sub-directories.
+Finally note an important point - mentioned above: locking should be done to the smallest possible "segment" of sub-directories.
 Specifically, any store should lock only - at most - resources under the _namespace_ being manipulated.
 
 For example, a container lifecycle storage should not lock out any other container, but only its own private directory.

docs/nydus.md

@@ -37,6 +37,6 @@ Nerdctl supports to convert an OCI image or docker format v2 image to Nydus imag
 
 Before the conversion, you should have the `nydus-image` binary installed, which is contained in the ["nydus static package"](https://github.com/dragonflyoss/image-service/releases). You can run the command like `nerdctl image convert --nydus --oci --nydus-builder-path <the_path_of_nydus_image_binary> <source_image> <target_image>` to convert the `<source_image>` to a Nydus image whose tag is `<target_image>`.
 
-By now, the converted Nydus image cannot be run directly. It shoud be unpacked to nydus snapshotter before `nerdctl run`, which is a part of the processing flow of `nerdctl image pull`. So you need to push the converted image to a registry after the conversion and use `nerdctl --snapshotter nydus image pull` to unpack it to the nydus snapshotter before running the image.
+By now, the converted Nydus image cannot be run directly. It should be unpacked to nydus snapshotter before `nerdctl run`, which is a part of the processing flow of `nerdctl image pull`. So you need to push the converted image to a registry after the conversion and use `nerdctl --snapshotter nydus image pull` to unpack it to the nydus snapshotter before running the image.
 
 Optionally, you can use the nydusify conversion tool to check if the format of the converted Nydus image is valid. For more details about the Nydus image validation and how to build Nydus image, please refer to [nydusify](https://github.com/dragonflyoss/image-service/blob/master/docs/nydusify.md) and [acceld](https://github.com/goharbor/acceleration-service).

examples/nerdctl-ipfs-registry-kubernetes/ipfs-cluster/README.md

@@ -8,7 +8,7 @@ Usage:
   - [`ipfs-key`](https://github.com/whyrusleeping/ipfs-key) is required (see https://ipfscluster.io/documentation/guides/k8s/)
 - Deploy `bootstrap.yaml` and `nerdctl-ipfs-registry.yaml` (e.g. using `kubectl apply`)
 - Make sure nodes contain containerd >= v1.5.8
-- You might want to change some configuration written in `nerdctl-ipfs-registry.yaml` (e.g. [chaning profile based on your node's resouce requirements](https://docs.ipfs.tech/how-to/default-profile/#available-profiles))
+- You might want to change some configuration written in `nerdctl-ipfs-registry.yaml` (e.g. [chaning profile based on your node's resource requirements](https://docs.ipfs.tech/how-to/default-profile/#available-profiles))
 
 ## Example on kind
 

examples/nerdctl-ipfs-registry-kubernetes/ipfs-stargz-snapshotter/README.md

@@ -8,7 +8,7 @@ Usage:
 - Deploy `bootstrap.yaml` and `nerdctl-ipfs-registry.yaml` (e.g. using `kubectl apply`)
 - Make sure nodes contain containerd >= v1.5.8 and stargz-snapshotter.
   - Here we use `ghcr.io/containerd/stargz-snapshotter:0.12.1-kind` that contains both of them. (This image requires kind >= 0.16.0)
-- You might want to change some configuration written in `nerdctl-ipfs-registry.yaml` (e.g. [chaning profile based on your node's resouce requirements](https://docs.ipfs.tech/how-to/default-profile/#available-profiles))
+- You might want to change some configuration written in `nerdctl-ipfs-registry.yaml` (e.g. [chaning profile based on your node's resource requirements](https://docs.ipfs.tech/how-to/default-profile/#available-profiles))
 
 ## About eStargz and Stargz Snapshotter
 
@@ -64,7 +64,7 @@ $ docker exec -it kind-worker /bin/bash
 (kind-worker)# nerdctl rmi ghcr.io/stargz-containers/jenkins:2.60.3-esgz
 ```
 
-> NOTE: This example copies a pre-converted eStargz image (`ghcr.io/stargz-containers/jenkins:2.60.3-esgz`) from the registry to IPFS but you can push non-eStargz image to IPFS with converting it to eStargz using `--estargz` flag of `nerdctl push`. This flag automatically performs convertion of the image to eStargz.
+> NOTE: This example copies a pre-converted eStargz image (`ghcr.io/stargz-containers/jenkins:2.60.3-esgz`) from the registry to IPFS but you can push non-eStargz image to IPFS with converting it to eStargz using `--estargz` flag of `nerdctl push`. This flag automatically performs conversion of the image to eStargz.
 
 The eStargz image added to `kind-worker` is shared to `kind-worker2` via IPFS.
 You can perform lazy pulling of this eStargz image among nodes using the following manifest.
@@ -98,7 +98,7 @@ EOF
 
 > NOTE1: Kubernetes doesn't support `ipfs://CID` URL on YAML as of now so we need to use `localhost:5050/ipfs/CID` form instead. In the future, this limitation should be eliminated.
 
-> NOTE2: stargz-snapshotter currently perfoms lazy pulling via `nerdctl ipfs registry` running on localhost instead of leveraging its [native support for fetching contents via ipfs daemon](https://github.com/containerd/stargz-snapshotter/blob/v0.12.0/docs/ipfs.md). This is because of the limitation described in NOTE1 and expected to be fixed once NOTE1 is solved.
+> NOTE2: stargz-snapshotter currently performs lazy pulling via `nerdctl ipfs registry` running on localhost instead of leveraging its [native support for fetching contents via ipfs daemon](https://github.com/containerd/stargz-snapshotter/blob/v0.12.0/docs/ipfs.md). This is because of the limitation described in NOTE1 and expected to be fixed once NOTE1 is solved.
 
 The image runs on all nodes.
 You may observe faster pulling of the image by eStargz.

examples/nerdctl-ipfs-registry-kubernetes/ipfs/README.md

@@ -7,7 +7,7 @@ Usage:
   - [`ipfs-swarm-key-gen`](https://github.com/Kubuxu/go-ipfs-swarm-key-gen) is required (see https://github.com/ipfs/kubo/blob/v0.15.0/docs/experimental-features.md#private-networks)
 - Deploy `bootstrap.yaml` and `nerdctl-ipfs-registry.yaml` (e.g. using `kubectl apply`)
 - Make sure nodes contain containerd >= v1.5.8
-- You might want to change some configuration written in `nerdctl-ipfs-registry.yaml` (e.g. [chaning profile based on your node's resouce requirements](https://docs.ipfs.tech/how-to/default-profile/#available-profiles))
+- You might want to change some configuration written in `nerdctl-ipfs-registry.yaml` (e.g. [chaning profile based on your node's resource requirements](https://docs.ipfs.tech/how-to/default-profile/#available-profiles))
 
 ## Example on kind
 

pkg/ipfs/registry_ipfs.go

@@ -126,7 +126,7 @@ func (s *server) serve(r *http.Request) (string, io.ReadSeeker, string, int64, e
 }
 
 func (s *server) serveContentByCID(ctx context.Context, targetCID string) (resC string, r io.ReadSeeker, mediaType string, size int64, err error) {
-	// TODO: make sure cidStr is a vaild CID?
+	// TODO: make sure cidStr is a valid CID?
 	c, desc, err := s.resolveCIDOfRootBlob(ctx, targetCID)
 	if err != nil {
 		return "", nil, "", 0, err