fix notice note in document to looks as all notes (with blue background)

website/config.toml

@@ -125,7 +125,7 @@ archived_version = false
 # point people to the main doc site.
 # url_latest_version = "https://clusterlink.net"
 
-latest_stable_version = "v0.3"
+latest_stable_version = "v0.4"
 
 # Repository configuration (URLs for in-page links to opening issues and suggesting changes)
 github_repo = "https://github.com/clusterlink-net/clusterlink"
@@ -234,6 +234,9 @@ path = "github.com/martignoni/hugo-notice"
 version = "main-DRAFT"
 url = "/docs/main"
 
+[[params.versions]]
+version = "v0.4"
+url = "/docs/v0.4/"
 
 [[params.versions]]
 version = "v0.3"

website/content/en/docs/main/tasks/relay/index.md

@@ -56,8 +56,8 @@ This is an extension of the basic [nginx toturial][]. Please run it first and se
     ```
 
     {{< notice note >}}
-      The relay cluster certificates should use the same Fabric CA files as the server and the client.
-    {{< /notice >}}
+   The relay cluster certificates should use the same Fabric CA files as the server and the client.
+   {{< /notice >}}
 
 1. Deploy ClusterLink on the relay cluster:
 

website/content/en/docs/v0.4/_index.md

@@ -0,0 +1,12 @@
+---
+title: v0.4
+cascade:
+  version: v0.4
+  versName: &name v0.4
+  git_version_tag: v0.4.0
+  exclude_search: false
+linkTitle: *name
+simple_list: true
+weight: -9999 # Weight for doc version vX.Y should be -(100*X + Y)0
+# For example: v0.2.x => -20 v3.6.7 => -3060. `main` is arbitrarily set to -9999
+---

website/content/en/docs/v0.4/concepts/_index.md

@@ -0,0 +1,5 @@
+---
+title: Core Concepts
+description: Core Concepts of the ClusterLink system
+weight: 30
+---

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

@@ -0,0 +1,54 @@
+---
+title: Fabric
+description: Defining a ClusterLink fabric
+weight: 10
+---
+
+The concept of a *Fabric* encapsulates a set of cooperating [peers][].
+ All peers in a fabric can communicate and may share [services][]
+ between them, with access governed by [policies][].
+ The Fabric acts as a root of trust for peer-to-peer communications (i.e.,
+ it functions as the certificate authority enabling mutual authentication between
+ peers).
+
+Currently, the concept of a Fabric is just that - a concept. It is not represented
+ or backed by any managed resource in a ClusterLink deployment. Once a Fabric is created,
+ its only relevance is in providing a certificate for use by each peer's gateways.
+ 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 of certificates
+ between peers, out of band.
+
+## Initializing a new fabric
+
+### Prerequisites
+
+The following sections assume that you have access to the `clusterlink` CLI and one or more
+ peers (i.e., clusters) where you'll deploy ClusterLink. The CLI can be downloaded
+ from the ClusterLink [releases page on GitHub][].
+
+### Create a new fabric CA
+
+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 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
+
+Once a Fabric has been created and initialized, you can proceed with configuring
+ [peers][]. For a complete, end-to-end use case, please refer to the
+ [iperf tutorial][].
+
+[peers]: {{< relref "peers" >}}
+[services]: {{< relref "services" >}}
+[policies]: {{< relref "policies" >}}
+[releases page on GitHub]: https://github.com/clusterlink-net/clusterlink/releases/tag/{{% param git_version_tag %}}
+[iperf tutorial]: {{< relref "../tutorials/iperf" >}}

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

@@ -0,0 +1,214 @@
+---
+title: Peers
+description: Defining ClusterLink peers as part of a fabric
+weight: 20
+---
+
+A *Peer* represents a location, such as a Kubernetes cluster, participating in a
+ [fabric][]. Each peer may host one or more [services][]
+ that it may wish 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 Custom Resource (CR)][operator-cr]. They may also wish to define
+ 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
+ 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
+ done with lowered privileges (e.g., by users, such as application owners). Remote peers are
+ represented by the Peer Custom Resources (CRs). Each peer CR instance
+ defines a remote cluster and the network endpoints of its ClusterLink gateways.
+
+## Prerequisites
+
+The following sections assume that you have access to the `clusterlink` CLI and one or more
+ peers (i.e., clusters) where you'll deploy ClusterLink. The CLI can be downloaded
+ from the ClusterLink [releases page on GitHub][].
+ It also assumes that you have access to the [previously created fabric][]
+ CA files.
+
+## Initializing a new peer
+
+{{< notice warning >}}
+Creating a new peer is a **fabric administrator** level operation and should be appropriately
+ protected.
+{{< /notice >}}
+
+### Create a new peer certificate
+
+To create a new peer certificate belonging to a fabric, confirm that the fabric
+ Certificate Authority (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`).
+{{< /notice >}}
+
+This will create the certificate and private key files (`cert.pem` and
+ `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.
+
+{{< notice info >}}
+You will need the CA certificate (but **not** the CA private key) and the peer's certificate
+ and private key pair in the next step. They can be provided out of band (e.g., over email) to the
+ peer administrator or by any other means for secure transfer of sensitive data.
+{{< /notice >}}
+
+## Deploy ClusterLink to a new peer
+
+{{< notice info >}}
+This operation is typically done by a local **peer administrator**, usually different
+ than the **fabric administrator**.
+{{< /notice >}}
+
+Before proceeding, ensure that the following files (created in the previous step) are
+ available in the current working directory:
+
+ 1. CA certificate;
+ 1. peer certificate; and
+ 1. peer private key.
+
+### Install the ClusterLink deployment operator
+
+Install the ClusterLink operator by running the following command:
+
+```sh
+clusterlink deploy peer --name <peer_name> --fabric <fabric_name>
+```
+
+The command assumes that kubectl is set to the correct context and credentials
+ and that the certificates were created in respective sub-directories
+ under the current working directory.
+ If they were not, add the `--path <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.
+ The CA, peer certificate, and private key are set as K8s secrets
+ in the namespace where ClusterLink components are installed, which by default is
+ `clusterlink-system`. You can confirm the successful completion of this step
+ using the following commands:
+
+```sh
+kubectl get crds
+kubectl get secret --namespace clusterlink-system
+```
+
+{{% expand summary="Example output" %}}
+
+```sh
+$ kubectl get crds
+NAME                                       CREATED AT
+accesspolicies.clusterlink.net             2024-04-07T12:08:24Z
+exports.clusterlink.net                    2024-04-07T12:08:24Z
+imports.clusterlink.net                    2024-04-07T12:08:24Z
+instances.clusterlink.net                  2024-04-07T12:08:24Z
+peers.clusterlink.net                      2024-04-07T12:08:24Z
+privilegedaccesspolicies.clusterlink.net   2024-04-07T12:08:24Z
+
+$ kubectl get secret --namespace clusterlink-system
+NAME              TYPE     DATA   AGE
+cl-controlplane   Opaque   2      19h
+cl-dataplane      Opaque   2      19h
+cl-ca             Opaque   1      19h
+cl-peer           Opaque   1      19h
+```
+
+{{% /expand %}}
+
+### Deploy ClusterLink via the operator and ClusterLink CR
+
+After the operator is installed, you can deploy ClusterLink by applying
+ 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
+ in the same namespace.
+
+Refer to the [operator documentation][] for a description of the ClusterLink CR fields.
+
+## Add or remove peers
+
+{{< notice info >}}
+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 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
+ be configured via a management plane.
+
+{{% expand summary="Peer Custom Resource" %}}
+
+```go
+type Peer struct {
+    metav1.TypeMeta   `json:",inline"`
+    metav1.ObjectMeta `json:"metadata,omitempty"`
+
+    Spec PeerSpec `json:"spec"`
+    Status PeerStatus `json:"status,omitempty"`
+}
+
+
+type PeerSpec struct {
+    Gateways []Endpoint `json:"gateways"`
+}
+
+type PeerStatus struct {
+    Conditions []metav1.Condition `json:"conditions,omitempty"`
+}
+
+type Endpoint struct {
+    Host string `json:"host"`
+    Port uint16 `json:"port"`
+}
+```
+
+{{% /expand %}}
+
+There are two fundamental attributes in the peer CRD: the peer 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
+ during connection establishment. The name is used by importers in referencing an export
+ (see [services][] for details).
+
+Gateway endpoint would typically be implemented via a `NodePort` or `LoadBalancer`
+ 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 CR][].
+ 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" >}}
+{{% /expand %}}
+
+## 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
+ [services][] and [policies][].
+ For a complete end-to-end use case, refer to the [iperf tutorial][].
+
+[fabric]: {{< relref "fabric" >}}
+[previously created fabric]: {{< relref "fabric#create-a-new-fabric-ca" >}}
+[services]: {{< relref "services" >}}
+[policies]: {{< relref "policies" >}}
+[releases page on GitHub]: https://github.com/clusterlink-net/clusterlink/releases/tag/{{% param git_version_tag %}}
+[operator-cr]: {{< relref "../tasks/operator#deploy-cr-instance" >}}
+[operator documentation]: {{< relref "../tasks/operator#commandline-flags" >}}
+[ClusterLink CR]: {{< relref "peers#deploy-clusterlink-via-the-operator-and-clusterlink-cr" >}}
+[iperf tutorial]: {{< relref "../tutorials/iperf" >}}