nephio-project · nephio-prow · Mar 8, 2025 · Mar 7, 2025 · Mar 7, 2025
diff --git a/.vale/config/vocabularies/Nephio/accept.txt b/.vale/config/vocabularies/Nephio/accept.txt
@@ -7,14 +7,17 @@ APIs
 apiserver
 ASN
 ASNs
+apiVersion
 [Aa]utomations
 authProvider
 [Aa]utoscaling
 backtrackVal
 [Bb]ool
 [Bb]oolean
 cabundle
-[Cc]onfigMap
+[Cc]onfig
+ConfigMap
+configsync
 Codegen
 [Cc]loudified
 CNI
@@ -32,11 +35,13 @@ Dockerfile
 Docsy
 encodedVal
 [Ee]num
+[Ee]nums
 envtest
 [Ee]tcd
 [Ee]xecute
 [Ee]xecution
 Expr
+[Ff]anout
 func
 gcloud
 Gitea
@@ -57,8 +62,10 @@ JFrog
 JSON
 [Kk]pt
 [Kk]ptfile
+[Kk]ptfiles
 kubeadm
 Kubebuilder
+kubeconfig
 kubectl
 kubelet
 Kubernetes
@@ -67,6 +74,7 @@ Kustomization
 kpt fn
 kpt-fn
 Libvirt
+LVMCluster
 MacBook
 MetalLB
 [Nn]amespace
@@ -79,6 +87,7 @@ NFDeploy
 NFDeployment
 NFs
 [Mm]akefile
+[Mm]akefiles
 Multus
 [Mm]ultivendor
 [Mm]ulticloud
@@ -113,11 +122,11 @@ Postgres
 PVC
 PVCs
 [Rr]emoveKeys
-[Rp]epositorySelector
+RepositorySelector
 repoTest
 [Rr]ebase
 [Rr]pkg
-[Rr]oot[Ss]ync
+RootSync
 [Rr]ollout
 sbi
 SDK
@@ -127,7 +136,8 @@ stderr
 [Ss]udo
 [Ss]ubpackage
 SSH
-[Sp]pecializer
+[Ss]pecializer
+[Ss]pecializers
 TLS
 [Tt]riage
 [Tt]ko

diff --git a/content/en/docs/glossary-abbreviations.md b/content/en/docs/glossary-abbreviations.md
@@ -5,7 +5,7 @@ weight: 10
 ---
 
 We use many terms in our Nephio discussions, coming from different domains
-including telecom, Kubernetes, configuration management, and our own
+including telecommunications, Kubernetes, configuration management, and our own
 [Nephio-specific](#nephio-related-abbreviations) terms. This glossary is intended to help clarify our usage of
 these terms.
 
@@ -325,7 +325,7 @@ label indicating cost allocation center).
 The same value in a configuration is often used in more than one place. *Value
 propagation* is the technique of setting or generating the value once, and then
 copying (or propagating) it to different places in the configuration. For
-example, setting a Helm value in the values.yaml file, and then having it used
+example, setting a Helm value in the *values.yaml* file, and then having it used
 in multiple places across different resources.
 
 ## Variant

diff --git a/.../docs/guides/contributor-guides/helm-to-operator-codegen-sdk-developer-guide.md b/.../docs/guides/contributor-guides/helm-to-operator-codegen-sdk-developer-guide.md
@@ -89,7 +89,7 @@ A) Base-Cases:
 
 B) Composite-Cases:
 1. Slice/ Array: 
-	Iterates over each element of slice and calls the DFS fxn again with the element.
+	Iterates over each element of slice and calls the DFS function again with the element.
 	Returns the list of all backtrack-values. ([] is considered as default value)
 2. Map: 
 	Iterates over each key-value pairs, calls the DFS(value).
@@ -103,7 +103,7 @@ B) Composite-Cases:
 C) Special-Cases:
 We have assumed in the DFS function, that every path (structure) will end at the basic-data-types (string, int, bool etc), But there lies some cases when we can’t traverse further because the attributes of struct are private. Such cases are handled specially. (Converted to String and then return appropriately)
 1. V1.Time and resource.Quantity
-2. []byte/[]uint8: []byte is generally used in kind: Secret. It is seen that we provide 64base encoded secret-value in Yaml, but on converting the Yaml to runtime-obj, the secret-val automatically get decoded to actual value, Since, It is not good to show decoded/actual secret value in the code, therefore, we encode it again and store this base64-encoded-value as secret-value in JSON.
+2. []byte/[]uint8: []byte is generally used in kind: Secret. It is seen that we provide 64base encoded secret-value in YAML, but on converting the YAML to runtime-obj, the secret-val automatically get decoded to actual value, Since, It is not good to show decoded/actual secret value in the code, therefore, we encode it again and store this base64-encoded-value as secret-value in JSON.
 
 
 JSON Conversion Example

diff --git a/content/en/docs/guides/install-guides/_index.md b/content/en/docs/guides/install-guides/_index.md
@@ -42,7 +42,7 @@ We recommend that you use e2-standard-16. The minimum requirement is e2-standard
 ### Following the progress of the installation on the GCE
 
 To watch the progress of the installation, you need to allow approximately 30 seconds for Nephio to
-reach a network-accessible state. Then log in with ssh and investigate the script execution using
+reach a network-accessible state. Then log in with SSH and investigate the script execution using
 tail:
 
 ```bash
@@ -146,12 +146,12 @@ The following environment variables can be used to configure the installation:
 
 Monitor the installation on your terminal.
 
-Log on to your VM using ssh on another terminal. Use the `docker` and `kubectl` commands to monitor
+Log on to your VM using SSH on another terminal. Use the `docker` and `kubectl` commands to monitor
 the installation.
 
 ## Access to the user interfaces
 
-Once the installation is complete, log in with ssh and forward the port to the user interface (UI)
+Once the installation is complete, log in with SSH and forward the port to the user interface (UI)
 (7007) and to Gitea’s HTTP interface (3000), if desired:
 
 Using the GCE:
@@ -179,8 +179,8 @@ You can now navigate to the following URLs:
 
 ## Open terminal
 
-You may want a second ssh window open to run `kubectl` commands, and so on, without port forwarding
-(which would fail if you tried to open a second ssh connection with that setting).
+You may want a second SSH window open to run `kubectl` commands, and so on, without port forwarding
+(which would fail if you tried to open a second SSH connection with that setting).
 
 Using the GCE:
 

diff --git a/content/en/docs/guides/install-guides/common-components.md b/content/en/docs/guides/install-guides/common-components.md
@@ -14,10 +14,10 @@ This page is draft and the separation of the content to different categories is
 
 {{% alert title="Note" color="primary" %}}
 
-If you want to use a version other than that of v3.0.0 of Nephio *catalog* repo, then replace the *@origin/v3.0.0*
+If you want to use a version other than that of v3.0.0 of Nephio *catalog* repository, then replace the *@origin/v3.0.0*
 suffix on the package URLs on the `kpt pkg get` commands below with the tag/branch of the version you wish to use.
 
-While using KPT you can [either pull a branch or a tag](https://kpt.dev/book/03-packages/01-getting-a-package) from a
+While using kpt you can [either pull a branch or a tag](https://kpt.dev/book/03-packages/01-getting-a-package) from a
 git repository. By default it pulls the tag. In case, you have branch with the same name as a tag then to:
 
 ```bash

diff --git a/content/en/docs/guides/install-guides/common-dependencies.md b/content/en/docs/guides/install-guides/common-dependencies.md
@@ -15,7 +15,7 @@ installation, the CRDs that come along with them are necessary.
 If you want to use a version other than that of v3.0.0 of Nephio *catalog* repository, then replace the *@origin/v3.0.0*
 suffix on the package URLs on the `kpt pkg get` commands below with the tag/branch of the version you wish to use.
 
-While using KPT you can [either pull a branch or a tag](https://kpt.dev/book/03-packages/01-getting-a-package) from a
+While using kpt you can [either pull a branch or a tag](https://kpt.dev/book/03-packages/01-getting-a-package) from a
 git repository. By default it pulls the tag. In case, you have branch with the same name as a tag then to:
 
 ```bash

diff --git a/content/en/docs/guides/install-guides/explore-nephio-free5gc.md b/content/en/docs/guides/install-guides/explore-nephio-free5gc.md
@@ -83,7 +83,7 @@ tasks such as
 * *Common Labels*: Allows adding labels to all resources and selectors. Currently commented out.
 * *Bases*: Specifies the directories (*../crd*, *../rbac*, *../operator*) containing the base resources for the application.
   In the *crd/base* folder there are CRDs for the workload network functions. They define the schema for the
-  "XXFDeployment" resource under the "workload.nephio.org" group. Also, there are YAML config files for teaching
+  "XXFDeployment" resource under the "workload.nephio.org" group. Also, there are YAML configuration files for teaching
   kustomize how to substitute *name* and *namespace* reference in CRD.
 * *Patches Strategic Merge*: Specifies the patches that should be applied to the base resources.
   Currently includes a patch file named *manager_auth_proxy_patch.yaml*, which adds authentication protection to the

diff --git a/content/en/docs/guides/install-guides/explore-sandbox.md b/content/en/docs/guides/install-guides/explore-sandbox.md
@@ -122,7 +122,7 @@ interacts closely with.
 
 | Component          | Purpose                                                                                         |
 | ------------------ | ------------------------------------------------------------------------------------------------|
-| Porch              | Google Container Tools Package Orchestration Server, provides an API used by Nephio to work with packages in git repositries                                       |
+| Porch              | Google Container Tools Package Orchestration Server, provides an API used by Nephio to work with packages in git repositories                                       |
 | ConfigSync         | Google Container Tools Configuration Synchronization, used by Nephio to deploy configurations from repositories from the Management cluster onto Workload clusters  |
 | Nephio Controllers | The Nephio controllers, which implement the Nephio functionality to fetch, manipulate, and deploy NFs                                                        |
 | Nephio WebUI       | The Nephio web client                                                                                                                                        |

diff --git a/content/en/docs/guides/install-guides/install-on-gce.md b/content/en/docs/guides/install-guides/install-on-gce.md
@@ -37,7 +37,7 @@ e2-standard-16 is recommended and e2-standard-8 is minimum.
 ### Follow the Installation on GCE
 
 If you want to watch the progress of the installation, give it about 30
-seconds to reach a network accessible state, and then ssh in and tail the
+seconds to reach a network accessible state, and then SSH in and tail the
 startup script execution:
 
 ```bash
@@ -47,7 +47,7 @@ gcloud compute ssh ubuntu@nephio-r3-e2e -- \
 
 ## Access to the User Interfaces
 
-Once it is completed, ssh in and port forward the port to the UI (7007) and to
+Once it is completed, SSH in and port forward the port to the UI (7007) and to
 Gitea's HTTP interface, if desired (3000):
 
 ```bash
@@ -64,8 +64,8 @@ browse the Nephio Web UI
 
 ## Open Terminal
 
-You will probably want a second ssh window open to run *kubectl* commands, etc.,
-without the port forwarding (which would fail if you try to open a second ssh
+You will probably want a second SSh window open to run *kubectl* commands, etc.,
+without the port forwarding (which would fail if you try to open a second SSH
 connection with that setting).
 
 ```bash

diff --git a/content/en/docs/guides/install-guides/install-on-gcp.md b/content/en/docs/guides/install-guides/install-on-gcp.md
@@ -14,7 +14,7 @@ In this guide, you will set up Nephio with:
 - **Git Provider**: Google Cloud Source Repositories will be the git provider for cluster deployment repositories. Some
   external repositories will be on GitHub.
 - **Web UI Auth**: Google OAuth 2.0
-- **Ingress/Load Balancer**: Ingress with a GKE-specific FrontEndConfig to provide http-to-https redirection will be
+- **Ingress/Load Balancer**: Ingress with a GKE-specific FrontEndConfig to provide HTTP-to-HTTPS redirection will be
   used to access the Nephio Web UI.
 
 Additionally, this guide makes the following simplifying choices:

diff --git a/content/en/docs/guides/install-guides/package-transformations.md b/content/en/docs/guides/install-guides/package-transformations.md
@@ -170,7 +170,7 @@ metadata:
 ## porchctl rpkg for Workload clusters
 
 The `porchctl rpkg` suite of commands that act on Repository resources on the
-kubernetes cluster in scope. The packages in the Repository resources are
+Kubernetes cluster in scope. The packages in the Repository resources are
 remote packages (*rpkg*).
 
 To see which repositories are in scope:
@@ -324,7 +324,7 @@ mgmt-08c26219f9879acdefed3469f8c3cf89d5db3868 proposed
 Proposing the package changes the name of the drafts/regional/v1 to
 proposed/regional/v1. There are no changes to the content of the branch.
 
-### Approve the Package and Trigger Configsync
+### Approve the Package and Trigger Config Sync
 
 Approving the package triggers `configsync`, which triggers creation of the new
 workload cluster using all the *PackageVariant* components specified in the
@@ -340,7 +340,7 @@ The new cluster comes up after a number of minutes.
 ## Transformations in the Workload cluster creation
 
 Approving the regional Workload cluster package in the *mgmt* repository
-triggered configsync to apply the *PackageVariant* configurations in the
+triggered `configsync` to apply the *PackageVariant* configurations in the
 *mgmt/regional* package. Let's examine those *PackageVariant* configurations one
 by one.
 
@@ -361,7 +361,7 @@ workloadclusters.infra.nephio.org | nephio-system.nephio-controller     | Trigge
 The *PackageVariant* specified in *pv-cluster.yaml* is executed and:
 1. Produces a package variant of the
    [cluster-capi-kind](https://github.com/nephio-project/nephio-example-packages/tree/main/cluster-capi-kind) package
-   called lambda-cluster in the gitea *mgmt* repository on your management cluster.
+   called lambda-cluster in the Gitea *mgmt* repository on your management cluster.
 1. Applies the lambda-cluster *kpt* package to create the kind cluster for the workload cluster.
 
 #### Package transformations

diff --git a/content/en/docs/guides/user-guides/usecase-user-guides/exercise-1-free5gc.md b/content/en/docs/guides/user-guides/usecase-user-guides/exercise-1-free5gc.md
@@ -14,7 +14,7 @@ These exercises will take you from a system with only the Nephio Management clus
 
 - A Regional cluster
 - Two Edge clusters
-- Repositories for each cluster, registered with Nephio, and with Config Sync set up to pull from those repositories.
+- Repositories for each cluster, registered with Nephio, and with ConfigSync set up to pull from those repositories.
 - Inter-cluster networking between those clusters
 - A complete free5GC deployment including:
 
@@ -755,7 +755,7 @@ use our standard specialization techniques and pipeline to deploy UERANSIM, just
 
 However, before you do that, let us register the UE with free5GC as a subscriber. You will use the free5GC Web UI to do
 this. To access it, you need to open another port forwarding session. Assuming you have the *regional-kubeconfig* file
-you created earlier in your home directory, you need to establish another ssh session from your workstation to the VM,
+you created earlier in your home directory, you need to establish another SSH session from your workstation to the VM,
 port forwarding port 5000.
 
 Before moving on to the new terminal, let's copy regional-kubeconfig to the home directory:

diff --git a/content/en/docs/network-architecture/o-ran-integration.md b/content/en/docs/network-architecture/o-ran-integration.md
@@ -57,7 +57,7 @@ The O-RAN WG6 O2ims Provisioning working group has now introduced the concept of
 
 Within FOCOM a corresponding SMO-level O-Cloud Template information record is kept. The role of the FOCOM is to support integration towards multiple O-Clouds, each with its own catalog of supported O-Cloud Templates. The FOCOM O-Cloud Template information record contains a reference to the supporting O-Cloud IMS end point, the name and version of the O-Cloud Template on the O-Cloud side, a schema for the instance specific input data accepted by the O-Cloud Template, as well as the characteristics/capacity and metadata information about the O-Cloud Template.
 
-The expectation is that each O-RAN CNF vendor defines O-Cloud Templates for each O-Cloud infrastructure vendor that they plan to support, due to the need for specific tailoring of the cluster worker nodes to match the HW configuration requirements (bios settings, huge pages, SRIOV NIC configuration etc.) from specific O-RAN CNFs. These O-Cloud Templates act as a reference design to be used by each operator running their specific O-Cloud and are expected to be tailored further for each operator. The exposed information about the O-Cloud Templates are then discovered by the SMO/FOCOM component as part of the O-Cloud registration process.
+The expectation is that each O-RAN CNF vendor defines O-Cloud Templates for each O-Cloud infrastructure vendor that they plan to support, due to the need for specific tailoring of the cluster worker nodes to match the HW configuration requirements (bios settings, huge pages, SR-IOV NIC configuration etc.) from specific O-RAN CNFs. These O-Cloud Templates act as a reference design to be used by each operator running their specific O-Cloud and are expected to be tailored further for each operator. The exposed information about the O-Cloud Templates are then discovered by the SMO/FOCOM component as part of the O-Cloud registration process.
 
 ### High-Level design of SMO FOCOM using Nephio in R4