Harmonizing notes and warning texts

content/en/docs/guides/install-guides/_index.md

@@ -31,7 +31,11 @@ gcloud compute instances create --machine-type e2-standard-16 \
                                     nephio-r2-e2e
 ```
 
-**NOTE**: e2-standard-16 is recommended and e2-standard-8 is minimum. 
+{{% alert title="Note" color="primary" %}}
+
+e2-standard-16 is recommended and e2-standard-8 is minimum. 
+
+{{% /alert %}}
 
 ### Follow the Installation on GCE
 

content/en/docs/guides/install-guides/common-components.md

@@ -12,8 +12,11 @@ This page is draft and the separation of the content to different categories is
 {{% /pageinfo %}}
 
 
-> **_NOTE:_** If you want to use a version other than that at the tip of Nephio `catalog` repo, then replace the `@main` suffix on the package URLs on the `kpt pkg get` commands below with the tag of the version you wish to use.
+{{% alert title="Note" color="primary" %}}
 
+If you want to use a version other than that at the tip of Nephio `catalog` repo, then replace the `@main` suffix on the package URLs on the `kpt pkg get` commands below with the tag of the version you wish to use.
+
+{{% /alert %}}
 
 ## Porch
 

content/en/docs/guides/install-guides/common-dependencies.md

@@ -10,7 +10,11 @@ Some of these, like the resource-backend, will move out of the "required"
 category in later releases.  Even if you do not use these directly in your
 installation, the CRDs that come along with them are necessary.
 
-> **_NOTE:_** If you want to use a version other than that at the tip of Nephio `catalog` repo, then replace the `@main` suffix on the package URLs on the `kpt pkg get` commands below with the tag of the version you wish to use.
+{{% alert title="Note" color="primary" %}}
+
+If you want to use a version other than that at the tip of Nephio `catalog` repo, then replace the `@main` suffix on the package URLs on the `kpt pkg get` commands below with the tag of the version you wish to use.
+
+{{% /alert %}}
 
 ## Network Config Operator
 

content/en/docs/guides/install-guides/demo-vagrant-windows.md

@@ -44,9 +44,13 @@ But the easiest way is to force the port-forwarding as shown before:
 
 ## Notes
 
-> **Warning**: For low-end machines (less then 8T32GB), you will need to modify
+{{% alert title="Warning" color="warning" %}}
+
+For low-end machines (less then 8T32GB), you will need to modify
 the Vagrant file. This is not recommended!
 
+{{% /alert %}}
+
 - In the Vagrant file "./Vagrantfile", there are *CPUS & RAM* parameters in
   `config.vm.provider`, it's possible to override them at runtime:
   - On Linux, or the Git Bash on Windows we can use a one-liner command `CPUS=16

content/en/docs/guides/install-guides/install-on-gce.md

@@ -28,7 +28,11 @@ gcloud compute instances create --machine-type e2-standard-16 \
                                     nephio-r2-e2e
 ```
 
-**NOTE**: e2-standard-16 is recommended and e2-standard-8 is minimum. 
+{{% alert title="Note" color="primary" %}}
+
+e2-standard-16 is recommended and e2-standard-8 is minimum.
+
+{{% /alert %}}
 
 ### Follow the Installation on GCE
 

content/en/docs/guides/install-guides/install-on-gcp.md

@@ -337,9 +337,13 @@ gcloud anthos config controller create nephio-cc \
     --full-management
 ```
 
-Note that Config Controller clusters are always regional and are not available in all regions. See the link above for a
+{{% alert title="Note" color="primary" %}}
+
+The Config Controller clusters are always regional and are not available in all regions. See the link above for a
 list of available regions. The Config Controller creation may take up to fifteen minutes.
 
+{{% /alert %}}
+
 
 The output is similar to:
 
@@ -1376,10 +1380,14 @@ demonstrate how to build out Nephio-based networks on GCP.
 
 ## Next Steps
 
-Note that the exercises using free5gc rely on Multus and on the gtp5g kernel module, neither of which are installed on
+{{% alert title="Note" color="primary" %}}
+
+The exercises using free5gc rely on Multus and on the gtp5g kernel module, neither of which are installed on
 GKE nodes. Therefore, the free5gc workloads cannot be run on this installation. You will need to alter the exercises to\
 use workloads that do not rely on that functionality in order to experiment with Nephio features.
 
+{{% /alert %}}
+
 * Step through the [Free5GC](/content/en/docs/guides/user-guides/exercise-1-free5gc.md) and
 [OAI](/content/en/docs/guides/user-guides/exercise-2-oai.md) exercises
 * Dig into the [user guide](/content/en/docs/guides/user-guides/_index.md)

content/en/docs/guides/install-guides/install-on-multiple-vm.md

@@ -78,13 +78,15 @@ kpt live init <cluster-name>
 kpt live apply <cluster-name> --reconcile-timeout=15m --output=table
 ```
 
-**Note**: 
+{{% alert title="Note" color="primary" %}} 
 
 * For management cluster you have to name the repository as `mgmt`.
 * In the `repository` package by default gitea address is `172.18.0.200:3000` in `repository/set-values.yaml` 
 change this to your git address.
 * `repository/token-configsync.yaml` and `repository/token-porch.yaml` are responsible for creating secrets with the help of Nephio token controller for accessing git instance for root-sync. You would need the name of config-sync token to provide it to root-sync.
 
+{{% /alert %}}
+
 ### Install Root-sync
 
 Get the Root-sync kpt package and edit it:

content/en/docs/guides/install-guides/install-on-single-vm.md

@@ -140,7 +140,7 @@ kpt live init <cluster-name>
 kpt live apply <cluster-name> --reconcile-timeout=15m --output=table
 ```
 
-**Note**: 
+{{% alert title="Note" color="primary" %}}
 
 * For management cluster you have to name the repository as `mgmt`.
 * In the `repository` package the default Gitea address is `172.18.0.200:3000`. 
@@ -150,6 +150,8 @@ responsible for creating secrets with the help of the Nephio token controller
 for accessing the git instance for root-sync. 
 You would need the name of the config-sync token to provide it to root-sync.
 
+{{% /alert %}}
+
 ### Install Root-sync
 
 Get the Root-sync kpt package and edit it:

content/en/docs/guides/user-guides/exercise-1-free5gc.md

@@ -30,7 +30,11 @@ The network configuration is illustrated in the following figure:
 
 ![nephio-r1-5g-network.png](/static/images/user-guides/nephio-r1-5g-network.png)
 
-Note that for simplicity, only one edge cluster is represented.
+{{% alert title="Note" color="primary" %}}
+
+For simplicity, only one edge cluster is represented.
+
+{{% /alert %}}
 
 Additionally, you can use Nephio to change the capacity requirement for the UPF and SMF NFs and see how the free5GC
 operator translates that into increased memory and CPU requirements for the underlying workload.
@@ -52,8 +56,13 @@ Management cluster via Nephio; the mgmt-staging repository is just used internal
 process.
 
 Use the session just started on the VM to run these commands:
-(Note: After fresh `docker` install, verify `docker` supplementary group is loaded by executing `id | grep docker`.
-If not, logout and login to the VM or execute the `newgrp docker` to ensure the `docker` supplementary group is loaded.)
+
+{{% alert title="Note" color="primary" %}}
+
+After fresh `docker` install, verify `docker` supplementary group is loaded by executing `id | grep docker`.
+If not, logout and login to the VM or execute the `newgrp docker` to ensure the `docker` supplementary group is loaded.
+
+{{% /alert %}}
 
 ```bash
 kubectl get repositories
@@ -818,9 +827,11 @@ PING 172.0.0.1 (172.0.0.1) from 10.1.0.2 uesimtun0: 56(84) bytes of data.
 rtt min/avg/max/mdev = 6.280/7.586/8.896/1.011 ms
 ```
 
+{{% alert title="Note" color="primary" %}}
 
+Our DNN does not actually provide access to the internet, so you won't be able to reach the other sites.
 
-Note that our DNN does not actually provide access to the internet, so you won't be able to reach the other sites.
+{{% /alert %}}
 
 ## Step 9: Change the Capacities of the UPF and SMF NFs
 

content/en/docs/guides/user-guides/exercise-2-oai.md

@@ -48,8 +48,13 @@ Management cluster via Nephio; the mgmt-staging repository is just used internal
 process.
 
 Use the session just started on the VM to run these commands:
-(Note: After fresh `docker` install, verify `docker` supplementary group is loaded by executing `id | grep docker`.
-If not, logout and login to the VM or execute the `newgrp docker` to ensure the `docker` supplementary group is loaded.)
+
+{{% alert title="Note" color="primary" %}}
+
+After fresh `docker` install, verify `docker` supplementary group is loaded by executing `id | grep docker`.
+If not, logout and login to the VM or execute the `newgrp docker` to ensure the `docker` supplementary group is loaded.
+
+{{% /alert %}}
 
 ```bash
 kubectl get repositories

content/en/docs/guides/user-guides/helm/flux-helm.md

@@ -51,7 +51,11 @@ Click through the `Next` button until you are through all the steps, leaving all
 At this point, we can take a closer look at the contents of the kpt package which contains the relevant kubernetes
 resources to deploy the controllers.
 
-**_NOTE:_**  We are deploying into the `flux-system` namespace by default.
+{{% alert title="Note" color="primary" %}}
+
+We are deploying into the `flux-system` namespace by default.
+
+{{% /alert %}}
 
 Finally, we need to `propose` and then `approve` the pkg to initialize the deployment.
 
@@ -123,9 +127,13 @@ source repo and the package to be deployed.
 
 ![Add acm pkg](/static/images/user-guides/add-deploy-onlinebout-select.png)
 
-**_NOTE:_**  The overrides online-boutique-values ConfigMap in the package refers to the default values.yaml for the
+{{% alert title="Note" color="primary" %}}
+
+The overrides online-boutique-values ConfigMap in the package refers to the default values.yaml for the
 chart and can be customized prior to pkg approval.
 
+{{% /alert %}}
+
 Shortly thereafter, you should see the online boutique components deployed in the online-boutique namespace:
 
 ```bash

content/en/docs/porch/contribturos-guide/dev-process.md

@@ -34,7 +34,12 @@ The simplest way to run the porch API server is to launch it in a VSCode IDE, as
 1. Open the `porch.code-workspace` file in the root of the porch git repo.
 
 1. Edit your local `.vscode/launch.json` file as follows: Change the `--kubeconfig` argument of the `Launch Server` configuration to point to a KUBECONFIG file that is set to the kind cluster as the current context. 
-  > **_NOTE:_**  If your current KUBECONFIG environment variable already points to the porch-test kind cluster, then you don't have to touch anything.
+
+{{% alert title="Note" color="primary" %}}
+
+  If your current KUBECONFIG environment variable already points to the porch-test kind cluster, then you don't have to touch anything.
+
+  {{% /alert %}}
 
 1. Launch the Porch server locally in VSCode by selecting the "Launch Server" configuration on the VSCode "Run and Debug" window. For more information please refer to the [VSCode debugging documentation](https://code.visualstudio.com/docs/editor/debugging).
 

content/en/docs/porch/contribturos-guide/environment-setup.md

@@ -45,9 +45,14 @@ Porch.
 
 The [`./scripts/setup-dev-env.sh`](https://github.com/nephio-project/porch/blob/main/scripts/setup-dev-env.sh) setup
 script automatically builds a porch development environment.
-Please note that this is only one of many possible ways of building a working porch development environment so feel free
+
+{{% alert title="Note" color="primary" %}}
+
+This is only one of many possible ways of building a working porch development environment so feel free
 to customize it to suit your needs.
 
+{{% /alert %}}
+
 The setup script will perform the following steps:
 
 1. Install a kind cluster. The name of the cluster is read from the PORCH_TEST_CLUSTER environment variable, otherwise

content/en/docs/porch/package-variant.md

@@ -91,11 +91,14 @@ The simple clone operation is shown in *Figure 1*.
 | :---: | :---: |
 | *Figure 1: Basic Package Cloning* | *Legend* |
 
+{{% alert title="Note" color="primary" %}}
 
-Note that *proposal* and *approval* are not handled by the package variant controller. Those are left to humans or other
+*Proposal* and *approval* are not handled by the package variant controller. Those are left to humans or other
 controllers. The exception is the proposal of deletion (there is no concept of a "Draft" deletion), which the package
 variant control will do, depending upon the specified deletion policy.
 
+{{% /alert %}}
+
 ### PackageRevision Metadata
 
 The package variant controller utilizes Porch APIs. This means that it is not just doing a `clone` operation, but in
@@ -180,12 +183,15 @@ protocol for facilitating this dance:
 | :---: |
 | *Figure 4: Configuration Injection* |
 
+{{% alert title="Note" color="primary" %}}
 
-Note that because we are injecting data *from the Kubernetes cluster*, we can also monitor that data for changes. For
+Because we are injecting data *from the Kubernetes cluster*, we can also monitor that data for changes. For
 each resource we inject, the package variant controller will establish a Kubernetes "watch" on the resource (or perhaps
 on the collection of such resources). A change to that resource will result in a new Draft package with the updated
 configuration injected.
 
+{{% /alert %}}
+
 There are a number of additional details that will be described in the detailed design below, along with the specific
 API definition.
 
@@ -375,10 +381,14 @@ When creating or updating a package, the package variant controller will ensure
 - All of the key-value pairs in `spec.packageContext.data` exist in the `data` field of the ConfigMap.
 - None of the keys listed in `spec.packageContext.removeKeys` exist in the ConfigMap.
 
-Note that if a user adds a key via PackageVariant, then changes the PackageVariant to no longer add that key, it will
+{{% alert title="Note" color="primary" %}}
+
+If a user adds a key via PackageVariant, then changes the PackageVariant to no longer add that key, it will
 NOT be removed automatically, unless the user also lists the key in the `removeKeys` list. This avoids the need to track
 which keys were added by PackageVariant.
 
+{{% /alert %}}
+
 Similarly, if a user manually adds a key in the downstream that is also listed in the `removeKeys` field, the package
 variant controller will remove that key the next time it needs to update the downstream package. There will be no
 attempt to coordinate "ownership" of these keys.
@@ -538,12 +548,16 @@ package, it is considered an error and should prevent generation of the Draft:
 
 This will result in the condition `Ready` being set to `False`.
 
-Note that whether or not all `required` injection points are fulfilled does not affect the *PackageVariant* conditions,
+{{% alert title="Note" color="primary" %}}
+
+Whether or not all `required` injection points are fulfilled does not affect the *PackageVariant* conditions,
 only the *PackageRevision* conditions.
 
+{{% /alert %}}
+
 **A Further Note on Selectors**
 
-Note that by allowing the use of GVK, not just name, in the selector, more precision in selection is enabled. This is a
+By allowing the use of GVK, not just name, in the selector, more precision in selection is enabled. This is a
 way to constrain the injections that will be done. That is, if the package has 10 different objects with
 `config-injection` annotation, the PackageVariant could say it only wants to replace certain GVKs, allowing better
 control.

content/en/docs/porch/running-porch/running-locally.md

@@ -61,9 +61,13 @@ This will:
 * build Porch binary and run it locally
 * configure Porch as the extension apiserver
 
-**Note:** this command does not build and start the Porch k8s controllers. Those
+{{% alert title="Note" color="primary" %}}
+
+This command does not build and start the Porch k8s controllers. Those
 are not required for basic package orchestration but are required for deploying packages.
 
+{{% /alert %}}
+
 You can also run the commands individually which can be useful when developing,
 in particular building and running Porch extension apiserver.
 

content/en/docs/porch/using-porch/install-and-using-porch.md

@@ -1832,7 +1832,7 @@ file. In this PackageVariant, the `network-function-auto-namespace` package in t
 `edge1` repo as the `network-function-auto-namespace-x` and `network-function-auto-namespace-y` package variants,
 similar to the PackageVariant in `simple-variant.yaml`.
 
-Here note the extra `template` section provided for the repositories in the PackageVariant:
+An extra `template` section provided for the repositories in the PackageVariant:
 
 ```yaml
 template:
@@ -1872,7 +1872,11 @@ management-f9a6f2802111b9e81c296422c03aae279725f6df            network-function-
 management-c97bc433db93f2e8a3d413bed57216c2a72fc7e3            network-function-auto-namespace                  v1                 v1         true     Published   management
 ```
 
-Note that the suffix `x-cumulonimbus` and `y-cumulonimbus` has been palced on the package names.
+{{% alert title="Note" color="primary" %}}
+
+The suffix `x-cumulonimbus` and `y-cumulonimbus` has been palced on the package names.
+
+{{% /alert %}}
 
 Examine the `edge1` repo on Giea and you should see two new draft branches.
 
@@ -1888,7 +1892,7 @@ In these packages, you will see that:
 3. The PackageVariant has set the `data.name` field as `network-function-auto-namespace-x-cumulonimbus` and
    `network-function-auto-namespace-y-cumulonimbus` respectively in the `pckage-context.yaml` files
 
-Note that this has all been performed automatically; weh have not had to perform the
+This has all been performed automatically; we have not had to perform the
 `porchctl rpkg pull/kpt fn render/porchctl rpkg push` combination of commands to make these chages as we had to in the
 `simple-variant.yaml` case above.
 

content/en/docs/porch/using-porch/usage-porch-kpt-cli.md

@@ -50,11 +50,15 @@ Porch server manages the following resources:
 4. `functions`: function resource represents a KRM function discovered in a repository registered with Porch. Functions
    are only supported with OCI repositories.
 
-Note that `packagerevisions` and `packagerevisionresources` represent different _views_ of the same underlying KRM
+{{% alert title="Note" color="primary" %}}
+
+`packagerevisions` and `packagerevisionresources` represent different _views_ of the same underlying KRM
 configuration package. `packagerevisions` represents the package metadata, and `packagerevisionresources` represents the
 package content. The matching resources share the same `name` (as well as API group and version:
 `porch.kpt.dev/v1alpha1`) and differ in resource kind (`PackageRevision` and `PackageRevisionResources` respectively).
 
+{{% /alert %}}
+
 ## Repository Registration
 
 To use Porch with a Git repository, you will need: