Skip to content
Closed
Show file tree
Hide file tree
Changes from 9 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -13,4 +13,9 @@ public/

# nodejs
package-lock.json
node_modules/
node_modules/

# AI DEV Tools
*.mcp
.mcp.json
.env
3 changes: 0 additions & 3 deletions .linkspector.yml
Original file line number Diff line number Diff line change
Expand Up @@ -25,9 +25,6 @@ ignorePatterns:
- pattern: "https://github\\.com/nephio-project/porch/releases/download/.*/porchctl_.*_linux_amd64\\.tar\\.gz"
- pattern: "https://kubernetes\\.io/.*"




replacementPatterns:
- pattern: ".md#.*$"
replacement: ".md"
256 changes: 134 additions & 122 deletions content/en/docs/porch/config-as-data.md

Large diffs are not rendered by default.

609 changes: 334 additions & 275 deletions content/en/docs/porch/package-orchestration.md

Large diffs are not rendered by default.

36 changes: 36 additions & 0 deletions content/en/docs/porch/user-guides/deprecation-of-update.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
---
title: "Deprecation of update"
type: docs
weight: 4
description: ""
---

## Motivation

The PackageRevision API object was meant to represent only metadata related to a package revision, while the contents of the package revision (i.e. the YAML files) are meant to be exposed via a companion PackageRevisionResources object. However PackageRevision's spec.tasks field contains all changes applied to the contents of the package revision in the form of patches, thus the contents of the package are leaking into the object that supposed to represent only the metadata. This implies that the PackageRevision can quickly grow bigger in size, than the contents of the package it represents.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The PackageRevision API object was meant to represent only metadata related to a package revision, while the contents of the package revision (i.e. the YAML files) are meant to be exposed via a companion PackageRevisionResources object. However PackageRevision's spec.tasks field contains all changes applied to the contents of the package revision in the form of patches, thus the contents of the package are leaking into the object that supposed to represent only the metadata. This implies that the PackageRevision can quickly grow bigger in size, than the contents of the package it represents.
The PackageRevision API object was intended to represent only metadata related to a package revision, while the contents of the package revision (i.e. the YAML files) were intended to be exposed via a companion PackageRevisionResources object. However PackageRevision's `spec.tasks` field contains all changes applied to the contents of the package revision in the form of patches, thus the contents of the package are leaking into the object that supposed to only represent the metadata. This means that the PackageRevision resource can rapidly grow bigger in size as changes to the PackageRevision resources are made. In some cases, the size of the PackageRevision resource can grow to be bigger than the contents of the package it represents.

For more details, see: https://github.com/nephio-project/nephio/issues/892

## Solution

We have introduced a new first task type, called upgrade. When there is a need to update a downstream package revision to a more up to date revision of its upstream package, do not store unnecessarily the diff's between the package revisions. Instead, now we use a 3-way-merge operation, where the old upstream, new upstream and the local revision changes are merged together. The introduced 3 way merge implementation is based on the kyaml's 3-way-merge solution.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
We have introduced a new first task type, called upgrade. When there is a need to update a downstream package revision to a more up to date revision of its upstream package, do not store unnecessarily the diff's between the package revisions. Instead, now we use a 3-way-merge operation, where the old upstream, new upstream and the local revision changes are merged together. The introduced 3 way merge implementation is based on the kyaml's 3-way-merge solution.
We have introduced a new "first" task type, called "upgrade". When there is a need to update a downstream package revision to a more up to date revision of its upstream package, the differences between the package revisions are no longer stored in the PackageRevision resource. Instead, a 3-way-merge operation is used, where the old upstream, new upstream and the local revision changes are merged together. The introduced 3 way merge implementation is based on the kyaml's 3-way-merge solution.

With this approach, we can reduce the task list to only one element, also we can deprecate the Patch/Eval/Update task types, since there will be no need for these. The remaining Init/Edit/Clone/Upgrade task can clearly identify the origin of a PackageRevision.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
With this approach, we can reduce the task list to only one element, also we can deprecate the Patch/Eval/Update task types, since there will be no need for these. The remaining Init/Edit/Clone/Upgrade task can clearly identify the origin of a PackageRevision.
With this approach, the task list is reduced to only one element and the Patch/Eval/Update task types are deprecated as they are no longer needed. The remaining Init/Edit/Clone/Upgrade "first" tasks clearly identify the origin of a PackageRevision.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be no harm to define a "first" task somewhere in the docs.

For more details, see: https://github.com/nephio-project/porch/pull/252

### Example
porchctl rpkg upgrade repository.package.1 --namespace=porch-demo --revision=2 --workspace=2
This command upgrades the package `repository.package.1` to the second version (revision=2) of its parent package.
It then creates a new package `repository.package.2` with the workspace name specified in the command (workspace=2).

### Migration guide from `update` to `upgrade`
The `upgrade` command now internally handles the functionality previously provided by:
porchctl rpkg copy --replay-strategy=true
This eliminates the need for users to manually copy a cloned package. Additionally, the `upgrade` command operates on
approved packages.

#### Previous workflow:
porchctl rpkg copy repository.package-copy.2 --namespace=porch-demo --workspace=3 --replay-strategy=true
porchctl rpkg update --discover=upstream
porchctl rpkg update porch-test.subpackage-copy.3 --namespace=porch-demo --revision=2
#### New workflow:
porchctl rpkg upgrade --discover=upstream
porchctl rpkg upgrade porch-test.subpackage-copy.2 --namespace=porch-demo --revision=2 --workspace=3
29 changes: 15 additions & 14 deletions content/en/docs/porch/user-guides/porchctl-cli-guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,20 +35,21 @@ The commands for administering repositories are:

The commands for administering package revisions are:

| Command | Description |
| ------------------------------ | ------------------------------------------------------------------------------------------------ |
| `porchctl rpkg approve` | Approve a proposal to publish a package revision. |
| `porchctl rpkg clone` | Create a clone of an existing package revision. |
| `porchctl rpkg copy` | Create a new package revision from an existing one. |
| `porchctl rpkg del` | Delete a package revision. |
| `porchctl rpkg get` | List package revisions in registered repositories. |
| `porchctl rpkg init` | Initializes a new package revision in a repository. |
| `porchctl rpkg propose` | Propose that a package revision should be published. |
| `porchctl rpkg propose-delete` | Propose deletion of a published package revision. |
| `porchctl rpkg pull` | Pull the content of the package revision. |
| `porchctl rpkg push` | Push resources to a package revision. |
| `porchctl rpkg reject` | Reject a proposal to publish or delete a package revision. |
| `porchctl rpkg upgrade` | Update a downstream package revision to a more recent revision of its upstream package revision. |
| Command | Description |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------ |
| `porchctl rpkg approve` | Approve a proposal to publish a package revision. |
| `porchctl rpkg clone` | Create a clone of an existing package revision. |
| `porchctl rpkg copy` | Create a new package revision from an existing one. |
| `porchctl rpkg del` | Delete a package revision. |
| `porchctl rpkg get` | List package revisions in registered repositories. |
| `porchctl rpkg init` | Initializes a new package in a repository. |
| `porchctl rpkg propose` | Propose that a package revision should be published. |
| `porchctl rpkg propose-delete` | Propose deletion of a published package revision. |
| `porchctl rpkg pull` | Pull the content of the package revision. |
| `porchctl rpkg push` | Push resources to a package revision. |
| `porchctl rpkg reject` | Reject a proposal to publish or delete a package revision. |
| `porchctl rpkg update` | Deprecated, please use the upgrade functionality instead. See: [Deprecation of update](./deprecation-of-update.md) |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As porchctl rpkg update no longer works, it shouldn't be on the list at all. Deprecation means it's still there but shold not be used. Maybe put in a footnote or something to say 'porchctl rpkg update' is gone.

| `porchctl rpkg upgrade` | Update a downstream package revision to a more recent revision of its upstream package using 3 way merge. |

## Using the porchctl CLI

Expand Down
4 changes: 2 additions & 2 deletions go.mod
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
module github.com/nephio-project/docs

go 1.18
go 1.24

require (
github.com/google/docsy v0.10.0 // indirect
github.com/google/docsy v0.12.0 // indirect
github.com/google/docsy/dependencies v0.7.2 // indirect
)
11 changes: 0 additions & 11 deletions go.sum
Original file line number Diff line number Diff line change
@@ -1,11 +0,0 @@
github.com/FortAwesome/Font-Awesome v0.0.0-20230327165841-0698449d50f2/go.mod h1:IUgezN/MFpCDIlFezw3L8j83oeiIuYoj28Miwr/KUYo=
github.com/FortAwesome/Font-Awesome v0.0.0-20240402185447-c0f460dca7f7/go.mod h1:IUgezN/MFpCDIlFezw3L8j83oeiIuYoj28Miwr/KUYo=
github.com/google/docsy v0.7.1 h1:DUriA7Nr3lJjNi9Ulev1SfiG1sUYmvyDeU4nTp7uDxY=
github.com/google/docsy v0.7.1/go.mod h1:JCmE+c+izhE0Rvzv3y+AzHhz1KdwlA9Oj5YBMklJcfc=
github.com/google/docsy v0.10.0 h1:6tMDacPwAyRWNCfvsn/9qGOZDQ8b0aRzjRZvnZPY5dg=
github.com/google/docsy v0.10.0/go.mod h1:c0nIAqmRTOuJ01F85U/wJPQtc3Zj9N58Kea9bOT2AJc=
github.com/google/docsy/dependencies v0.7.1/go.mod h1:gihhs5gmgeO+wuoay4FwOzob+jYJVyQbNaQOh788lD4=
github.com/google/docsy/dependencies v0.7.2 h1:+t5ufoADQAj4XneFphz4A+UU0ICAxmNaRHVWtMYXPSI=
github.com/google/docsy/dependencies v0.7.2/go.mod h1:gihhs5gmgeO+wuoay4FwOzob+jYJVyQbNaQOh788lD4=
github.com/twbs/bootstrap v5.2.3+incompatible/go.mod h1:fZTSrkpSf0/HkL0IIJzvVspTt1r9zuf7XlZau8kpcY0=
github.com/twbs/bootstrap v5.3.3+incompatible/go.mod h1:fZTSrkpSf0/HkL0IIJzvVspTt1r9zuf7XlZau8kpcY0=
2 changes: 1 addition & 1 deletion layouts/_default/_markup/render-heading.html
Original file line number Diff line number Diff line change
@@ -1 +1 @@
{{ template "_default/_markup/td-render-heading.html" . }}
<h{{ .Level }}{{ with .Anchor }} id="{{ . }}"{{ end }}>{{ .Text | safeHTML }}</h{{ .Level }}>
4 changes: 2 additions & 2 deletions netlify.toml
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ command = "hugo"
publish = "public"

[build.environment]
GO_VERSION = "1.18.1"
HUGO_VERSION = "v0.120.4"
GO_VERSION = "1.24.5"
HUGO_VERSION = "v0.148.2"
HUGO_ENV = "production"

[context.production]
Expand Down
11 changes: 7 additions & 4 deletions package.json
Original file line number Diff line number Diff line change
@@ -1,18 +1,21 @@
{
"name": "nephio-rpoject-docs",
"name": "nephio-project-docs",
"version": "1.0.0",
"description": "",
"description": "Documentation website for Nephio - Kubernetes-based cloud-native network automation platform",
"main": "postcss.config.js",
"scripts": {
"build": "hugo --gc --minify",
"serve": "hugo server -D",
"lint": "echo \"No linting configured\" && exit 0",
"test": "echo \"Error: no test specified\" && exit 1"
},
"repository": {
"type": "git",
"url": "git+https://github.com/nephio-project/docs.git"
},
"keywords": [],
"keywords": ["nephio", "kubernetes", "documentation", "cloud-native", "network-automation", "5g", "hugo", "docsy"],
"author": "Gergely Csatari <[email protected]>",
"license": "APACHE2",
"license": "CC-BY-4.0",
"bugs": {
"url": "https://github.com/nephio-project/docs/issues"
},
Expand Down
Loading