website: nit fixes

This commit contains some minor style fixes to the website.

Signed-off-by: Or Ozeri <[email protected]>

website/Makefile

@@ -11,7 +11,7 @@ build: ; $(info building site...)
 	@hugo
 
 # delete hugo modules under clean?
-clean: ; $(info cleaning website output folder...)
+clean: ; $(info cleaning website output directory...)
 	@rm -rf ./public
 
 serve: ; $(info running locally with env=production...)

website/content/en/docs/concepts/fabric.md

@@ -4,7 +4,7 @@ description: Defining a ClusterLink fabric
 weight: 32
 ---
 
-The concept of a `Fabric` encapsulates a set of cooperating [peers]({{< ref "peers" >}}/).
+The concept of a `Fabric` encapsulates a set of cooperating [peers]({{< ref "peers" >}}).
  All peers in a fabric can communicate and may share [services]({{< ref "services" >}})
  between them, with access governed by [policies]({{< ref "policies" >}}).
  The `Fabric` acts as a root of trust for peer to peer communications (i.e.,
@@ -17,7 +17,7 @@ Currently, the concept of a `Fabric` is just that - a concept. It is not represe
  One could potentially consider a more elaborate implementation where a central
  management entity explicitly deals with `Fabric` life cycle, association of peers to
  a fabric, etc. The role of this central management component in ClusterLink is currently
- delegated to users who are responsible for coordinating the transfer to certificates
+ delegated to users who are responsible for coordinating the transfer of certificates
  between peers, out of band.
 
 ## Initializing a new fabric
@@ -28,15 +28,15 @@ The following assume that you have access to the `clusterlink` CLI and one or mo
  peers (i.e., clusters) where you'll deploy ClusterLink. The CLI can be downloaded
  from the ClusterLink [releases page on GitHub](https://github.com/clusterlink-net/clusterlink/releases/latest).
 
-### Create a new Fabric CA
+### Create a new fabric CA
 
-To create a new Fabric certificate authority (CA), execute the following CLI command:
+To create a new fabric certificate authority (CA), execute the following CLI command:
 
 ```sh
 clusterlink create fabric --name <fabric_name>
 ```
 
-This command will create the CA files `cert.pem` and `key.pem` in a folder named <fabric_name>. The `--name` option is optional, and by default, "default_fabric" will be used. While you will need access to these files to create the peers` gateway certificates later, the private key file should be protected and not shared with others.
+This command will create the CA files `cert.pem` and `key.pem` in a directory named <fabric_name>. The `--name` option is optional, and by default, "default_fabric" will be used. While you will need access to these files to create the peers` gateway certificates later, the private key file should be protected and not shared with others.
 
 ## Related tasks
 

website/content/en/docs/concepts/peers.md

@@ -1,23 +1,23 @@
 ---
 title: Peers
-description: Defining ClusterLink Peers as part of Fabric
+description: Defining ClusterLink peers as part of a fabric
 weight: 34
 ---
 
 A `Peer` represents a location, such as a Kubernetes cluster, participating in a
- [Fabric]({{< ref "fabric" >}}). Each peer may host one or more [Services]({{< ref "services" >}})
+ [fabric]({{< ref "fabric" >}}). Each peer may host one or more [services]({{< ref "services" >}})
  it wishes to share with other peers. A peer is managed by a peer administrator,
  which is responsible for running the ClusterLink control and data planes. The
  administrator will typically deploy the ClusterLink components by configuring
- the [deployment CRD]({{< ref "users#deploy-crd-instance" >}}). They may also wish to provide
+ the [deployment CR]({{< ref "users#deploy-cr-instance" >}}). They may also wish to provide
  (often) coarse-grained access policies in accordance with high level corporate
  policies (e.g., "production peers should only communicate with other production peers").
 
-Once a Peer has been added to a Fabric, it can communicate with any other Peer
+Once a peer has been added to a fabric, it can communicate with any other peer
  belonging to it. All configuration relating to service sharing (e.g., the exporting
- and importing of Services, and the setting of fine grained application policies) can be
+ and importing of services, and the setting of fine grained application policies) can be
  done with lowered privileges (e.g., by users, such as application owners). Remote peers are
- represented by the `Peer` Custom Resource Definition (CRD). Each Peer CRD instance
+ represented by the `Peer` Custom Resource Definition (CRD). Each Peer CR instance
  defines a remote cluster and the network endpoints of its ClusterLink gateways.
 
 ## Prerequisites
@@ -26,30 +26,30 @@ The following assume that you have access to the `clusterlink` CLI and one or mo
  peers (i.e., clusters) where you'll deploy ClusterLink. The CLI can be downloaded
  from the ClusterLink [releases page on GitHub](https://github.com/clusterlink-net/clusterlink/releases/latest).
  It also assumes that you have access to the [previously created]({{< ref "fabric#create-a-new-fabric-ca" >}})
- Fabric CA files.
+ fabric CA files.
 
-## Initializing a new Peer
+## Initializing a new peer
 
 {{< notice warning >}}
-Creating a new Peer is a **Fabric administrator** level operation and should be appropriately
+Creating a new peer is a **fabric administrator** level operation and should be appropriately
  protected.
 {{< /notice >}}
 
-### Create a new Peer certificate
+### Create a new peer certificate
 
-To create a new Peer certificate belonging to a fabric, confirm that the Fabric CA files
+To create a new peer certificate belonging to a fabric, confirm that the fabric CA files
  are available in the current working directory, and then execute the following CLI command:
 
 ```sh
 clusterlink create peer-cert --name <peer_name> --fabric <fabric_name>
 ```
 
 {{< notice tip >}}
-The Fabric CA files (certificate and private key) are expected to be in a subdirectory (i.e., `./<fabric_name>/cert.name` and `./<fabric_name>/key.pem`).
+The fabric CA files (certificate and private key) are expected to be in a subdirectory (i.e., `./<fabric_name>/cert.name` and `./<fabric_name>/key.pem`).
 {{< /notice >}}
 
 This will create the certificate and private key files (`cert.pem` and
- `key.pem`, respectively) for the new peer. By default, the files are
+ `key.pem`, respectively) of the new peer. By default, the files are
  created in a subdirectory named `<peer_name>` under the subdirectory of the fabric `<fabric_name>`.
  You can override the default by setting the `--output <path>` option.
 
@@ -59,11 +59,11 @@ You will need the CA certificate (but **not** the CA private key) and the peer c
  peer administrator.
 {{< /notice >}}
 
-## Deploy ClusterLink to a new Peer
+## Deploy ClusterLink to a new peer
 
 {{< notice info >}}
-This operation is typically done by a local **Peer administrator**, usually different
- than the **Fabric administrator**.
+This operation is typically done by a local **peer administrator**, usually different
+ than the **fabric administrator**.
 {{< /notice >}}
 
 Before proceeding, ensure that the CA certificate (the CA private key is not needed),
@@ -72,23 +72,23 @@ Before proceeding, ensure that the CA certificate (the CA private key is not nee
 
 ### Install the ClusterLink deployment operator
 
-Install the ClusterLink operator by running the following command
+Install the ClusterLink operator by running the following command:
 
 ```sh
 clusterlink peer init
 ```
 <!-- TODO: is this the right command -->
 
 The command assumes that kubectl is set to the correct context and credentials
-and that the certificates were created in the local folder. If they were not,
-add the `-f <path>` CLI option to set the correct path to the certificate files.
+and that the certificates were created in respective sub-directories under the current working directory. If they were not,
+add the `-f <path>` CLI option to set the correct path.
 
 This command will deploy the ClusterLink deployment CRDs using the current
 kubectl context. The operation requires cluster administrator privileges
 in order to install CRDs into the cluster.
 The ClusterLink operator is installed to the `clusterlink-operator` namespace
-and the CA and peer certificate and key are set as Kubernetes secrets
-in the namespace. You can confirm the successful completion of the step using
+and the CA and peer certificate and private key are set as K8s secrets
+in the namespace. You can confirm the successful completion of this step using
 the following commands:
 
 ```sh
@@ -109,50 +109,48 @@ multiline output of `kubectl get secret --namespace clusterlink-operator` comman
 
 {{% /expand %}}
 
-### Deploy ClusterLink via the Operator and ClusterLink CRD
+### Deploy ClusterLink via the operator and ClusterLink CR
 
 After the operator is installed, you can deploy ClusterLink by applying
- the ClusterLink instance CRD. This will cause the ClusterLink operator to
+ the ClusterLink CR. This will cause the ClusterLink operator to
  attempt reconciliation of the actual and intended ClusterLink deployment.
  By default, the operator will install the ClusterLink control and data plane
  components into a dedicated and privileged namespace (defaults to `clusterlink-system`).
- Configurations affecting the entire peer, such as the list of known Peers, are also maintained
+ Configurations affecting the entire peer, such as the list of known peers, are also maintained
  in the same namespace.
 
 Refer to the [getting started guide]({{< ref "users#setup" >}}) for a description
- of the ClusterLink instance CRD's fields.
+ of the ClusterLink CR fields.
 
 <!-- TODO expand the sample CRD file? -->
 
-## Add or remove Peers
+## Add or remove peers
 
 {{< notice info >}}
-This operation is typically done by a local **Peer administrator**, usually different
- than the **Fabric administrator**.
+This operation is typically done by a local **peer administrator**, usually different
+ than the **fabric administrator**.
 {{< /notice >}}
 
-Managing peers is done by creating, deleting and updating Peer CRD instances
+Managing peers is done by creating, deleting and updating peer CRs
  in the dedicated ClusterLink namespace (typically, `clusterlink-system`). Peers are
  added to the ClusterLink namespace by the peer administrator. Information
  regarding peer gateways and attributes is communicated out of band (e.g., provided
- by the Fabric or remote Peer administrator over email). In the future, these may
+ by the fabric or remote peer administrator over email). In the future, these may
  be configured via a management plane.
 
-There are two fundamental attributes in the Peer CRD: the Peer's name and the list of
- ClusterLink gateway endpoints through which the remote peer's Services are available.
- Peer names are unique and must align with the Subject name present in their certificate
+There are two fundamental attributes in the peer CRD: the peer name and the list of
+ ClusterLink gateway endpoints through which the remote peer services are available.
+ Peer names are unique and must align with the subject name present in their certificate
  during connection establishment. The name is used by importers in referencing an export
  (see [here]({{< ref "services" >}}) for details).
 
 Gateway endpoint would typically be a implemented via a `NodePort` or `LoadBalancer`
- Kubernetes Service. A `NodePort` Service would typically be used in local deployments
- (e.g., when running in KIND clusters during development) and a `LoadBalancer` Service
- would be used in Cloud based deployments. These can be automatically configured and
- created via the [operator CRD]{{< ref "#deploy-clusterlink-via-the-operator-and-clusterlink-crd" >}}.
- Not having any gateways is an error and will be reported in the Peer's Status.
- In addition, the Status section includes other useful attributes, such a `Reachable`
- (or `Seen`) indicating whether the Peer is currently reachable, the last time it
- successfully responded to heartbeats, etc.
+ K8s service. A `NodePort` service would typically be used in local deployments
+ (e.g., when running in kind clusters during development) and a `LoadBalancer` service
+ would be used in cloud based deployments. These can be automatically configured and
+ created via the [ClusterLink CRD]{{< ref "#deploy-clusterlink-via-the-operator-and-clusterlink-crd" >}}.
+ The peer's status section includes a `Reachable` condition indicating whether the peer is currently reachable,
+ and in case it is not reachable, the last time it was.
 
 {{% expand summary="Example YAML for `kubectl apply -f <peer_file>`" %}}
 {{< readfile file="/static/files/peer_crd_sample.yaml" code="true" lang="yaml" >}}
@@ -161,6 +159,6 @@ Gateway endpoint would typically be a implemented via a `NodePort` or `LoadBalan
 ## Related tasks
 
 Once a peer has been created and initialized with the ClusterLink control and data
- planes as well as one or more remote Peers, you can proceed with configuring
+ planes as well as one or more remote peers, you can proceed with configuring
  [services]({{< ref "services" >}}) and [policies]({{< ref "policies" >}}).
- For a complete end to end use case, refer to [iperf toturial]({{< ref "iperf" >}}).
+ For a complete end to end use case, refer to the [iperf toturial]({{< ref "iperf" >}}).

website/content/en/docs/concepts/policies.md

@@ -1,6 +1,6 @@
 ---
 title: Policies
-description: Controlling Service access across peers
+description: Controlling service access across peers
 weight: 38
 ---
 

website/content/en/docs/concepts/services.md

@@ -1,6 +1,6 @@
 ---
 title: Services
-description: Sharing Services
+description: Sharing services
 weight: 36
 ---
 

website/content/en/docs/getting-started/developers.md

@@ -15,7 +15,7 @@ Here are the key steps for setting up your developer environment, making a chang
     - [Go](https://go.dev/doc/install) version 1.20 or higher.
     - [Git](https://git-scm.com/downloads) command line.
     - We recommend using a [local development environment](https://kubernetes.io/docs/tasks/tools/)
-      such as Kind/kubectl for local development and integration testing.
+      such as kind/kubectl for local development and integration testing.
     - Additional development packages, such as `goimports` and `golangci-lint`. See the full list in
       [post-create.sh](https://github.com/clusterlink-net/clusterlink/blob/main/.devcontainer/dev/post-create.sh).
 1. Clone our repository with `git clone [email protected]:clusterlink-net/clusterlink.git`.