Add SUSE Edge 3.5.2 release notes and documentation updates#1185
Add SUSE Edge 3.5.2 release notes and documentation updates#1185dprodanov4 wants to merge 34 commits into
Conversation
* Add a note for ptp4l configuration * reformulate the problem * add PTP configuration link * Per comments, update to version and wording (cherry picked from commit 1df2876)
Update asciidoc/edge-book/releasenotes.adoc Co-authored-by: Eduardo Mínguez <e.minguez@gmail.com> (cherry picked from commit 900ac84)
These were missed in previous version updates for 3.5 (cherry picked from commit 3290288)
This aligns with the changes in suse-edge/telco-cloud-examples#78 (cherry picked from commit 6d06640)
This was missed in suse-edge#1001 (cherry picked from commit 8458cae)
(cherry picked from commit 4e39412)
…use-edge#1034) Co-authored-by: Eduardo Mínguez <eduardo.minguez@suse.com>
(cherry picked from commit d5b458d)
This was missed for 3.5, should be 10.2.29.1 (cherry picked from commit 5f6df7c)
…n 23) (suse-edge#1058) * libdpdk updated to newer tested version 25 (from version 23) (suse-edge#1056) (cherry picked from commit 409e68c) * libdpdk updated to version 25 also in l10n/source/edge.xml file
Due to addnab/docker-run-action#62 We can see related errors e.g on suse-edge#1058 (cherry picked from commit 36173af)
Signed-off-by: Ranjini M N <ranjini.n@suse.com>
Signed-off-by: Ranjini M N <ranjini.n@suse.com>
This aligns with rancher/turtles-product-docs#145 (cherry picked from commit 420ca10)
Signed-off-by: Ranjini M N <ranjini.n@suse.com>
This was updated in suse-edge#1087 but version-edge is used to format some URLs which use only the major version e.g 3.5, not the maintenance release e.g 3.5.1 Also it was noted that the nessie registry reference should use version-edge-registry
Ironic ConfigMap, ironic-bmo, has been renamed to ironic so this commit updates the troubleshooting documentation with the updated ConfigMap name.
The Telco documentation covering the PTP feature, refer to some basic steps shared with any SLES installation. However, the recent SLES 16.0 release came with some documentation refactoring, causing one link to change. Fix this problem by linking to the still existing SLES 15SP7 documentation. Note that SLES 16.0 has not yet migrated that section. Also change the text string associated with the link. Signed-off-by: Marco Chiappero <marco.chiappero@suse.com>
Signed-off-by: Ranjini M N <ranjini.n@suse.com>
- Document net.ifnames=1 is enforced by default from SLE Micro 6.2 onwards and must be explicitly set as kernel arg for SLM < 6.2 - Rewrite deployment model section to explain why STC uses EIB for mgmt clusters and Directed Network Provisioning for downstream clusters. Also mention it is the supported provisioning method (cherry picked from commit a1176f0)
- Add 3.5.2 release notes with component versions - Update container images in airgap deployment guides (69 images) - Update versions.adoc with 3.5.2 component versions - Update Longhorn container images - Highlight updated components: K3s 1.34.7, RKE2 1.34.7, Rancher 2.13.6, Metal3 305.0.26+up0.13.2, EIB 1.3.3.1
- Metal3: 305.0.25+up0.13.2 → 305.0.26+up0.13.2 - Ironic: 32.0.0.1 → 32.0.1.0 - Set availability date to TBD
ranjinimn
left a comment
There was a problem hiding this comment.
@dprodanov4 I just reviewed the content from documentation side of things. Hope it's okay. Please let me know if you have any questions.
|
|
||
| Starting with Rancher 2.13, Rancher Turtles is installed by default, therefore it is necessary to follow some additional migration steps as described in the https://documentation.suse.com/cloudnative/cluster-api/latest/en/tutorials/migration.html[Rancher Turtles Documentation] | ||
|
|
||
| Before upgrade it is necessary to remove the installed rancher-turtles chart and rancher-turtles-airgap-resources (if installed), |
There was a problem hiding this comment.
| Before upgrade it is necessary to remove the installed rancher-turtles chart and rancher-turtles-airgap-resources (if installed), | |
| Before the upgrade, you must remove the installed `rancher-turtles` chart and `rancher-turtles-airgap-resources` (if present). |
| *After* following the steps below to upgrade to `Edge {static-edge-version}` it is necessary to install the new `rancher-turtles-providers` helm chart - this creates new `CAPIProvider` resources to replace those removed in the pre-upgrade steps above. | ||
|
|
||
| First we must run the migration script as described in the https://turtles.docs.rancher.com/turtles/next/en/tutorials/migration.html[Rancher Turtles Documentation] | ||
|
|
There was a problem hiding this comment.
| First, we must run the migration script as described in the https://turtles.docs.rancher.com/turtles/next/en/tutorials/migration.html[Rancher Turtles Documentation]: |
| bash migrate-providers-ownership.sh --adopt metal3:capm3-system --adopt metal3ipam:metal3-ipam-system | ||
| ``` | ||
|
|
||
| Next the `rancher-turtles-providers` chart can be installed. This chart installation should be done via a `HelmChart` resource to enable future automated upgrade via the upgrade controller: |
There was a problem hiding this comment.
| Next the `rancher-turtles-providers` chart can be installed. This chart installation should be done via a `HelmChart` resource to enable future automated upgrade via the upgrade controller: | |
| Next, install the `rancher-turtles-providers` chart using a HelmChart resource, which enables future automated upgrades via the upgrade controller. |
|
|
||
| * *Runtime stack*: This is the part of SUSE Telco Cloud that is used to run the workloads. | ||
| ** <<components-rke2,RKE2>> serves as the security-hardened, lightweight Kubernetes distribution, optimized for edge and compliance-focused telecom environments. | ||
| ** (Optional) <<components-suse-security,SUSE Security>> to enable security features like image vulnerability scanning, deep packet inspection and automatic intra-cluster traffic control. |
There was a problem hiding this comment.
| ** (Optional) <<components-suse-security,SUSE Security>> to enable security features like image vulnerability scanning, deep packet inspection, and automatic intra-cluster traffic control. |
|
|
||
| The management cluster is a one-time, single-site deployment. Image-based Provisioning bundles all the components into a single bootable image. This way, the management cluster will bootstrap itself, requiring minimal operational complexity. It is the simplest and most straightforward way to get it up and running. | ||
|
|
||
| Downstream clusters, however, are a different story. In telco environments, they are deployed at scale across many data centers and edge sites, often with no on-site technical expertise available. Directed Network Provisioning is designed for this: it requires that target servers support an out-of-band management interface such as Redfish, through which the management cluster remotely powers on, inspects, and provisions bare-metal nodes without any on-site intervention. |
There was a problem hiding this comment.
| Downstream clusters, however, are a different story. In Telco environments, they are deployed at scale across many data centers and edge sites, often with no on-site technical expertise available. Directed Network Provisioning is designed for this: it requires that target servers support an out-of-band management interface such as Redfish, through which the management cluster remotely powers on, inspects, and provisions bare-metal nodes without any on-site intervention. |
|
|
||
| Downstream clusters, however, are a different story. In telco environments, they are deployed at scale across many data centers and edge sites, often with no on-site technical expertise available. Directed Network Provisioning is designed for this: it requires that target servers support an out-of-band management interface such as Redfish, through which the management cluster remotely powers on, inspects, and provisions bare-metal nodes without any on-site intervention. | ||
|
|
||
| Baking all cluster-specific configuration into a boot image, as Image-based Provisioning would require, means every site variation demands a different image, and any configuration change requires rebuilding and redistributing images across all sites. Directed Network Provisioning solves this by keeping the OS image generic and driving all cluster-specific configuration, including networking, Kubernetes, and Telco profiles, from the management cluster at provisioning time. Operators simply rack, power, and connect the hardware and the management cluster handles the rest. |
There was a problem hiding this comment.
The sentence was verbose and I just split it.
| Baking cluster-specific configurations into a boot image, which is required for image-based provisioning, means that every site variation demands a different image. Furthermore, any subsequent configuration change requires the rebuilding and redistribution of images across all sites. Directed Network Provisioning solves this by keeping the OS image generic and driving all cluster-specific configuration, including networking, Kubernetes, and Telco profiles, from the management cluster at provisioning time. Operators simply rack, power, and connect the hardware and the management cluster handles the rest. |
|
|
||
| This chapter describes how to provision downstream clusters using Directed Network Provisioning, the supported provisioning method for SUSE Telco Cloud. Unlike Image-based Provisioning, this workflow keeps the OS image generic and drives all cluster-specific configuration from the management cluster, enabling consistent and fully automated deployments at scale across distributed sites. | ||
|
|
||
| Directed Network Provisioning is a fully automated, zero-touch workflow driven by the management cluster. Each bare-metal host is first pre-enrolled in Metal3 from the management cluster by registering its BMC credentials and hardware details. Once the host is racked, connected to the required networks, and powered on, the management cluster takes over: it provisions the OS using an EIB-generated base image via the out-of-band management interface, and deploys the full Kubernetes stack with all telco profiles applied, without any further manual intervention. |
There was a problem hiding this comment.
| Directed Network Provisioning is a fully automated, zero-touch workflow driven by the management cluster. Each bare-metal host is first pre-enrolled in Metal^3^ from the management cluster by registering its BMC credentials and hardware details. Once the host is racked, connected to the required networks, and powered on, the management cluster takes over: it provisions the OS using an EIB-generated base image via the out-of-band management interface, and deploys the full Kubernetes stack with all Telco profiles applied, without any further manual intervention. |
|
|
||
| * <<components-slmicro,`SUSE Linux Micro`>> (or `SUSE Linux Micro RT` for Real-Time kernel) as the operating system. Networking, storage, users, and kernel arguments can be customized depending on the use case. | ||
| * <<components-rke2,`RKE2`>> as the Kubernetes distribution. The default CNI plug-in is `Cilium`. Other CNI combinations such as `Cilium+Multus` can be used depending on the use case. | ||
| * (Optional) <<components-suse-storage,`SUSE Storage`>> |
There was a problem hiding this comment.
Any specific reason for monospacing SUSE Storage?
| * (Optional) <<components-suse-storage,SUSE Storage>> |
|
|
||
| The management cluster automates the deployment of the following components on each downstream cluster node: | ||
|
|
||
| * <<components-slmicro,`SUSE Linux Micro`>> (or `SUSE Linux Micro RT` for Real-Time kernel) as the operating system. Networking, storage, users, and kernel arguments can be customized depending on the use case. |
There was a problem hiding this comment.
Any specific reason for monospacing SUSE Linux Micro and SUSE Linux Micro RT ?
| * <<components-slmicro,SUSE Linux Micro>> (or SUSE Linux Micro RT for Real-Time kernel) as the operating system. Networking, storage, users, and kernel arguments can be customized depending on the use case. |
| * <<components-slmicro,`SUSE Linux Micro`>> (or `SUSE Linux Micro RT` for Real-Time kernel) as the operating system. Networking, storage, users, and kernel arguments can be customized depending on the use case. | ||
| * <<components-rke2,`RKE2`>> as the Kubernetes distribution. The default CNI plug-in is `Cilium`. Other CNI combinations such as `Cilium+Multus` can be used depending on the use case. | ||
| * (Optional) <<components-suse-storage,`SUSE Storage`>> | ||
| * (Optional) <<components-suse-security,`SUSE Security`>> |
There was a problem hiding this comment.
| * (Optional) <<components-suse-security,SUSE Security>> |
f270291 to
89b4c06
Compare
89b4c06 to
a1489bd
Compare
|
Looks like this is a mistake as it's proposed to main and #1186 is the PR we should review? |
|
@hardys @dprodanov4 Do you want me to review that PR? Or can these suggestions be considered for that PR ? |
Complete documentation updates for SUSE Edge 3.5.2 release.
Release Notes:
Documentation Updates:
Updated Files: