diff --git a/content/en/docs/guides/install-guides/common-components.md b/content/en/docs/guides/install-guides/common-components.md index b8d7f9f0..f61ac08a 100644 --- a/content/en/docs/guides/install-guides/common-components.md +++ b/content/en/docs/guides/install-guides/common-components.md @@ -88,11 +88,11 @@ kpt live apply nephio-operator --reconcile-timeout=15m --output=table ## Management Cluster GitOps Tool -A GitOps tool (ConfigSync) is installed to allow GitOps-based application of packages on the management cluster itself. +A GitOps tool (configsync) is installed to allow GitOps-based application of packages on the management cluster itself. It is not needed if you only want to provision network functions, but it is used extensively in the cluster provisioning workflows. -Different GitOps tools may be used, but these instructions only cover ConfigSync. +Different GitOps tools may be used, but these instructions only cover configsync. To install it on the management cluster, we again follow the same process. Later, we will configure it to point to the *mgmt* repository: diff --git a/content/en/docs/guides/install-guides/explore-sandbox.md b/content/en/docs/guides/install-guides/explore-sandbox.md index 0a62407f..52c2d7d6 100644 --- a/content/en/docs/guides/install-guides/explore-sandbox.md +++ b/content/en/docs/guides/install-guides/explore-sandbox.md @@ -38,7 +38,7 @@ the cluster using the `kpt live status` command on the unpacked packages in the The rendered *kpt* packages containing components are unpacked in the */tmp/kpt-pkg* directory. The rendered *kpt* packages that create the *mgmt* and *mgmt-staging* repositories are unpacked in the */tmp/repository* directory. The rendered *kpt* -package containing the *rootsync* configuration for the *mgmt* repository is unpacked in the */tmp/rootsync* directory. +package containing the *RootSync* configuration for the *mgmt* repository is unpacked in the */tmp/rootsync* directory. You can examine the contents of any rendered *kpt* packager by examining the contents of these directories. ```bash @@ -123,7 +123,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 repositories | -| ConfigSync | Google Container Tools Configuration Synchronization, used by Nephio to deploy configurations from repositories from the Management cluster onto Workload clusters | +| 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 index 454c0829..dd59420b 100644 --- a/content/en/docs/guides/install-guides/install-on-gce.md +++ b/content/en/docs/guides/install-guides/install-on-gce.md @@ -64,7 +64,7 @@ browse the Nephio Web UI ## Open Terminal -You will probably want a second SSh window open to run *kubectl* commands, etc., +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). diff --git a/content/en/docs/guides/install-guides/install-on-gcp.md b/content/en/docs/guides/install-guides/install-on-gcp.md index 9ea70aab..e12ce973 100644 --- a/content/en/docs/guides/install-guides/install-on-gcp.md +++ b/content/en/docs/guides/install-guides/install-on-gcp.md @@ -508,7 +508,7 @@ Project [your-nephio-project-id] repository [config-control] was cloned to [/hom Before you start adding things to that repository, set up Config Sync to pull configurations from there by creating a -rootsync in Config Controller. There is a package available to help properly configure the rootsync: +RootSync in Config Controller. There is a package available to help properly configure the RootSync: ```bash kpt pkg get --for-deployment https://github.com/nephio-project/catalog.git/distros/gcp/cc-rootsync@main @@ -585,7 +585,7 @@ Successfully executed 2 function(s) in 1 package(s). In the sandbox exercises, you may have used `kpt live apply` to apply the package at this point. In this case, there are restrictions in Config Controller that interfere with the operation of `kpt live`. So, instead, you can just directly -apply the rootsync resources with `kubectl`: +apply the RootSync resources with `kubectl`: ```bash kubectl apply -f cc-rootsync/rootsync.yaml diff --git a/content/en/docs/guides/user-guides/_index.md b/content/en/docs/guides/user-guides/_index.md index 9ac94e29..e73897e4 100644 --- a/content/en/docs/guides/user-guides/_index.md +++ b/content/en/docs/guides/user-guides/_index.md @@ -77,15 +77,15 @@ refer to [Kpt book](https://kpt.dev/book/). those supported by the kpt CLI, but makes them available as a Kubernetes service. For more details refer to [Porch user guide](https://kpt.dev/guides/porch-user-guide). -### ConfigSync +### configsync -Config Sync lets cluster operators and platform administrators deploy consistent configurations and policies. You can +configsync lets cluster operators and platform administrators deploy consistent configurations and policies. You can deploy these configurations and policies to individual Kubernetes clusters, multiple clusters that can span hybrid and multi-cloud environments, and multiple namespaces within clusters. This process simplifies and automates configuration -and policy management at scale. Config Sync also lets development teams independently manage their namespaces within +and policy management at scale. configsync also lets development teams independently manage their namespaces within clusters, while still being subject to policy guardrails set by administrators. -Config Sync is an open-source project and the source and releases available +configsync is an open-source project and the source and releases available [here](https://www.github.com/GoogleContainerTools/kpt-config-sync). ### Packages @@ -200,7 +200,7 @@ The diagram below depicts deployment at the high level. #### Infrastructure Components * Porch -* ConfigSync +* configsync #### Nephio Controllers * Nephio Controller Operator @@ -225,7 +225,7 @@ The diagram below depicts deployment at the high level. ### Workload Cluster Components #### Infrastructure Components -* ConfigSync +* configsync #### Nephio Controllers * Watcher agent @@ -243,7 +243,7 @@ The diagram below depicts deployment at the high level. ## Management Cluster Details * Role -* Infrastructure components (Porch, ConfigSync) +* Infrastructure components (Porch, configsync) * Components * Specializes * Injectors @@ -254,7 +254,7 @@ The diagram below depicts deployment at the high level. * Web UI ## Workload Cluster Details -* Infrastructure components (ConfigSync) +* Infrastructure components (configsync) * Operators * Controllers 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 index db0a04fc..a9da43a1 100644 --- 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 ConfigSync 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: @@ -196,7 +196,7 @@ mgmt-08c26219f9879acdefed3469f8c3cf89d5db3868 approved ``` -ConfigSync running in the Management cluster will now pull out this new package, create all the resources necessary to +configsync running in the Management cluster will now pull out this new package, create all the resources necessary to provision a KinD cluster, and register it with Nephio. This will take about five minutes or so. ## Step 2: Check the Regional cluster installation diff --git a/content/en/docs/guides/user-guides/usecase-user-guides/exercise-2-oai.md b/content/en/docs/guides/user-guides/usecase-user-guides/exercise-2-oai.md index 2649e0c7..47a3926e 100644 --- a/content/en/docs/guides/user-guides/usecase-user-guides/exercise-2-oai.md +++ b/content/en/docs/guides/user-guides/usecase-user-guides/exercise-2-oai.md @@ -97,7 +97,7 @@ It will take around 15 minutes to create the three clusters. You can check the p *mgmt* and *mgmt-staging* repository. After couple of minutes you should see three independent repositories (Core, Regional and Edge) for each workload cluster. -You can also look at the state of packagerevisions for the three packages. You can use the below command +You can also look at the state of PackageRevisions for the three packages. You can use the below command ```bash kubectl get packagerevisions | grep -E 'core|regional|edge' | grep mgmt diff --git a/content/en/docs/guides/user-guides/usecase-user-guides/exercise-3-fluxcd-wl.md b/content/en/docs/guides/user-guides/usecase-user-guides/exercise-3-fluxcd-wl.md index 000704ad..581eba49 100644 --- a/content/en/docs/guides/user-guides/usecase-user-guides/exercise-3-fluxcd-wl.md +++ b/content/en/docs/guides/user-guides/usecase-user-guides/exercise-3-fluxcd-wl.md @@ -107,7 +107,7 @@ Sample output: packagevariant.config.porch.kpt.dev/flux-regional-cluster created ``` -ConfigSync running in the Management cluster will create all the resources necessary to +configsync running in the Management cluster will create all the resources necessary to provision a KinD cluster, and register it with Nephio. This can take some time. ## Step 2: Check the cluster installation @@ -239,8 +239,8 @@ Sample output: } ``` As you can see, it *sourceRef* references the *regional* GitRepository CR and defaults to the root *path* of the repository. -It also holds a reference to the *kubeConfig* Secret used to access the Workload Cluster, which was created -during the cluster api instantiation. +It also holds a reference to the *kubeconfig* Secret used to access the Workload Cluster, which was created +during the cluster API instantiation. ## Step 4: Deploy a sample workload to the Cluster diff --git a/content/en/docs/guides/user-guides/usecase-user-guides/exercise-4-o2ims.md b/content/en/docs/guides/user-guides/usecase-user-guides/exercise-4-o2ims.md index 30fb1671..3536f4f2 100644 --- a/content/en/docs/guides/user-guides/usecase-user-guides/exercise-4-o2ims.md +++ b/content/en/docs/guides/user-guides/usecase-user-guides/exercise-4-o2ims.md @@ -10,7 +10,7 @@ weight: 2 - A Nephio Management cluster: - [installation guides](/content/en/docs/guides/install-guides/_index.md) for detailed environment options. -- The following *optional* operator pkg deployed: +- The following *optional* operator package deployed: - [o2ims operator](/content/en/docs/guides/install-guides/optional-components.md#o2ims-operator) {{% alert title="Note" color="primary" %}} diff --git a/content/en/docs/network-architecture/o-ran-integration.md b/content/en/docs/network-architecture/o-ran-integration.md index ed244792..fec5ff93 100644 --- a/content/en/docs/network-architecture/o-ran-integration.md +++ b/content/en/docs/network-architecture/o-ran-integration.md @@ -61,14 +61,14 @@ The expectation is that each O-RAN CNF vendor defines O-Cloud Templates for each ### High-Level design of SMO FOCOM using Nephio in R4 -A FOCOM service implementation based on Nephio enablers uses a KPT-based cluster package management solution where: +A FOCOM service implementation based on Nephio enablers uses a Kpt-based cluster package management solution where: -- The stored O-Cloud Template information in FOCOM is realized by a Git based cluster template repository where each O-Cloud Template information record is realized with a KPT package blueprint -- Each FOCOM O-Cloud Template KPT package blueprint refer one-to-one to a corresponding IMS-side O-Cloud Template in a specific O-Cloud IMS +- The stored O-Cloud Template information in FOCOM is realized by a Git based cluster template repository where each O-Cloud Template information record is realized with a Kpt package blueprint +- Each FOCOM O-Cloud Template Kpt package blueprint refer one-to-one to a corresponding IMS-side O-Cloud Template in a specific O-Cloud IMS -The Nephio based FOCOM implementation will use the Porch NBI for deployment of O-Cloud Node Clusters based on the O-Cloud Template. To trigger creation of a new Node Cluster, the applicable O-Cloud Template KPT package blueprint will be cloned into a new draft for a Node Cluster Provisioning Request instance package. Every O-Cloud Template KPT package blueprint will contain two manifest files, one with the O-Cloud Template information and one for a FOCOM Provisioning Request that will carry the instance specific input and be used by FOCOM to generate the O2ims Provisioning Request. Once the draft Provisioning Request instance package has been created the client shall update the FOCOM Provisioning Request manifest file inside the package to add the instance specific input. Finally the client will propose and approve the Provisioning Request instance package and this will trigger FOCOM to start the reconciliation process for the O2ims Provisioning Request towards the O-Cloud IMS. +The Nephio based FOCOM implementation will use the Porch NBI for deployment of O-Cloud Node Clusters based on the O-Cloud Template. To trigger creation of a new Node Cluster, the applicable O-Cloud Template Kpt package blueprint will be cloned into a new draft for a Node Cluster Provisioning Request instance package. Every O-Cloud Template Kpt package blueprint will contain two manifest files, one with the O-Cloud Template information and one for a FOCOM Provisioning Request that will carry the instance specific input and be used by FOCOM to generate the O2ims Provisioning Request. Once the draft Provisioning Request instance package has been created the client shall update the FOCOM Provisioning Request manifest file inside the package to add the instance specific input. Finally the client will propose and approve the Provisioning Request instance package and this will trigger FOCOM to start the reconciliation process for the O2ims Provisioning Request towards the O-Cloud IMS. -Each O-Cloud Template KPT package blueprint will contain a reference to the id of the O-Cloud where this O-Cloud template is supported. Each O-Cloud has been previously registered in FOCOM, in the Nephio R4 implementation this is supported with a separate O-Cloud Registration CR that is manually created in the FOCOM Nephio management cluster. In coming Nephio releases this will be done as part of the O-Cloud registration user story. +Each O-Cloud Template Kpt package blueprint will contain a reference to the id of the O-Cloud where this O-Cloud template is supported. Each O-Cloud has been previously registered in FOCOM, in the Nephio R4 implementation this is supported with a separate O-Cloud Registration CR that is manually created in the FOCOM Nephio management cluster. In coming Nephio releases this will be done as part of the O-Cloud registration user story. ![focom1.png](/static/images/network-architecture/o-ran/focom1.png) diff --git a/content/en/docs/porch/contributors-guide/_index.md b/content/en/docs/porch/contributors-guide/_index.md index 02316190..bae9fa65 100644 --- a/content/en/docs/porch/contributors-guide/_index.md +++ b/content/en/docs/porch/contributors-guide/_index.md @@ -25,7 +25,7 @@ Porch comprises of several software components: handlers, Porch `main` function * [engine](https://github.com/nephio-project/porch/tree/main/pkg/engine): Core logic of Package Orchestration - operations on package contents -* [func](https://github.com/nephio-project/porch/tree/main/func): KRM function evaluator microservice; exposes gRPC API +* [func](https://github.com/nephio-project/porch/tree/main/func): KRM function evaluator microservice; exposes GRPC API * [repository](https://github.com/nephio-project/porch/blob/main/pkg/repository): Repository integration package * [git](https://github.com/nephio-project/porch/tree/main/pkg/externalrepo/git): Integration with Git repository. * [oci](https://github.com/nephio-project/porch/tree/main/pkg/externalrepo/oci): Integration with OCI repository. @@ -69,7 +69,7 @@ Follow the [Running Porch Locally](../running-porch/running-locally.md) guide to ## Debugging To debug Porch, run Porch locally [running-locally.md](../running-porch/running-locally.md), exit porch server running -in the shell, and launch Porch under the debugger. VSCode debug session is pre-configured in +in the shell, and launch Porch under the debugger. VS Code debug session is pre-configured in [launch.json](https://github.com/nephio-project/porch/blob/main/.vscode/launch.json). Update the launch arguments to your needs. @@ -91,7 +91,7 @@ Some useful code pointers: All tests can be run using `make test`. Individual tests can be run using `go test`. End-to-End tests assume that Porch instance is running and `KUBECONFIG` is configured with the instance. The tests will automatically detect whether they are running against -Porch running on local machien or k8s cluster and will start Git server appropriately, +Porch running on local machine or k8s cluster and will start Git server appropriately, then run test suite against the Porch instance. ## Makefile Targets @@ -112,5 +112,5 @@ then run test suite against the Porch instance. ## VS Code [VS Code](https://code.visualstudio.com/) works really well for editing and debugging. -Just open VSCode from the root folder of the Porch repository and it will work fine. The folder contains the needed +Just open VS Code from the root folder of the Porch repository and it will work fine. The folder contains the needed configuration to Launch different functions of Porch. diff --git a/content/en/docs/porch/contributors-guide/dev-process.md b/content/en/docs/porch/contributors-guide/dev-process.md index 6401b3b7..06a40dce 100644 --- a/content/en/docs/porch/contributors-guide/dev-process.md +++ b/content/en/docs/porch/contributors-guide/dev-process.md @@ -174,8 +174,8 @@ E2E=1 go test -v ./test/e2e/cli -run TestPorch/rpkg-lifecycle ``` -To run the end to end tests on your local machine towards a Porch server running in VSCode, be aware of the following if the tests are not running: -- Set the actual load balancer IP address for the function runner in your "launch.json", for example +To run the end to end tests on your local machine towards a Porch server running in VS Code, be aware of the following if the tests are not running: +- Set the actual load balancer IP address for the function runner in your *launch.json*, for example "--function-runner=172.18.255.201:9445" - Clear the git cache of your Porch workspace before every test run, for example `rm -fr /.cache/git/*` diff --git a/content/en/docs/porch/contributors-guide/environment-setup-vm.md b/content/en/docs/porch/contributors-guide/environment-setup-vm.md index be86ec42..31fe187d 100644 --- a/content/en/docs/porch/contributors-guide/environment-setup-vm.md +++ b/content/en/docs/porch/contributors-guide/environment-setup-vm.md @@ -120,7 +120,7 @@ You have now set up the VM so that it can be used for remove debugging of Porch. Use the [VS Code Remote SSH] (https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh) -plugin to To debug from VS Code running on your local machine towards a VM. Detailed documentation +plugin to debug from VS Code running on your local machine towards a VM. Detailed documentation on the plugin and its use is available on the [Remote Development using SSH](https://code.visualstudio.com/docs/remote/ssh) in the VS Code documentation. @@ -128,7 +128,7 @@ documentation. 1. Use the **Connect to a remote host** instructions on the [Remote Development using SSH](https://code.visualstudio.com/docs/remote/ssh) page to connect to your VM. -2. Click **Open Folder** and browse to the Porch code on the vm, */home/ubuntu/git/github/nephio-project/porch* in this +2. Click **Open Folder** and browse to the Porch code on the VM, */home/ubuntu/git/github/nephio-project/porch* in this case: ![Browse to Porch code](/static/images/porch/contributor/01_VSCodeOpenPorchFolder.png) diff --git a/content/en/docs/porch/contributors-guide/environment-setup.md b/content/en/docs/porch/contributors-guide/environment-setup.md index 847a30cb..90d42c15 100644 --- a/content/en/docs/porch/contributors-guide/environment-setup.md +++ b/content/en/docs/porch/contributors-guide/environment-setup.md @@ -90,7 +90,7 @@ See more advanced variants of this command in the [detailed description of the d At this point you are basically ready to start developing porch, but before you start it is worth checking that everything works as expected. -### Check that the apiservice is ready +### Check that the APIservice is ready ```bash kubectl get apiservice v1alpha1.porch.kpt.dev diff --git a/content/en/docs/porch/function-runner-pod-templates.md b/content/en/docs/porch/function-runner-pod-templates.md index 95db680f..67472454 100644 --- a/content/en/docs/porch/function-runner-pod-templates.md +++ b/content/en/docs/porch/function-runner-pod-templates.md @@ -26,7 +26,7 @@ The following contract needs to be fulfilled by any function evaluator pod templ ## Enabling pod templating on function runner A ConfigMap with the pod template should be created in the namespace where the porch-fn-runner pod is running. -The configMap's name should be included as `--function-pod-template` in the command line arguments in the pod spec of the function runner. +The ConfigMap's name should be included as `--function-pod-template` in the command line arguments in the pod spec of the function runner. ```yaml ... diff --git a/content/en/docs/porch/package-orchestration.md b/content/en/docs/porch/package-orchestration.md index 08bbdbdf..bb4ea923 100644 --- a/content/en/docs/porch/package-orchestration.md +++ b/content/en/docs/porch/package-orchestration.md @@ -71,7 +71,7 @@ At the high level, the Core CaD functionality comprises: * package discovery, authoring and lifecycle management * [porchctl](user-guides/porchctl-cli-guide.md) - a Git-native, schema-aware, extensible client-side tool for managing KRM packages -* a GitOps-based deployment mechanism (for example [ConfigSync][]), which distributes and deploys configuration, and +* a GitOps-based deployment mechanism (for example [configsync][]), which distributes and deploys configuration, and provides observability of the status of deployed resources * a task-specific UI supporting repository management, package discovery, authoring, and lifecycle @@ -83,7 +83,7 @@ Concepts briefly introduced above are elaborated in more detail in this section. ### Repositories -Porch and [ConfigSync][] currently integrate with [git][] repositories, and there is an existing design to add OCI +Porch and [configsync][] currently integrate with [git][] repositories, and there is an existing design to add OCI support to kpt. Initially, the Package Orchestration service will prioritize integration with [git][], and support for additional repository types may be added in the future as required. @@ -128,19 +128,19 @@ cloned. If a new version of the upstream package becomes available, the upstream The deployment mechanism is responsible for deploying configuration packages from a repository and affecting the live state. Because the configuration is stored in standard repositories (Git, and in the future OCI), the deployment -component is pluggable. By default, [ConfigSync][] is the deployment mechanism used by CaD Core implementation but +component is pluggable. By default, [configsync][] is the deployment mechanism used by CaD Core implementation but others can be used as well. Here we highlight some key attributes of the deployment mechanism and its integration within the CaD Core: * _Published_ packages in a deployment repository are considered ready to be deployed -* ConfigSync supports deploying individual packages and whole repositories. For Git specifically that translates to a - requirement to be able to specify repository, branch/tag/ref, and directory when instructing ConfigSync to deploy a +* configsync supports deploying individual packages and whole repositories. For Git specifically that translates to a + requirement to be able to specify repository, branch/tag/ref, and directory when instructing configsync to deploy a package. -* _Draft_ packages need to be identified in such a way that ConfigSync can easily avoid deploying them. -* ConfigSync needs to be able to pin to specific versions of deployable packages in order to orchestrate rollouts and +* _Draft_ packages need to be identified in such a way that configsync can easily avoid deploying them. +* configsync needs to be able to pin to specific versions of deployable packages in order to orchestrate rollouts and rollbacks. This means it must be possible to GET a specific version of a package. -* ConfigSync needs to be able to discover when new versions are available for deployment. +* configsync needs to be able to discover when new versions are available for deployment. ## Package Orchestration - Porch @@ -181,8 +181,8 @@ The package discovery functionality of Package Orchestration service enables the * enumerate _upstream_ packages available for creating (cloning) a _downstream_ package * identify downstream packages that need to be upgraded after a change is made to an upstream package * identify all deployment-ready packages in a deployment repository that are ready to be synced to a deployment target - by ConfigSync -* identify new versions of packages in a deployment repository that can be rolled out to a deployment target by ConfigSync + by configsync +* identify new versions of packages in a deployment repository that can be rolled out to a deployment target by configsync ### Package Authoring @@ -253,7 +253,7 @@ perform in order to satisfy requirements of the basic roles. For example, only p The Package Orchestration service, **Porch** is designed to be hosted in a [Kubernetes](https://kubernetes.io/) cluster. -The overall architecture is shown below, and includes also existing components (k8s apiserver and ConfigSync). +The overall architecture is shown below, and includes also existing components (k8s apiserver and configsync). ![Porch Architecture](/static/images/porch/Porch-Architecture.svg) @@ -368,8 +368,8 @@ Find the Porch User Guide in a dedicated __Not Yet Resolved__ -Cross-cluster rollouts and orchestration of deployment activity. For example, package deployed by ConfigSync in cluster -A, and only on success, the same (or a different) package deployed by ConfigSync in cluster B. +Cross-cluster rollouts and orchestration of deployment activity. For example, package deployed by configsync in cluster +A, and only on success, the same (or a different) package deployed by configsync in cluster B. ## Alternatives Considered diff --git a/content/en/docs/porch/package-variant.md b/content/en/docs/porch/package-variant.md index 66766336..27312c2f 100644 --- a/content/en/docs/porch/package-variant.md +++ b/content/en/docs/porch/package-variant.md @@ -538,7 +538,7 @@ With that understanding, the injection process works as follows: - An annotation with name *kpt.dev/injected-resource-name* and value set to the name of the in-cluster resource is added (or overwritten) in the in-package resource. -If the the overall injection cannot be completed for some reason, or if any of the below problems exist in the upstream +If the overall injection cannot be completed for some reason, or if any of the below problems exist in the upstream package, it is considered an error and should prevent generation of the Draft: - There is a resource annotated as an injection point but having an invalid annotation value (i.e., other than @@ -1020,7 +1020,7 @@ spec: When using other targeting means, the use of the Expr fields becomes more likely, because we have more possible sources for different field values. The Expr values are all [Common Expression Language (CEL)](https://github.com/google/cel-go) expressions, rather than static values. This allows -the user to construct values based upon various fields of the targets. Consider again the repositorySelector example, +the user to construct values based upon various fields of the targets. Consider again the RepositorySelector example, where we have these repositories in the cluster. | Repository | Labels | diff --git a/content/en/docs/porch/running-porch/running-on-GKE.md b/content/en/docs/porch/running-porch/running-on-GKE.md index 217c6cc3..26c49e4b 100644 --- a/content/en/docs/porch/running-porch/running-on-GKE.md +++ b/content/en/docs/porch/running-porch/running-on-GKE.md @@ -78,7 +78,7 @@ To run a released version of Porch, download the release configuration bundle fr Untar and apply the *porch_blueprint.tar.gz* configuration bundle. This will install: * Porch server -* [ConfigSync](https://kpt.dev/gitops/configsync/) +* [configsync](https://kpt.dev/gitops/configsync/) ```bash mkdir porch-install @@ -100,7 +100,7 @@ packagerevisionresources porch.kpt.dev/v1alpha1 packagerevisions porch.kpt.dev/v1alpha1 true PackageRevision ``` -To install ConfigSync: +To install configsync: ```bash echo " @@ -138,7 +138,7 @@ IMAGE_TAG=$(git rev-parse --short HEAD) make push-and-deploy-no-sa If you want to use a different repository, you can set IMAGE_REPO variable (see [Makefile](https://github.com/nephio-project/porch/blob/main/Makefile#L33) for details). -The `make push-and-deploy-no-sa` target will install Porch but not ConfigSync. You can install ConfigSync in your k8s +The `make push-and-deploy-no-sa` target will install Porch but not configsync. You can install configsync in your k8s cluster manually following the [documentation](https://github.com/GoogleContainerTools/kpt-config-sync/blob/main/docs/installation.md). diff --git a/content/en/docs/porch/user-guides/install-and-using-porch.md b/content/en/docs/porch/user-guides/install-and-using-porch.md index dabe5a8f..bb9f6859 100644 --- a/content/en/docs/porch/user-guides/install-and-using-porch.md +++ b/content/en/docs/porch/user-guides/install-and-using-porch.md @@ -286,10 +286,10 @@ external-blueprints git Package false True https://github.com/n management git Package false True http://172.18.255.200:3000/nephio/management.git ``` -## Configure ConfigSync on the workload cluster +## Configure configsync on the workload cluster -ConfigSync is installed on the edge1 cluster so that it syncs the contents of the *edge1* repository onto the edge1 -workload cluster. We will use the ConfigSync package from Nephio. +configsync is installed on the edge1 cluster so that it syncs the contents of the *edge1* repository onto the edge1 +workload cluster. We will use the configsync package from Nephio. ```bash export KUBECONFIG=~/.kube/kind-edge1-config @@ -302,7 +302,7 @@ kpt live init configsync kpt live apply configsync ``` -Check that the ConfigSync PODs are up and running: +Check that the configsync PODs are up and running: ```bash kubectl get pod -n config-management-system @@ -311,7 +311,7 @@ config-management-operator-6946b77565-f45pc 1/1 Running 0 118m reconciler-manager-5b5d8557-gnhb2 2/2 Running 0 118m ``` -Now, we need to set up a Rootsync CR to synchronize the *edge1* repository: +Now, we need to set up a RootSync CR to synchronize the *edge1* repository: ```bash kpt pkg get https://github.com/nephio-project/catalog/tree/main/nephio/optional/rootsync @@ -351,7 +351,7 @@ Gitea: > # name: edge1-access-token-configsync ``` -Initialize and apply rootsync: +Initialize and apply RootSync: ```bash export KUBECONFIG=~/.kube/kind-edge1-config @@ -360,7 +360,7 @@ kpt live init rootsync # This command is only needed once kpt live apply rootsync ``` -Check that the rootsync CR is created: +Check that the RootSync CR is created: ```bash kubectl get rootsync -n config-management-system @@ -368,7 +368,7 @@ NAME RENDERINGCOMMIT RENDERINGERRORCOUNT SOURCEC edge1 613eb1ad5632d95c4336894f8a128cc871fb3266 613eb1ad5632d95c4336894f8a128cc871fb3266 613eb1ad5632d95c4336894f8a128cc871fb3266 ``` -Check that ConfigSync is synchronized with the repository on the management cluster: +Check that configsync is synchronized with the repository on the management cluster: ```bash kubectl get pod -n config-management-system -l app=reconciler @@ -1454,8 +1454,8 @@ management-c97bc433db93f2e8a3d413bed57216c2a72fc7e3 network-function-auto-name The process of deploying a blueprint package from our *management* repository clones the package, then modifies it for use on the workload cluster. The cloned package is then initialized, pushed, proposed, and approved onto the *edge1* repository. -Remember that the *edge1* repository is being monitored by ConfigSync from the edge1 cluster, so once the package appears in -the *edge1* repository on the management cluster, it will be pulled by ConfigSync and applied to the edge1 cluster. +Remember that the *edge1* repository is being monitored by configsync from the edge1 cluster, so once the package appears in +the *edge1* repository on the management cluster, it will be pulled by configsync and applied to the edge1 cluster. ``` porchctl -n porch-demo rpkg pull management-8b80738a6e0707e3718ae1db3668d0b8ca3f1c82 tmp_packages_for_deployment/edge1-network-function-a.clone.tmp @@ -1516,7 +1516,7 @@ No resources found in network-function-a namespace. ``` We now propose and approve the deployment package, which merges the package to the *edge1* repository and further triggers -ConfigSync to apply the package to the edge1 cluster. +configsync to apply the package to the edge1 cluster. ``` export KUBECONFIG=~/.kube/kind-management-config @@ -1619,7 +1619,7 @@ No resources found in network-function-auto-namespace-a namespace. ``` We now propose and approve the deployment package, which merges the package to the *edge1* repository and further triggers -Configsync to apply the package to the edge1 cluster. +configsync to apply the package to the edge1 cluster. ``` export KUBECONFIG=~/.kube/kind-management-config diff --git a/content/en/docs/release-notes/R1.md b/content/en/docs/release-notes/R1.md index 0ac243a4..153b2028 100644 --- a/content/en/docs/release-notes/R1.md +++ b/content/en/docs/release-notes/R1.md @@ -81,7 +81,7 @@ The following limitations need to be borne in mind: * Only Gitea works with automated cluster provisioning to create new repositories and join them to Nephio. To use a different Git provider, you must manually provision the cluster repositories, register them to the Nephio - management server, and set up ConfigSync on the workload cluster. + management server, and set up configsync on the workload cluster. * In the current demo configuration, the Web UI does not require authentication. Testing of the Web UI with authentication configured has not yet been done. * The Web UI only shows resources in the default namespace. diff --git a/content/en/docs/release-notes/R2.md b/content/en/docs/release-notes/R2.md index dadce13c..3f152f0d 100644 --- a/content/en/docs/release-notes/R2.md +++ b/content/en/docs/release-notes/R2.md @@ -108,7 +108,7 @@ The following limitations need to be borne in mind: limitation of free5GC. * Only Gitea works with automated cluster provisioning to create new repositories and join them to Nephio. To use a different Git provider, you must manually provision the - cluster repositories, register them to the Nephio management server, and set up ConfigSync on the workload cluster. + cluster repositories, register them to the Nephio management server, and set up configsync on the workload cluster. * In the current demo configuration, the Web UI does not require authentication. Testing of the Web UI with authentication configured has not yet been done. * The Web UI only shows resources in the default namespace. diff --git a/content/en/docs/release-notes/R3.md b/content/en/docs/release-notes/R3.md index 28f28890..8d49a309 100644 --- a/content/en/docs/release-notes/R3.md +++ b/content/en/docs/release-notes/R3.md @@ -95,7 +95,7 @@ The following packages have been introduced: * Feedback of the workload deployments from the workload clusters to the management cluster is limited. You may need to connect directly to the workload cluster via kubectl to resolve any deployment issues. * The web UI features are limited to the viewing and editing of packages, and resources in those packages, and their deployment. Additional features will be added in subsequent releases. * When the capacities of the UPF, SMF, and AMF NFs are changed, the free5GC operator on the workload cluster will instantiate a new POD with correspondingly modified resources (CPU, memory, and so on). During this process, the pod will restart. This is a limitation of free5GC. -* Only Gitea works with automated cluster provisioning to create new repositories and join them to Nephio. To use a different Git provider, you must manually provision the cluster repositories, register them to the Nephio management server, and set up ConfigSync on the workload cluster. +* Only Gitea works with automated cluster provisioning to create new repositories and join them to Nephio. To use a different Git provider, you must manually provision the cluster repositories, register them to the Nephio management server, and set up configsync on the workload cluster. * The web UI does not require authentication in the current demo configuration. Testing of the web UI with authentication configured has not yet been done. * The web UI only shows the resources in the default namespace. * While many types of Git authentication are supported, testing has only been done with token-based Git authentication in Gitea. diff --git a/content/en/docs/release-notes/R4.md b/content/en/docs/release-notes/R4.md index d2008271..4511b091 100644 --- a/content/en/docs/release-notes/R4.md +++ b/content/en/docs/release-notes/R4.md @@ -39,13 +39,13 @@ A Nephio sandbox can be created on any Kubernetes cluster, from v1.26 onwards. ### API * Focom Operator - * CRDs to support the Focom cluster provisioning api: + * CRDs to support the Focom cluster provisioning API: * [FocomProvisioningRequest](https://github.com/nephio-project/api/blob/main/config/crd/bases/focom.nephio.org_focomprovisioningrequests.yaml) * [OCloud](https://github.com/nephio-project/api/blob/main/config/crd/bases/focom.nephio.org_oclouds.yaml) * [TemplateInfo](https://github.com/nephio-project/api/blob/main/config/crd/bases/provisioning.oran.org_templateinfoes.yaml) * O2IMS Operator - * CRDs to support the O2IMS cluster provisioning api: + * CRDs to support the O2IMS cluster provisioning API: * [ProvisioningRequest](https://github.com/nephio-project/api/blob/main/config/crd/bases/o2ims.provisioning.oran.org_provisioningrequests.yaml) ### Web UI @@ -57,14 +57,14 @@ There were also security related updates done. The following packages have been introduced: -* ORAN Cluster Provisioning pkgs: +* ORAN Cluster Provisioning packages: * [Focom operator](https://github.com/nephio-project/catalog/tree/main/nephio/optional/focom-operator) * [O2IMS Operator](https://github.com/nephio-project/catalog/tree/main/nephio/optional/o2ims) * [FluxCD operators](https://github.com/nephio-project/catalog/tree/main/nephio/optional/fluxcd) -* Centralized FluxCD pkgs: +* Centralized FluxCD packages: * [Nephio Workload Cluster Flux](https://github.com/nephio-project/catalog/tree/main/infra/capi/nephio-workload-cluster-flux) * [Flux Gitrepo Kustomize](https://github.com/nephio-project/catalog/tree/main/nephio/optional/flux-gitrepo-kustomize) -* Spire/Spiffe related pkgs: +* Spire/Spiffe related packages: * [Spire](https://github.com/nephio-project/catalog/tree/main/nephio/optional/spire) * [Spire Agent](https://github.com/nephio-project/catalog/tree/main/nephio/optional/spire-agent) * [Spire Restricted SA](https://github.com/nephio-project/catalog/tree/main/nephio/optional/spire-restrictedSA) @@ -80,7 +80,7 @@ The following packages have been introduced: * CI/CD Testing * New e2e test suites added: - * [FluxCD Centralized workload deployemnt](https://prow.nephio.io/job-history/gs/prow-nephio-sig-release/logs/e2e-daily-ubuntu-jammy-flux) + * [FluxCD Centralized workload deployment](https://prow.nephio.io/job-history/gs/prow-nephio-sig-release/logs/e2e-daily-ubuntu-jammy-flux) * [O2IMS Cluster Provisioning](https://prow.nephio.io/job-history/gs/prow-nephio-sig-release/pr-logs/directory/e2e-o2ims-ubuntu-jammy) * Security