openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

Telco core RDS changes

Browse Source 
Telco RAN changes
This commit is contained in:
Aidan Reilly
2024-05-16 08:07:07 +01:00
parent 58799746c3
commit 2911e45ced
54 changed files with 429 additions and 441 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
_distro_map.yml
View File

@@ -55,9 +55,12 @@ openshift-telco:
enterprise-4.14:
name: '4.14'
dir: container-platform-telco/4.14
# enterprise-4.15:
# name: '4.15'
# dir: container-platform-telco/4.15
enterprise-4.15:
name: '4.15'
dir: container-platform-telco/4.15
# enterprise-4.16:
# name: '4.16'
# dir: container-platform-telco/4.16
microshift:
name: Red Hat build of MicroShift
author: OpenShift Documentation Project <openshift-docs@redhat.com>

7
modules/telco-core-cluster-network-operator.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-cluster-network-operator_{context}"]
@@ -8,13 +8,13 @@
New in this release::
Not applicable.
* No reference design updates in this release
Description::
The CNO deploys and manages the cluster network components including the default OVN-Kubernetes network plugin during {product-title} cluster installation. It allows configuring primary interface MTU settings, OVN gateway modes to use node routing tables for pod egress, and additional secondary networks such as MACVLAN.
+
In support of network traffic segregation, multiple network interfaces are configured through the CNO. Traffic steering to these interfaces is configured through static routes applied by using the NMState Operator. To ensure that pod traffic is properly routed, OVN-K is configured with the `routingViaHost` option enabled. This setting uses the kernel routing table and the applied static routes rather than OVN for pod egress traffic.
In support of network traffic separation, multiple network interfaces are configured through the CNO. Traffic steering to these interfaces is configured through static routes applied by using the NMState Operator. To ensure that pod traffic is properly routed, OVN-K is configured with the `routingViaHost` option enabled. This setting uses the kernel routing table and the applied static routes rather than OVN for pod egress traffic.
+
The Whereabouts CNI plugin is used to provide dynamic IPv4 and IPv6 addressing for additional pod network interfaces without the use of a DHCP server.
@@ -25,4 +25,3 @@ Limits and requirements::
Engineering considerations::
* Pod egress traffic is handled by kernel routing table with the `routingViaHost` option. Appropriate static routes must be configured in the host.

15
modules/telco-core-cpu-partitioning-performance-tune.adoc
View File

@@ -1,23 +1,16 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-cpu-partitioning-performance-tune_{context}"]
= CPU partitioning and performance tuning
New in this release::
Open vSwitch (OVS) is removed from CPU partitioning. OVS manages its cpuset dynamically to automatically adapt to network traffic needs. Users no longer need to reserve additional CPUs for handling high network throughput on the primary container network interface (CNI). There is no impact on the configuration needed to benefit from this change.
* No reference design updates in this release
Description::
CPU partitioning allows for the separation of sensitive workloads from generic purposes, auxiliary processes, interrupts, and driver work queues to achieve improved performance and latency. The CPUs allocated to those auxiliary processes are referred to as `reserved` in the following sections. In hyperthreaded systems, a CPU is one hyperthread.
+
For more information, see https://docs.openshift.com/container-platform/latest/scalability_and_performance/cnf-low-latency-tuning.html#cnf-cpu-infra-container_cnf-master[Restricting CPUs for infra and application containers].
+
Configure system level performance.
For recommended settings, see link:https://docs.openshift.com/container-platform/latest/scalability_and_performance/ztp_far_edge/ztp-reference-cluster-configuration-for-vdu.html#ztp-du-configuring-host-firmware-requirements_sno-configure-for-vdu[Configuring host firmware for low latency and high performance].
Limits and requirements::
* The operating system needs a certain amount of CPU to perform all the support tasks including kernel networking.
@@ -40,10 +33,12 @@ cpu-freq-governor.crio.io: "performance"
----
Engineering considerations::
* The minimum reserved capacity (`systemReserved`) required can be found by following the guidance in link:https://access.redhat.com/solutions/5843241["Which amount of CPU and memory are recommended to reserve for the system in OCP 4 nodes?"]
* The minimum reserved capacity (`systemReserved`) required can be found by following the guidance in link:https://access.redhat.com/solutions/5843241["Which amount of CPU and memory are recommended to reserve for the system in OpenShift 4 nodes?"]
* The actual required reserved CPU capacity depends on the cluster configuration and workload attributes.
* This reserved CPU value must be rounded up to a full core (2 hyper-thread) alignment.
* Changes to the CPU partitioning will drain and reboot the nodes in the MCP.
* The reserved CPUs reduce the pod density, as the reserved CPUs are removed from the allocatable capacity of the OpenShift node.
* The real-time workload hint should be enabled if the workload is real-time capable.
* Hardware without Interrupt Request (IRQ) affinity support will impact isolated CPUs. To ensure that pods with guaranteed CPU QoS have full use of allocated CPU, all hardware in the server must support IRQ affinity.
* OVS dynamically manages its `cpuset` configuration to adapt to network traffic needs.
You do not need to reserve additional CPUs for handling high network throughput on the primary CNI.

30
modules/telco-core-crs-networking.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// *
// * telco_ref_design_specs/core/telco-core-ref-crs.adoc
:_mod-docs-content-type: REFERENCE
[id="networking-crs_{context}"]
@@ -11,20 +11,20 @@
|====
Component,Reference CR,Optional,New in this release
Baseline,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-network-yaml[Network.yaml],No,No
Baseline,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-networkattachmentdefinition-yaml[networkAttachmentDefinition.yaml],Yes,No
Baseline,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-networkattachmentdefinition-yaml[networkAttachmentDefinition.yaml],Yes,Yes
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-addr-pool-yaml[addr-pool.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-bfd-profile-yaml[bfd-profile.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-bgp-advr-yaml[bgp-advr.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-bgp-peer-yaml[bgp-peer.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallb-yaml[metallb.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbns-yaml[metallbNS.yaml],Yes,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbopergroup-yaml[metallbOperGroup.yaml],Yes,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbsubscription-yaml[metallbSubscription.yaml],No,No
Multus - Tap CNI for rootless DPDK pod,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-mc_rootless_pods_selinux-yaml[mc_rootless_pods_selinux.yaml],No,No
SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovnetwork-yaml[sriovNetwork.yaml],Yes,No
SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovnetworknodepolicy-yaml[sriovNetworkNodePolicy.yaml],No,Yes
SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovoperatorconfig-yaml[SriovOperatorConfig.yaml],No,Yes
SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovsubscription-yaml[SriovSubscription.yaml],No,No
SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovsubscriptionns-yaml[SriovSubscriptionNS.yaml],No,No
SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovsubscriptionopergroup-yaml[SriovSubscriptionOperGroup.yaml],No,No
SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovsubscription-yaml[SriovSubscription.yaml],No,No
SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovoperatorconfig-yaml[SriovOperatorConfig.yaml],No,No
SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovnetworknodepolicy-yaml[sriovNetworkNodePolicy.yaml],No,No
SR-IOV Network Operator,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sriovnetwork-yaml[sriovNetwork.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbns-yaml[metallbNS.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbopergroup-yaml[metallbOperGroup.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallbsubscription-yaml[metallbSubscription.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-metallb-yaml[metallb.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-bgp-peer-yaml[bgp-peer.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-bfd-profile-yaml[bfd-profile.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-addr-pool-yaml[addr-pool.yaml],No,No
Load balancer,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-bgp-advr-yaml[bgp-advr.yaml],No,No
Multus - Tap CNI for rootless DPDK pod,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-mc_rootless_pods_selinux-yaml[mc_rootless_pods_selinux.yaml],Yes,No
|====

20
modules/telco-core-crs-other.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// *
// * telco_ref_design_specs/core/telco-core-ref-crs.adoc
:_mod-docs-content-type: REFERENCE
[id="other-crs_{context}"]
@@ -10,17 +10,17 @@
[cols="4*", options="header", format=csv]
|====
Component,Reference CR,Optional,New in this release
Additional kernel modules,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-control-plane-load-kernel-modules-yaml[control-plane-load-kernel-modules.yaml],Yes,No
Additional kernel modules,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sctp_module_mc-yaml[sctp_module_mc.yaml],Yes,No
Additional kernel modules,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-worker-load-kernel-modules-yaml[worker-load-kernel-modules.yaml],Yes,No
Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogforwarder-yaml[ClusterLogForwarder.yaml],No,No
Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogging-yaml[ClusterLogging.yaml],No,No
Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogns-yaml[ClusterLogNS.yaml],No,No
Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogopergroup-yaml[ClusterLogOperGroup.yaml],No,No
Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogsubscription-yaml[ClusterLogSubscription.yaml],No,Yes
Disconnected configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-catalog-source-yaml[catalog-source.yaml],No,No
Disconnected configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-icsp-yaml[icsp.yaml],No,No
Disconnected configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-operator-hub-yaml[operator-hub.yaml],No,No
Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogns-yaml[ClusterLogNS.yaml],Yes,No
Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogopergroup-yaml[ClusterLogOperGroup.yaml],Yes,No
Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogsubscription-yaml[ClusterLogSubscription.yaml],Yes,No
Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogforwarder-yaml[ClusterLogForwarder.yaml],Yes,No
Cluster logging,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-clusterlogging-yaml[ClusterLogging.yaml],Yes,No
Additional kernel modules,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-control-plane-load-kernel-modules-yaml[control-plane-load-kernel-modules.yaml],Yes,No
Additional kernel modules,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-worker-load-kernel-modules-yaml[worker-load-kernel-modules.yaml],Yes,No
Additional kernel modules,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sctp_module_mc-yaml[sctp_module_mc.yaml],Yes,No
Power management,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-performanceprofile-yaml[PerformanceProfile.yaml],No,No
Monitoring and observability,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-monitoring-config-cm-yaml[monitoring-config-cm.yaml],Yes,No
Power management,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-performanceprofile-yaml[PerformanceProfile.yaml],No,No
|====

4
modules/telco-core-crs-resource-tuning.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// *
// * telco_ref_design_specs/core/telco-core-ref-crs.adoc
:_mod-docs-content-type: REFERENCE
[id="resource-tuning-crs_{context}"]
@@ -10,6 +10,6 @@
[cols="4*", options="header", format=csv]
|====
Component,Reference CR,Optional,New in this release
System reserved capacity,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-pid-limits-cr-yaml[pid-limits-cr.yaml],Yes,No
System reserved capacity,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-control-plane-system-reserved-yaml[control-plane-system-reserved.yaml],Yes,No
System reserved capacity,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-pid-limits-cr-yaml[pid-limits-cr.yaml],Yes,No
|====

7
modules/telco-core-crs-scheduling.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// *
// * telco_ref_design_specs/core/telco-core-ref-crs.adoc
:_mod-docs-content-type: REFERENCE
[id="scheduling-crs_{context}"]
@@ -10,9 +10,6 @@
[cols="4*", options="header", format=csv]
|====
Component,Reference CR,Optional,New in this release
NUMA-aware scheduler,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nropsubscriptionns-yaml[NROPSubscriptionNS.yaml],No,No
NUMA-aware scheduler,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nropsubscriptionopergroup-yaml[NROPSubscriptionOperGroup.yaml],No,No
NUMA-aware scheduler,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nropsubscription-yaml[NROPSubscription.yaml],No,No
NUMA-aware scheduler,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sched-yaml[sched.yaml],No,No
NUMA-aware scheduler,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-nrop-yaml[nrop.yaml],No,No
NUMA-aware scheduler,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-sched-yaml[sched.yaml],No,No
|====

11
modules/telco-core-crs-storage.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// *
// * telco_ref_design_specs/core/telco-core-ref-crs.adoc
:_mod-docs-content-type: REFERENCE
[id="storage-crs_{context}"]
@@ -10,9 +10,8 @@
[cols="4*", options="header", format=csv]
|====
Component,Reference CR,Optional,New in this release
External ODF configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-odfns-yaml[odfNS.yaml],No,No
External ODF configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-odfopergroup-yaml[odfOperGroup.yaml],No,No
External ODF configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-odfsubscription-yaml[odfSubscription.yaml],No,No
External ODF configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-01-rook-ceph-external-cluster-details.secret-yaml[01-rook-ceph-external-cluster-details.secret.yaml],No,No
External ODF configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-02-ocs-external-storagecluster-yaml[02-ocs-external-storagecluster.yaml],No,No
External {rh-storage-first} configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-01-rook-ceph-external-cluster-details.secret-yaml[01-rook-ceph-external-cluster-details.secret.yaml],No,Yes
External {rh-storage} configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-02-ocs-external-storagecluster-yaml[02-ocs-external-storagecluster.yaml],No,No
External {rh-storage} configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-odfns-yaml[odfNS.yaml],No,No
External {rh-storage} configuration,xref:../../telco_ref_design_specs/core/telco-core-ref-crs.adoc#telco-core-odfopergroup-yaml[odfOperGroup.yaml],No,No
|====

4
modules/telco-core-installation.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-installation_{context}"]
@@ -23,4 +23,4 @@ Limits and requirements::
Engineering considerations::
* Networking configuration should be applied as NMState configuration during installation in preference to day-2 configuration by using the NMState Operator.
* Networking configuration should be applied as NMState configuration during installation in preference to day-2 configuration by using the NMState Operator.

6
modules/telco-core-kernel.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/core/telco-core-ref-design-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-kernel_{context}"]
@@ -8,7 +8,7 @@
New in this release::
Not applicable
* No reference design updates in this release
Description::
@@ -41,4 +41,4 @@ Out of tree drivers are not supported.
Engineering considerations::
Not applicable
Not applicable

6
modules/telco-core-load-balancer.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-load-balancer_{context}"]
@@ -8,7 +8,7 @@
New in this release::
Not applicable.
* No reference design updates in this release
Description::
@@ -26,4 +26,4 @@ Engineering considerations::
* For core use models, MetalLB is supported with only the OVN-Kubernetes network provider used in local gateway mode. See `routingViaHost` in the "Cluster Network Operator" section.
* BGP configuration in MetalLB varies depending on the requirements of the network and peers.
* Address pools can be configured as needed, allowing variation in addresses, aggregation length, auto assignment, and other relevant parameters.
* The values of parameters in the Bi-Directional Forwarding Detection (BFD) profile should remain close to the defaults. Shorter values might lead to false negatives and impact performance.
* The values of parameters in the Bi-Directional Forwarding Detection (BFD) profile should remain close to the defaults. Shorter values might lead to false negatives and impact performance.

6
modules/telco-core-logging.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-logging_{context}"]
@@ -8,11 +8,11 @@
New in this release::
Not applicable
* No reference design updates in this release
Description::
The ClusterLogging Operator enables collection and shipping of logs off the node for remote archival and analysis. The reference configuration ships audit and infrastructure logs to a remote archive by using Kafka.
The Cluster Logging Operator enables collection and shipping of logs off the node for remote archival and analysis. The reference configuration ships audit and infrastructure logs to a remote archive by using Kafka.
Limits and requirements::

5
modules/telco-core-monitoring.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-monitoring_{context}"]
@@ -8,7 +8,7 @@
New in this release::
Not applicable
* No reference design updates in this release
Description::
@@ -33,4 +33,3 @@ Limits and requirements::
Engineering considerations::
* The Prometheus retention period is specified by the user. The value used is a tradeoff between operational requirements for maintaining historical data on the cluster against CPU and storage resources. Longer retention periods increase the need for storage and require additional CPU to manage the indexing of data.

12
modules/telco-core-power-management.adoc
View File

@@ -1,21 +1,25 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-power-management_{context}"]
= Power Management
New in this release::
* You can specify a maximum latency that is C-state for a low latency pod when using per-pod power management. Previously, C-states could only be disabled completely on a per pod basis.
* No reference design updates in this release
Description::
The link:https://docs.openshift.com/container-platform/4.15/rest_api/node_apis/performanceprofile-performance-openshift-io-v2.html#spec-workloadhints[Performance Profile] can be used to configure a cluster in a high power, low power or mixed (link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/cnf-low-latency-tuning.html#node-tuning-operator-pod-power-saving-config_cnf-master[per-pod power management]) mode. The choice of power mode depends on the characteristics of the workloads running on the cluster particularly how sensitive they are to latency.
The link:https://docs.openshift.com/container-platform/4.15/rest_api/node_apis/performanceprofile-performance-openshift-io-v2.html#spec-workloadhints[Performance Profile] can be used to configure a cluster in a high power, low power, or mixed mode.
The choice of power mode depends on the characteristics of the workloads running on the cluster, particularly how sensitive they are to latency.
Configure the maximum latency for a low-latency pod by using the per-pod power management C-states feature.
+
For more information, see link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.html#cnf-configuring-power-saving-for-nodes_cnf-low-latency-perf-profile[Configuring power saving for nodes].
Limits and requirements::
* Power configuration relies on appropriate BIOS configuration, for example, enabling C-states and P-states. Configuration varies between hardware vendors.
Engineering considerations::
* Latency: To ensure that latency-sensitive workloads meet their requirements, you will need either a high-power configuration or a per-pod power management configuration. Per-pod power management is only available for `Guaranteed` QoS Pods with dedicated pinned CPUs.

4
modules/telco-core-rds-disconnected.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/core/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-disconnected-environment_{context}"]
@@ -19,4 +19,4 @@ Limits and requirements::
Engineering considerations::
Not applicable
Not applicable

3
modules/telco-core-rds-networking.adoc
View File

@@ -1,10 +1,9 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/core/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-networking_{context}"]
= Networking
{product-title} networking is an ecosystem of features, plugins, and advanced networking capabilities that extend Kubernetes networking with the advanced networking-related features that your cluster needs to manage its network traffic for one or multiple hybrid clusters.

2
modules/telco-core-ref-application-workloads.adoc
View File

@@ -14,7 +14,7 @@ Pods running network functions that do not require the high throughput and low l
Description of limits::
* CNF applications should conform to the latest version of link:https://test-network-function.github.io/cnf-best-practices-guide/[Red Hat Best Practices for Kubernetes].
* CNF applications should conform to the latest version of the link:https://test-network-function.github.io/cnf-best-practices-guide/[Red Hat Best Practices for Kubernetes] guide.
* For a mix of best-effort and burstable QoS pods.
** Guaranteed QoS pods might be used but require correct configuration of reserved and isolated CPUs in the `PerformanceProfile`.
** Guaranteed QoS Pods must include annotations for fully isolating CPUs.

5
modules/telco-core-scalability.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-scalability_{context}"]
@@ -8,7 +8,7 @@
New in this release::
Not applicable
* No reference design updates in this release
Description::
@@ -23,4 +23,3 @@ Limits and requirements::
Engineering considerations::
Not applicable

18
modules/telco-core-scheduling.adoc
View File

@@ -1,28 +1,26 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-scheduling_{context}"]
= Scheduling
New in this release::
* NUMA-aware scheduling with the NUMA Resources Operator is now generally available in {product-title} {product-version}.
* With this release, you can exclude advertising the Non-Uniform Memory Access (NUMA) node for the SR-IOV network to the Topology Manager. By not advertising the NUMA node for the SR-IOV network, you can permit more flexible SR-IOV network deployments during NUMA-aware pod scheduling. To exclude advertising the NUMA node for the SR-IOV network resource to the Topology Manager, set the value `excludeTopology` to `true` in the `SriovNetworkNodePolicy` CR. For more information, see link:https://docs.openshift.com/container-platform/4.15/networking/hardware_networks/configuring-sriov-device.html#nw-sriov-exclude-topology-manager_configuring-sriov-device[Exclude the SR-IOV network topology for NUMA-aware scheduling].
* No reference design updates in this release
Description::
* The scheduler is a cluster-wide component responsible for selecting the right node for a given workload. It is a core part of the platform and does not require any specific configuration in the common deployment scenarios. However, there are few specific use cases described in the following section.
NUMA-aware scheduling can be enabled through the NUMA Resources Operator.
For more information, see link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/cnf-numa-aware-scheduling.html[Scheduling NUMA-aware workloads].
Limits and requirements::
* The default scheduler does not understand the NUMA locality of workloads. It only knows about the sum of all free resources on a worker node. This might cause workloads to be rejected when scheduled to a node with https://docs.openshift.com/container-platform/latest/scalability_and_performance/using-cpu-manager.html#topology_manager_policies_using-cpu-manager-and-topology_manager[Topology manager policy] set to `single-numa-node` or `restricted`.
* The default scheduler does not understand the NUMA locality of workloads. It only knows about the sum of all free resources on a worker node. This might cause workloads to be rejected when scheduled to a node with https://docs.openshift.com/container-platform/4.15/scalability_and_performance/using-cpu-manager.html#topology_manager_policies_using-cpu-manager-and-topology_manager[Topology manager policy] set to `single-numa-node` or `restricted`.
** For example, consider a pod requesting 6 CPUs and being scheduled to an empty node that has 4 CPUs per NUMA node. The total allocatable capacity of the node is 8 CPUs and the scheduler will place the pod there. The node local admission will fail, however, as there are only 4 CPUs available in each of the NUMA nodes.
** All clusters with multi-NUMA nodes are required to use the https://docs.openshift.com/container-platform/latest/scalability_and_performance/cnf-numa-aware-scheduling.html#installing-the-numa-resources-operator_numa-aware[NUMA Resources Operator]. The `machineConfigPoolSelector` of the NUMA Resources Operator must select all nodes where NUMA aligned scheduling is needed.
** All clusters with multi-NUMA nodes are required to use the https://docs.openshift.com/container-platform/4.15/scalability_and_performance/cnf-numa-aware-scheduling.html#installing-the-numa-resources-operator_numa-aware[NUMA Resources Operator]. The `machineConfigPoolSelector` of the NUMA Resources Operator must select all nodes where NUMA aligned scheduling is needed.
* All machine config pools must have consistent hardware configuration for example all nodes are expected to have the same NUMA zone count.
Engineering considerations::
* Pods might require annotations for correct scheduling and isolation. For more information on annotations, see xref:../../telco_ref_design_specs/core/telco-core-ref-design-components.adoc#telco-core-cpu-partitioning-performance-tune_core-ref-design-components[CPU partitioning and performance tuning].
* Pods might require annotations for correct scheduling and isolation. For more information on annotations, see the "CPU Partitioning and performance tuning" section.
* You can configure SR-IOV virtual function NUMA affinity to be ignored during scheduling by using the `excludeTopology` field in `SriovNetworkNodePolicy` CR.

11
modules/telco-core-security.adoc
View File

@@ -1,30 +1,27 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-security_{context}"]
= Security
New in this release::
* DPDK applications that need to inject traffic to the kernel can run in non-privileged pods with the help of the TAP CNI plugin. Furthermore, in this 4.14 release that ability to create a MAC-VLAN, IP-VLAN, and VLAN subinterface based on a master interface in a container namespace is generally available.
* No reference design updates in this release
Description::
Telco operators are security conscious and require clusters to be hardened against multiple attack vectors. Within {product-title}, there is no single component or feature responsible for securing a cluster. This section provides details of security-oriented features and configuration for the use models covered in this specification.
* **SecurityContextConstraints**: All workload pods should be run with restricted-v2 or restricted SCC.
* **Seccomp**: All pods should be run with the `RuntimeDefault` (or stronger) seccomp profile.
* **Rootless DPDK pods**: Many user-plane networking (DPDK) CNFs require pods to run with root privileges. With this feature, a conformant DPDK pod can be run without requiring root privileges.
Rootless DPDK pods create a tap device in a rootless pod that injects traffic from a DPDK application to the kernel.
* **Storage**: The storage network should be isolated and non-routable to other cluster networks. See the "Storage" section for additional details.
Limits and requirements::
* Rootless DPDK pods requires the following additional configuration steps:
** Configure the TAP plugin with the `container_t` SELinux context.
** Enable the `container_use_devices` SELinux boolean on the hosts.
Engineering considerations::
* For rootless DPDK pod support, the SELinux boolean `container_use_devices` must be enabled on the host for the TAP device to be created. This introduces a security risk that is acceptable for short to mid-term use. Other solutions will be explored.
* For rootless DPDK pod support, the SELinux boolean `container_use_devices` must be enabled on the host for the TAP device to be created. This introduces a security risk that is acceptable for short to mid-term use. Other solutions will be explored.

3
modules/telco-core-service-mesh.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-service-mesh_{context}"]
@@ -9,4 +9,3 @@
Description::
{rds-caps} CNFs typically require a service mesh implementation. The specific features and performance required are dependent on the application. The selection of service mesh implementation and configuration is outside the scope of this documentation. The impact of service mesh on cluster resource utilization and performance, including additional latency introduced into pod networking, must be accounted for in the overall solution engineering.

17
modules/telco-core-sriov.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-sriov_{context}"]
@@ -8,7 +8,16 @@
New in this release::
Not applicable
//CNF-5528
* `MultiNetworkPolicy` resources can now be applied to SR-IOV networks to enforce network reachability policies.
//CNF-9865
* QinQ is now supported in the SR-IOV Network Operator.
This is a Tech Preview feature.
//CNF-8804
* SR-IOV VFs can now receive all multicast traffic via the ‘allmulti’ flag when tuning the CNI.
This eliminates the need to add `NET_ADMIN` capability to the pod's security context constraints (SCCs) and enhances security by minimizing potential vulnerabilities for pods.
Description::
@@ -16,9 +25,11 @@ SR-IOV enables physical network interfaces (PFs) to be divided into multiple vir
Limits and requirements::
* The network interface controllers supported are listed in link:https://docs.openshift.com/container-platform/4.15/networking/hardware_networks/about-sriov.html#nw-sriov-supported-platforms_about-sriov[OCP supported SR-IOV devices]
* The network interface controllers supported are listed in link:https://docs.openshift.com/container-platform/4.15/networking/hardware_networks/about-sriov.html#supported-devices_about-sriov[Supported devices]
* SR-IOV and IOMMU enablement in BIOS: The SR-IOV Network Operator automatically enables IOMMU on the kernel command line.
* SR-IOV VFs do not receive link state updates from PF. If link down detection is needed, it must be done at the protocol level.
* `MultiNetworkPolicy` CRs can be applied to `netdevice` networks only.
This is because the implementation uses the `iptables` tool, which cannot manage `vfio` interfaces.
Engineering considerations::
* SR-IOV interfaces in `vfio` mode are typically used to enable additional secondary networks for applications that require high throughput or low latency.

6
modules/telco-core-storage.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/core/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-storage_{context}"]
@@ -20,7 +20,7 @@ All storage data may not be encrypted in flight. To reduce risk, isolate the sto
New in this release::
Not applicable
* No reference design updates in this release
Description::
@@ -28,7 +28,7 @@ Description::
For {rds-caps} clusters, storage support is provided by {rh-storage} storage services running externally to the application workload cluster. {rh-storage} supports separation of storage traffic using secondary CNI networks.
Limits and requirements::
* In an IPv4/IPv6 dual-stack networking environment, {rh-storage} uses IPv4 addressing. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.13/html-single/4.13_release_notes/index#support_openshift_dual_stack_with_odf_using_ipv4[Support OpenShift dual stack with ODF using IPv4].
* In an IPv4/IPv6 dual-stack networking environment, {rh-storage} uses IPv4 addressing. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.13/html-single/4.13_release_notes/index#support_openshift_dual_stack_with_odf_using_ipv4[Support OpenShift dual stack with {rh-storage} using IPv4].
Engineering considerations::

45
modules/telco-core-whats-new-ref-design.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-ran-ref-design-spec.adoc
// * telco_ref_design_specs/core/telco-core-rds-overview.adoc
:_mod-docs-content-type: CONCEPT
[id="telco-core-whats-new-ref-design_{context}""]
@@ -14,43 +14,8 @@ The following features that are included in {product-title} {product-version} an
|Feature
|Description
//CNF-7349 Rootless DPDK pods
|Support for running rootless Data Plane Development Kit (DPDK) workloads with kernel access by using the TAP CNI plugin
a|DPDK applications that inject traffic into the kernel can run in non-privileged pods with the help of the TAP CNI plugin.
* link:https://docs.openshift.com/container-platform/4.15/networking/hardware_networks/using-dpdk-and-rdma.html#nw-running-dpdk-rootless-tap_using-dpdk-and-rdma[Using the TAP CNI to run a rootless DPDK workload with kernel access]
//CNF-5977 Better pinning of the networking stack
|Dynamic use of non-reserved CPUs for OVS
a|With this release, the Open vSwitch (OVS) networking stack can dynamically use non-reserved CPUs.
The dynamic use of non-reserved CPUs occurs by default in performance-tuned clusters with a CPU manager policy set to `static`.
The dynamic use of available, non-reserved CPUs maximizes compute resources for OVS and minimizes network latency for workloads during periods of high demand.
OVS cannot use isolated CPUs assigned to containers in `Guaranteed` QoS pods. This separation avoids disruption to critical application workloads.
//CNF-7760
|Enabling more control over the C-states for each pod
a|The `PerformanceProfile` supports `perPodPowerManagement` which provides more control over the C-states for pods. Now, instead of disabling C-states completely, you can specify a maximum latency in microseconds for C-states. You configure this option in the `cpu-c-states.crio.io` annotation, which helps to optimize power savings for high-priority applications by enabling some of the shallower C-states instead of disabling them completely.
* link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/cnf-low-latency-tuning.html#node-tuning-operator-pod-power-saving-config_cnf-master[Optional: Power saving configurations]
//CNF-7741 Permit to disable NUMA Aware scheduling hints based on SR-IOV VFs
|Exclude SR-IOV network topology for NUMA-aware scheduling
a|You can exclude advertising Non-Uniform Memory Access (NUMA) nodes for the SR-IOV network to the Topology Manager. By not advertising NUMA nodes for the SR-IOV network, you can permit more flexible SR-IOV network deployments during NUMA-aware pod scheduling.
For example, in some scenarios, you want flexibility for how a pod is deployed. By not providing a NUMA node hint to the Topology Manager for the pod's SR-IOV network resource, the Topology Manager can deploy the SR-IOV network resource and the pod CPU and memory resources to different NUMA nodes. In previous {product-title} releases, the Topology Manager attempted to place all resources on the same NUMA node.
* link:https://docs.openshift.com/container-platform/4.15/networking/hardware_networks/configuring-sriov-device.html#nw-sriov-exclude-topology-manager_configuring-sriov-device[Exclude the SR-IOV network topology for NUMA-aware scheduling]
//CNF-8035 MetalLB VRF Egress interface selection with VRFs (Tech Preview)
|Egress service resource to manage egress traffic for pods behind a load balancer (Technology Preview)
a|With this update, you can use an `EgressService` custom resource (CR) to manage egress traffic for pods behind a load balancer service.
You can use the `EgressService` CR to manage egress traffic in the following ways:
* Assign the load balancer service's IP address as the source IP address of egress traffic for pods behind the load balancer service.
* Configure the egress traffic for pods behind a load balancer to a different network than the default node network.
* link:https://docs.openshift.com/container-platform/4.15/networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.html#configuring-egress-traffic-loadbalancer-services[Configuring an egress service]
//CNF-5528
|Multi-network policy support for IPv6 Networks
|You can now create multi-network policies for IPv6 networks.
For more information, see link:https://docs.openshift.com/container-platform/4.15/networking/multiple_networks/configuring-multi-network-policy.html#nw-multi-network-policy-ipv6-support_configuring-multi-network-policy[Supporting multi-network policies in IPv6 networks].
|====

115
modules/telco-core-yaml-ref-networking.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// *
// * telco_ref_design_specs/core/telco-core-ref-crs.adoc
:_mod-docs-content-type: REFERENCE
[id="networking-yaml_{context}"]
@@ -20,46 +20,39 @@ include::snippets/telco-core_Network.yaml[]
include::snippets/telco-core_networkAttachmentDefinition.yaml[]
----
[id="telco-core-sriovsubscriptionns-yaml"]
.SriovSubscriptionNS.yaml
[id="telco-core-addr-pool-yaml"]
.addr-pool.yaml
[source,yaml]
----
include::snippets/telco-core_SriovSubscriptionNS.yaml[]
include::snippets/telco-core_addr-pool.yaml[]
----
[id="telco-core-sriovsubscriptionopergroup-yaml"]
.SriovSubscriptionOperGroup.yaml
[id="telco-core-bfd-profile-yaml"]
.bfd-profile.yaml
[source,yaml]
----
include::snippets/telco-core_SriovSubscriptionOperGroup.yaml[]
include::snippets/telco-core_bfd-profile.yaml[]
----
[id="telco-core-sriovsubscription-yaml"]
.SriovSubscription.yaml
[id="telco-core-bgp-advr-yaml"]
.bgp-advr.yaml
[source,yaml]
----
include::snippets/telco-core_SriovSubscription.yaml[]
include::snippets/telco-core_bgp-advr.yaml[]
----
[id="telco-core-sriovoperatorconfig-yaml"]
.SriovOperatorConfig.yaml
[id="telco-core-bgp-peer-yaml"]
.bgp-peer.yaml
[source,yaml]
----
include::snippets/telco-core_SriovOperatorConfig.yaml[]
include::snippets/telco-core_bgp-peer.yaml[]
----
[id="telco-core-sriovnetworknodepolicy-yaml"]
.sriovNetworkNodePolicy.yaml
[id="telco-core-metallb-yaml"]
.metallb.yaml
[source,yaml]
----
include::snippets/telco-core_sriovNetworkNodePolicy.yaml[]
----
[id="telco-core-sriovnetwork-yaml"]
.sriovNetwork.yaml
[source,yaml]
----
include::snippets/telco-core_sriovNetwork.yaml[]
include::snippets/telco-core_metallb.yaml[]
----
[id="telco-core-metallbns-yaml"]
@@ -83,41 +76,6 @@ include::snippets/telco-core_metallbOperGroup.yaml[]
include::snippets/telco-core_metallbSubscription.yaml[]
----
[id="telco-core-metallb-yaml"]
.metallb.yaml
[source,yaml]
----
include::snippets/telco-core_metallb.yaml[]
----
[id="telco-core-bgp-peer-yaml"]
.bgp-peer.yaml
[source,yaml]
----
include::snippets/telco-core_bgp-peer.yaml[]
----
[id="telco-core-bfd-profile-yaml"]
.bfd-profile.yaml
[source,yaml]
----
include::snippets/telco-core_bfd-profile.yaml[]
----
[id="telco-core-addr-pool-yaml"]
.addr-pool.yaml
[source,yaml]
----
include::snippets/telco-core_addr-pool.yaml[]
----
[id="telco-core-bgp-advr-yaml"]
.bgp-advr.yaml
[source,yaml]
----
include::snippets/telco-core_bgp-advr.yaml[]
----
[id="telco-core-mc_rootless_pods_selinux-yaml"]
.mc_rootless_pods_selinux.yaml
[source,yaml]
@@ -125,3 +83,44 @@ include::snippets/telco-core_bgp-advr.yaml[]
include::snippets/telco-core_mc_rootless_pods_selinux.yaml[]
----
[id="telco-core-sriovnetwork-yaml"]
.sriovNetwork.yaml
[source,yaml]
----
include::snippets/telco-core_sriovNetwork.yaml[]
----
[id="telco-core-sriovnetworknodepolicy-yaml"]
.sriovNetworkNodePolicy.yaml
[source,yaml]
----
include::snippets/telco-core_sriovNetworkNodePolicy.yaml[]
----
[id="telco-core-sriovoperatorconfig-yaml"]
.SriovOperatorConfig.yaml
[source,yaml]
----
include::snippets/telco-core_SriovOperatorConfig.yaml[]
----
[id="telco-core-sriovsubscription-yaml"]
.SriovSubscription.yaml
[source,yaml]
----
include::snippets/telco-core_SriovSubscription.yaml[]
----
[id="telco-core-sriovsubscriptionns-yaml"]
.SriovSubscriptionNS.yaml
[source,yaml]
----
include::snippets/telco-core_SriovSubscriptionNS.yaml[]
----
[id="telco-core-sriovsubscriptionopergroup-yaml"]
.SriovSubscriptionOperGroup.yaml
[source,yaml]
----
include::snippets/telco-core_SriovSubscriptionOperGroup.yaml[]
----

79
modules/telco-core-yaml-ref-other.adoc
View File

@@ -1,30 +1,44 @@
// Module included in the following assemblies:
//
// *
// * telco_ref_design_specs/core/telco-core-ref-crs.adoc
:_mod-docs-content-type: REFERENCE
[id="other-yaml_{context}"]
= Other reference YAML
[id="telco-core-catalog-source-yaml"]
.catalog-source.yaml
[id="telco-core-control-plane-load-kernel-modules-yaml"]
.control-plane-load-kernel-modules.yaml
[source,yaml]
----
include::snippets/telco-core_catalog-source.yaml[]
include::snippets/telco-core_control-plane-load-kernel-modules.yaml[]
----
[id="telco-core-icsp-yaml"]
.icsp.yaml
[id="telco-core-sctp_module_mc-yaml"]
.sctp_module_mc.yaml
[source,yaml]
----
include::snippets/telco-core_icsp.yaml[]
include::snippets/telco-core_sctp_module_mc.yaml[]
----
[id="telco-core-operator-hub-yaml"]
.operator-hub.yaml
[id="telco-core-worker-load-kernel-modules-yaml"]
.worker-load-kernel-modules.yaml
[source,yaml]
----
include::snippets/telco-core_operator-hub.yaml[]
include::snippets/telco-core_worker-load-kernel-modules.yaml[]
----
[id="telco-core-clusterlogforwarder-yaml"]
.ClusterLogForwarder.yaml
[source,yaml]
----
include::snippets/telco-core_ClusterLogForwarder.yaml[]
----
[id="telco-core-clusterlogging-yaml"]
.ClusterLogging.yaml
[source,yaml]
----
include::snippets/telco-core_ClusterLogging.yaml[]
----
[id="telco-core-clusterlogns-yaml"]
@@ -48,46 +62,25 @@ include::snippets/telco-core_ClusterLogOperGroup.yaml[]
include::snippets/telco-core_ClusterLogSubscription.yaml[]
----
[id="telco-core-clusterlogforwarder-yaml"]
.ClusterLogForwarder.yaml
[id="telco-core-catalog-source-yaml"]
.catalog-source.yaml
[source,yaml]
----
include::snippets/telco-core_ClusterLogForwarder.yaml[]
include::snippets/telco-core_catalog-source.yaml[]
----
[id="telco-core-clusterlogging-yaml"]
.ClusterLogging.yaml
[id="telco-core-icsp-yaml"]
.icsp.yaml
[source,yaml]
----
include::snippets/telco-core_ClusterLogging.yaml[]
include::snippets/telco-core_icsp.yaml[]
----
[id="telco-core-control-plane-load-kernel-modules-yaml"]
.control-plane-load-kernel-modules.yaml
[id="telco-core-operator-hub-yaml"]
.operator-hub.yaml
[source,yaml]
----
include::snippets/telco-core_control-plane-load-kernel-modules.yaml[]
----
[id="telco-core-worker-load-kernel-modules-yaml"]
.worker-load-kernel-modules.yaml
[source,yaml]
----
include::snippets/telco-core_worker-load-kernel-modules.yaml[]
----
[id="telco-core-sctp_module_mc-yaml"]
.sctp_module_mc.yaml
[source,yaml]
----
include::snippets/telco-core_sctp_module_mc.yaml[]
----
[id="telco-core-performanceprofile-yaml"]
.PerformanceProfile.yaml
[source,yaml]
----
include::snippets/telco-core_PerformanceProfile.yaml[]
include::snippets/telco-core_operator-hub.yaml[]
----
[id="telco-core-monitoring-config-cm-yaml"]
@@ -97,3 +90,9 @@ include::snippets/telco-core_PerformanceProfile.yaml[]
include::snippets/telco-core_monitoring-config-cm.yaml[]
----
[id="telco-core-performanceprofile-yaml"]
.PerformanceProfile.yaml
[source,yaml]
----
include::snippets/telco-core_PerformanceProfile.yaml[]
----

15
modules/telco-core-yaml-ref-resource-tuning.adoc
View File

@@ -1,18 +1,11 @@
// Module included in the following assemblies:
//
// *
// * telco_ref_design_specs/core/telco-core-ref-crs.adoc
:_mod-docs-content-type: REFERENCE
[id="resource-tuning-yaml_{context}"]
= Resource Tuning reference YAML
[id="telco-core-pid-limits-cr-yaml"]
.pid-limits-cr.yaml
[source,yaml]
----
include::snippets/telco-core_pid-limits-cr.yaml[]
----
[id="telco-core-control-plane-system-reserved-yaml"]
.control-plane-system-reserved.yaml
[source,yaml]
@@ -20,3 +13,9 @@ include::snippets/telco-core_pid-limits-cr.yaml[]
include::snippets/telco-core_control-plane-system-reserved.yaml[]
----
[id="telco-core-pid-limits-cr-yaml"]
.pid-limits-cr.yaml
[source,yaml]
----
include::snippets/telco-core_pid-limits-cr.yaml[]
----

36
modules/telco-core-yaml-ref-scheduling.adoc
View File

@@ -1,39 +1,11 @@
// Module included in the following assemblies:
//
// *
// * telco_ref_design_specs/core/telco-core-ref-crs.adoc
:_mod-docs-content-type: REFERENCE
[id="scheduling-yaml_{context}"]
= Scheduling reference YAML
[id="telco-core-nropsubscriptionns-yaml"]
.NROPSubscriptionNS.yaml
[source,yaml]
----
include::snippets/telco-core_NROPSubscriptionNS.yaml[]
----
[id="telco-core-nropsubscriptionopergroup-yaml"]
.NROPSubscriptionOperGroup.yaml
[source,yaml]
----
include::snippets/telco-core_NROPSubscriptionOperGroup.yaml[]
----
[id="telco-core-nropsubscription-yaml"]
.NROPSubscription.yaml
[source,yaml]
----
include::snippets/telco-core_NROPSubscription.yaml[]
----
[id="telco-core-sched-yaml"]
.sched.yaml
[source,yaml]
----
include::snippets/telco-core_sched.yaml[]
----
[id="telco-core-nrop-yaml"]
.nrop.yaml
[source,yaml]
@@ -41,3 +13,9 @@ include::snippets/telco-core_sched.yaml[]
include::snippets/telco-core_nrop.yaml[]
----
[id="telco-core-sched-yaml"]
.sched.yaml
[source,yaml]
----
include::snippets/telco-core_sched.yaml[]
----

36
modules/telco-core-yaml-ref-storage.adoc
View File

@@ -1,32 +1,11 @@
// Module included in the following assemblies:
//
// *
// * telco_ref_design_specs/core/telco-core-ref-crs.adoc
:_mod-docs-content-type: REFERENCE
[id="storage-yaml_{context}"]
= Storage reference YAML
[id="telco-core-odfns-yaml"]
.odfNS.yaml
[source,yaml]
----
include::snippets/telco-core_odfNS.yaml[]
----
[id="telco-core-odfopergroup-yaml"]
.odfOperGroup.yaml
[source,yaml]
----
include::snippets/telco-core_odfOperGroup.yaml[]
----
[id="telco-core-odfsubscription-yaml"]
.odfSubscription.yaml
[source,yaml]
----
include::snippets/telco-core_odfSubscription.yaml[]
----
[id="telco-core-01-rook-ceph-external-cluster-details.secret-yaml"]
.01-rook-ceph-external-cluster-details.secret.yaml
[source,yaml]
@@ -41,3 +20,16 @@ include::snippets/telco-core_01-rook-ceph-external-cluster-details.secret.yaml[]
include::snippets/telco-core_02-ocs-external-storagecluster.yaml[]
----
[id="telco-core-odfns-yaml"]
.odfNS.yaml
[source,yaml]
----
include::snippets/telco-core_odfNS.yaml[]
----
[id="telco-core-odfopergroup-yaml"]
.odfOperGroup.yaml
[source,yaml]
----
include::snippets/telco-core_odfOperGroup.yaml[]
----

6
modules/telco-nmstate-operator.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * telco_ref_design_specs/ran/telco-core-ref-components.adoc
// * telco_ref_design_specs/core/telco-core-ref-design-components.adoc
:_mod-docs-content-type: REFERENCE
[id="telco-core-nmstate-operator_{context}"]
@@ -8,7 +8,7 @@
New in this release::
Not applicable
* No reference design updates in this release
Description::
@@ -20,4 +20,4 @@ Not applicable
Engineering considerations::
* The initial networking configuration is applied using `NMStateConfig` content in the installation CRs. The NMState Operator is used only when needed for network updates.
* When SR-IOV virtual functions are used for host networking, the NMState Operator using `NodeNetworkConfigurationPolicy` is used to configure those VF interfaces, for example, VLANs and the MTU.
* When SR-IOV virtual functions are used for host networking, the NMState Operator using `NodeNetworkConfigurationPolicy` is used to configure those VF interfaces, for example, VLANs and the MTU.

2
modules/telco-ran-bios-tuning.adoc
View File

@@ -11,7 +11,7 @@ New in this release::
Description::
Configure system level performance.
See link:https://docs.openshift.com/container-platform/latest/scalability_and_performance/ztp_far_edge/ztp-reference-cluster-configuration-for-vdu.html#ztp-du-configuring-host-firmware-requirements_sno-configure-for-vdu[Configuring host firmware for low latency and high performance] for recommended settings.
See link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/ztp_far_edge/ztp-reference-cluster-configuration-for-vdu.html#ztp-du-configuring-host-firmware-requirements_sno-configure-for-vdu[Configuring host firmware for low latency and high performance] for recommended settings.
+
If Ironic inspection is enabled, the firmware setting values are available from the per-cluster `BareMetalHost` CR on the hub cluster.
You enable Ironic inspection with a label in the `spec.clusters.nodes` field in the `SiteConfig` CR that you use to install the cluster.

16
modules/telco-ran-cluster-tuning.adoc
View File

@@ -7,15 +7,10 @@
= Cluster tuning
New in this release::
* You can remove the Image Registry Operator by using the cluster capabilities feature.
+
[NOTE]
====
You configure cluster capabilities by using the `spec.clusters.installConfigOverrides` field in the `SiteConfig` CR that you use to install the cluster.
====
* No reference design updates in this release
Description::
The cluster capabilities feature now includes a `MachineAPI` component which, when excluded, disables the following Operators and their resources in the cluster:
The cluster capabilities feature includes a `MachineAPI` component which, when excluded, disables the following Operators and their resources in the cluster:
* `openshift/cluster-autoscaler-operator`
@@ -23,6 +18,11 @@ The cluster capabilities feature now includes a `MachineAPI` component which, wh
* `openshift/machine-api-operator`
[NOTE]
====
Use cluster capabilities to remove the Image Registry Operator.
====
Limits and requirements::
* Cluster capabilities are not available for installer-provisioned installation methods.
@@ -57,7 +57,7 @@ The {rh-rhacm} hub cluster aggregates managed cluster metrics.
|Disable networking diagnostics
|Disable networking diagnostics for {sno} because they are not required.
|Configure a single Operator Hub catalog source
|Configure a single OperatorHub catalog source
|Configure the cluster to use a single catalog source that contains only the Operators required for a RAN DU deployment.
Each catalog source increases the CPU use on the cluster.
Using a single `CatalogSource` fits within the platform CPU budget.

3
modules/telco-ran-crs-cluster-tuning.adoc
View File

@@ -12,9 +12,10 @@
Component,Reference CR,Optional,New in this release
Cluster capabilities,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-example-sno-yaml[example-sno.yaml],No,No
Disabling network diagnostics,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-disablesnonetworkdiag-yaml[DisableSnoNetworkDiag.yaml],No,No
Disconnected Registry,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-09-openshift-marketplace-ns-yaml[09-openshift-marketplace-ns.yaml],No,Yes
Monitoring configuration,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-reducemonitoringfootprint-yaml[ReduceMonitoringFootprint.yaml],No,No
OperatorHub,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-defaultcatsrc-yaml[DefaultCatsrc.yaml],No,No
OperatorHub,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-disableolmpprof-yaml[DisableOLMPprof.yaml],No,No
OperatorHub,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-disconnectedicsp-yaml[DisconnectedICSP.yaml],No,No
OperatorHub,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-operatorhub-yaml[OperatorHub.yaml],No,No
OperatorHub,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-operatorhub-yaml[OperatorHub.yaml],Yes,No
|====

2
modules/telco-ran-crs-day-2-operators.adoc
View File

@@ -25,7 +25,7 @@ Node Tuning Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.
PTP fast event notifications,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpoperatorconfigforevent-yaml[PtpOperatorConfigForEvent.yaml],Yes,No
PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfigboundary-yaml[PtpConfigBoundary.yaml],No,No
PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfigdualcardgmwpc-yaml[PtpConfigDualCardGmWpc.yaml],No,No
PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfiggmwpc-yaml[PtpConfigGmWpc.yaml],No,Yes
PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfiggmwpc-yaml[PtpConfigGmWpc.yaml],No,No
PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpconfigslave-yaml[PtpConfigSlave.yaml],No,No
PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpsubscription-yaml[PtpSubscription.yaml],No,No
PTP Operator,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-ptpsubscriptionns-yaml[PtpSubscriptionNS.yaml],No,No

19
modules/telco-ran-crs-machine-configuration.adoc
View File

@@ -15,17 +15,18 @@ Container runtime (crun),xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-
Disabling CRI-O wipe,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-99-crio-disable-wipe-master-yaml[99-crio-disable-wipe-master.yaml],No,No
Disabling CRI-O wipe,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-99-crio-disable-wipe-worker-yaml[99-crio-disable-wipe-worker.yaml],No,No
Enable cgroup v1,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-enable-cgroups-v1-yaml[enable-cgroups-v1.yaml],No,No
Enabling kdump,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-05-kdump-config-master-yaml[05-kdump-config-master.yaml],No,Yes
Enabling kdump,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-05-kdump-config-worker-yaml[05-kdump-config-worker.yaml],No,Yes
Enabling kdump,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-05-kdump-config-master-yaml[05-kdump-config-master.yaml],No,No
Enabling kdump,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-05-kdump-config-worker-yaml[05-kdump-config-worker.yaml],No,No
Enabling kdump,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-06-kdump-master-yaml[06-kdump-master.yaml],No,No
Enabling kdump,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-06-kdump-worker-yaml[06-kdump-worker.yaml],No,No
Kubelet configuration and container mount hiding,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-01-container-mount-ns-and-kubelet-conf-master-yaml[01-container-mount-ns-and-kubelet-conf-master.yaml],No,No
Kubelet configuration and container mount hiding,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-01-container-mount-ns-and-kubelet-conf-worker-yaml[01-container-mount-ns-and-kubelet-conf-worker.yaml],No,No
One-shot time sync,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-99-sync-time-once-master-yaml[99-sync-time-once-master.yaml],No,Yes
One-shot time sync,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-99-sync-time-once-worker-yaml[99-sync-time-once-worker.yaml],No,Yes
kubelet configuration and container mount hiding,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-01-container-mount-ns-and-kubelet-conf-master-yaml[01-container-mount-ns-and-kubelet-conf-master.yaml],No,No
kubelet configuration and container mount hiding,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-01-container-mount-ns-and-kubelet-conf-worker-yaml[01-container-mount-ns-and-kubelet-conf-worker.yaml],No,No
One-shot time sync,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-99-sync-time-once-master-yaml[99-sync-time-once-master.yaml],No,No
One-shot time sync,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-99-sync-time-once-worker-yaml[99-sync-time-once-worker.yaml],No,No
SCTP,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-03-sctp-machine-config-master-yaml[03-sctp-machine-config-master.yaml],No,No
SCTP,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-03-sctp-machine-config-worker-yaml[03-sctp-machine-config-worker.yaml],No,No
Set RCU normal,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-08-set-rcu-normal-master-yaml[08-set-rcu-normal-master.yaml],No,No
Set RCU normal,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-08-set-rcu-normal-worker-yaml[08-set-rcu-normal-worker.yaml],No,No
SR-IOV related kernel arguments,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-07-sriov-related-kernel-args-master-yaml[07-sriov-related-kernel-args-master.yaml],No,Yes
Set RCU Normal,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-08-set-rcu-normal-master-yaml[08-set-rcu-normal-master.yaml],No,No
Set RCU Normal,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-08-set-rcu-normal-worker-yaml[08-set-rcu-normal-worker.yaml],No,No
SR-IOV related kernel arguments,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-07-sriov-related-kernel-args-master-yaml[07-sriov-related-kernel-args-master.yaml],No,No
SR-IOV related kernel arguments,xref:../../telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc#ztp-07-sriov-related-kernel-args-worker-yaml[07-sriov-related-kernel-args-worker.yaml],No,No
|====

19
modules/telco-ran-gitops-operator-and-ztp-plugins.adoc
View File

@@ -7,23 +7,15 @@
= {gitops-shortname} and {ztp} plugins
New in this release::
* GA support for inclusion of user-provided CRs in Git for {ztp} deployments
* {ztp} independence from the deployed cluster version
* No reference design updates in this release
Description::
{gitops-shortname} and {ztp} plugins provide a {gitops-shortname}-based infrastructure for managing cluster deployment and configuration.
Cluster definitions and configurations are maintained as a declarative state in Git.
ZTP plugins provide support for generating installation CRs from the `SiteConfig` CR and automatic wrapping of configuration CRs in policies based on `PolicyGenTemplate` CRs.
+
You can deploy and manage multiple versions of {product-title} on managed clusters with the baseline reference configuration CRs in a `/source-crs` subdirectory provided that subdirectory also contains the `kustomization.yaml` file.
You add user-provided CRs to this subdirectory that you use with the predefined CRs that are specified in the `PolicyGenTemplate` CRs.
This allows you to tailor your configurations to suit your specific requirements and provides {ztp} version independence between managed clusters and the hub cluster.
+
For more information, see the following:
* link:https://docs.openshift.com/container-platform/latest/scalability_and_performance/ztp_far_edge/ztp-preparing-the-hub-cluster.html#ztp-preparing-the-ztp-git-repository-ver-ind_ztp-preparing-the-hub-cluster[Preparing the site configuration repository for version independence]
* link:https://docs.openshift.com/container-platform/latest/scalability_and_performance/ztp_far_edge/ztp-advanced-policy-config.html#ztp-adding-new-content-to-gitops-ztp_ztp-advanced-policy-config[Adding custom content to the {ztp} pipeline]
You can deploy and manage multiple versions of {product-title} on managed clusters using the baseline reference configuration CRs.
You can also use custom CRs alongside the baseline CRs.
Limits::
* 300 `SiteConfig` CRs per ArgoCD application.
@@ -42,9 +34,8 @@ Alternative locations for the `/source-crs` directory are not supported in this
Engineering considerations::
* To avoid confusion or unintentional overwriting of files when updating content, use unique and distinguishable names for user-provided CRs in the `/source-crs` folder and extra manifests in Git.
* The `SiteConfig` CR allows multiple extra-manifest paths.
When files with the same name are found in multiple directory paths, the last file found takes precedence.
This allows the full set of version specific Day 0 manifests (extra-manifests) to be placed in Git and referenced from the `SiteConfig`.
* The `SiteConfig` CR allows multiple extra-manifest paths. When files with the same name are found in multiple directory paths, the last file found takes precedence.
This allows you to put the full set of version-specific Day 0 manifests (extra-manifests) in Git and reference them from the `SiteConfig` CR.
With this feature, you can deploy multiple {product-title} versions to managed clusters simultaneously.
* The `extraManifestPath` field of the `SiteConfig` CR is deprecated from {product-title} 4.15 and later.

6
modules/telco-ran-logging.adoc
View File

@@ -7,14 +7,14 @@
= Logging
New in this release::
* Vector is now the recommended log collector.
* No reference design updates in this release
Description::
Use logging to collect logs from the far edge node for remote analysis.
Use logging to collect logs from the far edge node for remote analysis. The recommended log collector is Vector.
Engineering considerations::
* Handling logs beyond the infrastructure and audit logs, for example, from the application workload requires additional CPU and network bandwidth based on additional logging rate.
* As of {product-title} 4.14, vector is the reference log collector.
* As of {product-title} 4.14, Vector is the reference log collector.
+
[NOTE]
====

6
modules/telco-ran-lvms-operator.adoc
View File

@@ -36,7 +36,7 @@ metadata:
namespace: openshift-storage
annotations:
ran.openshift.io/ztp-deploy-wave: "10"
spec: {}
spec:
storage:
deviceClasses:
- name: vg1
@@ -47,7 +47,9 @@ spec: {}
----
Limits and requirements::
* In {sno} clusters, persistent storage must be provided by either LVMS or Local Storage, not both.
* Ceph is excluded when used on cluster topologies with fewer than 3 nodes.
For example, Ceph is excluded in a {sno} cluster or {sno} cluster with a single worker node.
* In {sno} clusters, persistent storage must be provided by either LVMS or local storage, not both.
Engineering considerations::
* The LVMS Operator is not the reference storage solution for the DU use case.

2
modules/telco-ran-machine-configuration.adoc
View File

@@ -7,7 +7,7 @@
= Machine configuration
New in this release::
* Set `rcu_normal` after node recovery
* No reference design updates in this release
Limits and requirements::
* The CRI-O wipe disable `MachineConfig` assumes that images on disk are static other than during scheduled maintenance in defined maintenance windows.

4
modules/telco-ran-node-tuning-operator.adoc
View File

@@ -10,7 +10,7 @@ New in this release::
* No reference design updates in this release
Description::
You tune the cluster performance by link:https://docs.openshift.com/container-platform/latest/scalability_and_performance/cnf-create-performance-profiles.html[creating a performance profile].
You tune the cluster performance by link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/cnf-create-performance-profiles.html[creating a performance profile].
Settings that you configure with a performance profile include:
+
* Selecting the realtime or non-realtime kernel.
@@ -64,7 +64,7 @@ Variation must still meet the specified limits.
* Hardware without IRQ affinity support impacts isolated CPUs.
To ensure that pods with guaranteed whole CPU QoS have full use of the allocated CPU, all hardware in the server must support IRQ affinity.
For more information, see link:https://docs.openshift.com/container-platform/latest/scalability_and_performance/cnf-low-latency-tuning.html#about_irq_affinity_setting_cnf-master[About support of IRQ affinity setting].
For more information, see link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/cnf-low-latency-tuning.html#about_irq_affinity_setting_cnf-master[About support of IRQ affinity setting].
[NOTE]
====

30
modules/telco-ran-ptp-operator.adoc
View File

@@ -7,31 +7,37 @@
= PTP Operator
New in this release::
* PTP grandmaster clock (T-GM) GPS timing with single channel Intel E810-XXV-4T Westport Channel NIC – minimum firmware version 4.30 (Technology Preview)
* PTP grandmaster clock (T-GM) GPS timing with dual channel Intel E810-XXVDA4T Westport Channel NIC – minimum firmware version 4.40 (Technology Preview)
* PTP events and metrics for grandmaster (T-GM) are new in {product-title} {product-version} (Technology Preview)
* No reference design updates in this release
Description::
Configure of link:https://docs.openshift.com/container-platform/latest/scalability_and_performance/ztp_far_edge/ztp-reference-cluster-configuration-for-vdu.html#ztp-sno-du-configuring-ptp_sno-configure-for-vdu[PTP timing] support for cluster nodes.
See link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/ztp_far_edge/ztp-reference-cluster-configuration-for-vdu.html#ztp-sno-du-configuring-ptp_sno-configure-for-vdu[PTP timing] for details of support and configuration of PTP in cluster nodes.
The DU node can run in the following modes:
+
* As an ordinary clock synced to a T-GM or boundary clock (T-BC)
* As an ordinary clock (OC) synced to a grandmaster clock or boundary clock (T-BC)
* As dual boundary clocks, one per NIC (high availability is not supported)
* As a grandmaster clock synced from GPS with support for single or dual card E810 Westport Channel NICs
* As grandmaster clock with support for E810 Westport Channel NICs (Technology Preview)
* As dual boundary clocks (one per NIC) with support for E810 Westport Channel NICs
+
[NOTE]
====
Highly available boundary clocks are not supported.
====
* Optionally as a boundary clock for radio units (RUs)
* Optional: as a boundary clock for radio units (RUs)
+
Optional: subscribe applications to PTP events that happen on the node that the application is running.
You subscribe the application to events via HTTP.
--
Events and metrics for grandmaster clocks are a Tech Preview feature added in the 4.14 {rds} RDS. For more information see link:https://docs.openshift.com/container-platform/4.15/networking/ptp/using-ptp-events.html[Using the PTP hardware fast event notifications framework].
You can subscribe applications to PTP events that happen on the node where the DU application is running.
--
Limits and requirements::
* High availability is not supported with dual-NIC configurations.
* Digital Phase-Locked Loop (DPLL) clock synchronization is not supported for E810 Westport Channel NICs.
* GPS offsets are not reported.
Use a default offset of less than or equal to 5.

11
modules/telco-ran-red-hat-advanced-cluster-management-rhacm.adoc
View File

@@ -7,21 +7,28 @@
= {rh-rhacm-first}
New in this release::
* Additional node labels can be configured during installation.
* No reference design updates in this release
Description::
{rh-rhacm} provides Multi Cluster Engine (MCE) installation and ongoing lifecycle management functionality for deployed clusters.
You declaratively specify configurations and upgrades with `Policy` CRs and apply the policies to clusters with the {rh-rhacm} policy controller as managed by {cgu-operator-full}.
+
--
* {ztp-first} uses the MCE feature of {rh-rhacm}
* Configuration, upgrades, and cluster status are managed with the {rh-rhacm} policy controller
During installation {rh-rhacm} can apply labels to individual nodes as configured in the `SiteConfig` custom resource (CR).
--
Limits and requirements::
* A single hub cluster supports up to 3500 deployed {sno} clusters with 5 `Policy` CRs bound to each cluster.
Engineering considerations::
* Use {rh-rhacm} policy hub-side templating to better scale cluster configuration.
You can significantly reduce the number of policies by using a single group policy or small number of general group policies where the group and per-cluster values are substituted into templates.
* Cluster specific configuration: managed clusters typically have some number of configuration values that are specific to the individual cluster.
These configurations should be managed using {rh-rhacm} policy hub-side templating with values pulled from `ConfigMap` CRs based on the cluster name.
* To save CPU resources on managed clusters, policies that apply static configurations should be unbound from managed clusters after {ztp} installation of the cluster.
For more information, see link:https://docs.openshift.com/container-platform/latest/storage/understanding-persistent-storage.html#releasing_understanding-persistent-storage[Release a persistent volume].
For more information, see link:https://docs.openshift.com/container-platform/4.15/storage/understanding-persistent-storage.html#releasing_understanding-persistent-storage[Release a persistent volume].

67
modules/telco-ran-ref-design-features.adoc
View File

@@ -6,69 +6,6 @@
[id="telco-ran-ref-design-features_{context}"]
= {product-title} {product-version} features for {rds}
The following features that are included in {product-title} {product-version} and are leveraged by the {rds} reference design specification (RDS) have been added or updated.
The {product-version} version of the {rds} reference design specification (RDS) has the same feature set as the 4.14 version of the {rds} RDS.
.{product-title} {product-version} features for the {rds} RDS
[cols="1,3", options="header"]
|====
|Feature
|Description
//CNF-7365
|{ztp} independence from managed cluster version
a|You can now use {ztp} to manage clusters that are running different versions of {product-title} compared to the version that is running on the hub cluster. You can also have a mix of {product-title} versions in the deployed fleet of clusters.
* link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/ztp_far_edge/ztp-preparing-the-hub-cluster.html#ztp-preparing-the-ztp-git-repository-ver-ind_ztp-preparing-the-hub-cluster[Preparing the {ztp} site configuration repository for version independence]
//CNF-6925
|Using custom CRs alongside the reference CRs in {ztp}
a|You can now use custom CRs alongside the reference configuration CRs provided in the `ztp-site-generate` container.
* link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/ztp_far_edge/ztp-advanced-policy-config.html#ztp-adding-new-content-to-gitops-ztp_ztp-advanced-policy-config[Adding custom content to the {ztp} pipeline]
//CNF-8035
|Using custom node labels in the `SiteConfig` CR with {ztp}
a|You can now use the `nodeLabels` field in the `SiteConfig` CR to create custom roles for nodes in managed clusters.
* link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/ztp_far_edge/ztp-deploying-far-edge-sites.html#ztp-sno-siteconfig-config-reference_ztp-deploying-far-edge-sites[{sno-caps} SiteConfig CR installation reference]
//CNF-7078
|Intel Westport Channel e810 NIC as PTP Grandmaster clock (Technology Preview)
a|You can use the Intel Westport Channel E810-XXVDA4T as a GNSS-sourced grandmaster clock.
The NIC is automatically configured by the PTP Operator with the E810 hardware plugin.
* link:https://docs.openshift.com/container-platform/4.14/networking/ptp/configuring-ptp.html#configuring-linuxptp-services-as-grandmaster-clock-dual-nic_configuring-ptp[Configuring linuxptp services as a grandmaster clock for dual E810 Westport Channel NICs]
//CNF-6527
|PTP Operator hardware specific functionality plugin (Technology Preview)
a|A new E810 NIC hardware plugin is now available in the PTP Operator.
You can use the E810 plugin to configure the NIC directly.
* link:https://docs.openshift.com/container-platform/4.14/networking/ptp/configuring-ptp.html#nw-ptp-wpc-hardware-pins-reference_configuring-ptp[Intel Westport Channel E810 hardware configuration reference]
//OCPBUGS-13050, CTONET-3072
|PTP events and metrics
a|The `PtpConfig` reference configuration CRs have been updated.
* link:https://docs.openshift.com/container-platform/4.15/networking/using-ptp.html#discover-ptp-devices_using-ptp[Discovering PTP capable network devices in your cluster]
//CNF-7517
|Precaching user-specified images
a|You can now precache application workload images before upgrading your applications on {sno} clusters with {cgu-operator-full}.
* link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/ztp_far_edge/ztp-precaching-tool.html#ztp-pre-staging-tool[Precaching images for {sno} deployments]
//CNF-6318, OCPVE-630
|Using OpenShift capabilities to further reduce the {sno} DU footprint
a|Use cluster capabilities to enable or disable optional components before you install the cluster.
In {product-title} {product-version}, the following optional capabilities are available:
`image-registry`, `baremetal`, `marketplace`, `openshift-samples`, `Console`, `Insights`, `Storage`, `CSISnapshot`, `NodeTuning`, `MachineAPI`. The reference configuration includes only those features required for RAN DU.
* link:https://docs.openshift.com/container-platform/4.15/installing/cluster-capabilities.html#cluster-capabilities[Cluster capabilities]
//CNF-5997
|Set `vectord` as the default log collector in the DU profile
a| {sno} clusters that run DU workloads require logging and log forwarding.
* link:https://docs.openshift.com/container-platform/4.14/scalability_and_performance/ztp_far_edge/ztp-reference-cluster-configuration-for-vdu.html#ztp-sno-du-configuring-logging-locally-and-forwarding_sno-configure-for-vdu[Cluster logging and log forwarding]
|====
See link:https://docs.openshift.com/container-platform-telco/4.14/telco_ref_design_specs/ran/telco-ran-ref-design-spec.html#telco-ran-ref-design-features_ran-ref-design-spec[{product-title} 4.14 {rds} features] for more information.

4
modules/telco-ran-topology-aware-lifecycle-manager-talm.adoc
View File

@@ -7,7 +7,7 @@
= {cgu-operator-first}
New in this release::
* Added support for pre-caching additional user-specified images
* No reference design updates in this release
Description::
+
@@ -22,7 +22,7 @@ Managed updates::
Precaching for {sno} clusters::
{cgu-operator} supports optional precaching of {product-title}, OLM Operator, and additional user images to {sno} clusters before initiating an upgrade.
+
* A new `PreCachingConfig` custom resource is available for specifying optional pre-caching configurations.
* A `PreCachingConfig` custom resource is available for specifying optional pre-caching configurations.
For example:
+
[source,yaml]

7
modules/telco-ran-yaml-ref-cluster-tuning.adoc
View File

@@ -20,6 +20,13 @@ include::snippets/ztp_example-sno.yaml[]
include::snippets/ztp_DisableSnoNetworkDiag.yaml[]
----
[id="ztp-09-openshift-marketplace-ns-yaml"]
.09-openshift-marketplace-ns.yaml
[source,yaml]
----
include::snippets/ztp_09-openshift-marketplace-ns.yaml[]
----
[id="ztp-reducemonitoringfootprint-yaml"]
.ReduceMonitoringFootprint.yaml
[source,yaml]

7
modules/telco-ran-yaml-ref-machine-configuration.adoc
View File

@@ -131,3 +131,10 @@ include::snippets/ztp_08-set-rcu-normal-worker.yaml[]
----
include::snippets/ztp_07-sriov-related-kernel-args-master.yaml[]
----
[id="ztp-07-sriov-related-kernel-args-worker-yaml"]
.07-sriov-related-kernel-args-worker.yaml
[source,yaml]
----
include::snippets/ztp_07-sriov-related-kernel-args-worker.yaml[]
----

3
snippets/telco-core_Network.yaml
View File

@@ -20,3 +20,6 @@ spec:
# namespace: app-ns-1
# rawCNIConfig: '{ "cniVersion": "0.4.0", "name": "add-net-2", "plugins": [ {"type": "macvlan", "master": "bond1", "mode": "private" },{ "type": "tuning", "name": "tuning-arp" }] }'
# type: Raw
# Enable to use MultiNetworkPolicy CRs
useMultiNetworkPolicy: true

7
snippets/telco-core_PerformanceProfile.yaml
View File

@@ -43,11 +43,4 @@ spec:
# All guaranteed QoS containers get resources from a single NUMA node
topologyPolicy: "single-numa-node"
net:
# Limit the number or IRQs to 8 (number or reserved CPUs)
# => this is good enough as I have only 262 IT now instead of 501
# but this is a waste... TODO: now waste (see below)!
#
# This is more than enough for eno1 (host and OVN)
# eno2 should be down. TODO: add MCO or use NMSTATE in OCP4.10
# SR-IOV PFs: only VFs are used. TODO: MCO to have a single IRQ
userLevelNetworking: false

15
snippets/ztp_09-openshift-marketplace-ns.yaml Normal file
View File

@@ -0,0 +1,15 @@
apiVersion: v1
kind: Namespace
metadata:
annotations:
openshift.io/node-selector: ""
workload.openshift.io/allowed: "management"
labels:
openshift.io/cluster-monitoring: "true"
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/enforce-version: v1.25
pod-security.kubernetes.io/audit: baseline
pod-security.kubernetes.io/audit-version: v1.25
pod-security.kubernetes.io/warn: baseline
pod-security.kubernetes.io/warn-version: v1.25
name: "openshift-marketplace"

7
snippets/ztp_example-sno.yaml
View File

@@ -1,6 +1,6 @@
# example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
---
apiVersion: ran.openshift.io/v1
apiVersion: ran.openshift.io/v2
kind: SiteConfig
metadata:
name: "example-sno"
@@ -20,14 +20,15 @@ spec:
# remove all but the marketplace component from the optional set of
# components.
# Notes:
# - OperatorLifecycleManager is needed for 4.15 and later
# - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
installConfigOverrides: "{\"capabilities\":{\"baselineCapabilitySet\": \"None\", \"additionalEnabledCapabilities\": [ \"marketplace\", \"NodeTuning\" ] }}"
installConfigOverrides: "{\"capabilities\":{\"baselineCapabilitySet\": \"None\", \"additionalEnabledCapabilities\": [ \"OperatorLifecycleManager\", \"NodeTuning\" ] }}"
# It is strongly recommended to include crun manifests as part of the additional install-time manifests for 4.13+.
# The crun manifests can be obtained from source-crs/optional-extra-manifest/ and added to the git repo ie.sno-extra-manifest.
# extraManifestPath: sno-extra-manifest
clusterLabels:
# These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples
du-profile: "4.14"
du-profile: "latest"
# These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples in ../policygentemplates:
# ../policygentemplates/common-ranGen.yaml will apply to all clusters with 'common: true'
common: true

2
telco_ref_design_specs/core/telco-core-ref-crs.adoc
View File

@@ -12,7 +12,7 @@ Use the CRs to form the common baseline used in all the specific use models unle
[NOTE]
====
The {rds} CRs are available in link:https://github.com/openshift-kni/telco-reference/tree/release-4.14[GitHub].
The {rds} CRs are available in link:https://github.com/openshift-kni/telco-reference/tree/release-4.15[GitHub].
====
include::modules/telco-core-crs-resource-tuning.adoc[leveloffset=+1]

79
telco_ref_design_specs/core/telco-core-ref-design-components.adoc
View File

@@ -11,32 +11,106 @@ The following sections describe the various {product-title} components and confi
include::modules/telco-core-cpu-partitioning-performance-tune.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.html#cnf-cpu-infra-container_cnf-master[Tuning nodes for low latency with the performance profile]
* link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/ztp_far_edge/ztp-reference-cluster-configuration-for-vdu.html#ztp-du-configuring-host-firmware-requirements_sno-configure-for-vdu[Configuring host firmware for low latency and high performance]
include::modules/telco-core-service-mesh.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/service_mesh/v2x/ossm-about.html[About OpenShift Service Mesh]
include::modules/telco-core-rds-networking.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/networking/understanding-networking.html[Understanding networking]
include::modules/telco-core-cluster-network-operator.adoc[leveloffset=+2]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/networking/cluster-network-operator.html#nw-cluster-network-operator_cluster-network-operator[Cluster Network Operator]
include::modules/telco-core-load-balancer.adoc[leveloffset=+2]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/networking/metallb/about-metallb.html[About MetalLB and the MetalLB Operator]
include::modules/telco-core-sriov.adoc[leveloffset=+2]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/networking/hardware_networks/about-sriov.html[About SR-IOV hardware networks]
include::modules/telco-nmstate-operator.adoc[leveloffset=+2]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/networking/k8s_nmstate/k8s-nmstate-about-the-k8s-nmstate-operator.html[About the Kubernetes NMState Operator]
include::modules/telco-core-logging.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/observability/logging/cluster-logging.html[About logging]
include::modules/telco-core-power-management.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.html#cnf-configuring-power-saving-for-nodes_cnf-low-latency-perf-profile[Configuring power saving for nodes that run colocated high and low priority workloads]
include::modules/telco-core-storage.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.15[Product Documentation for Red Hat OpenShift Data Foundation]
include::modules/telco-core-monitoring.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/observability/monitoring/monitoring-overview.html#about-openshift-monitoring[About {product-version} monitoring]
include::modules/telco-core-scheduling.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/nodes/scheduling/nodes-scheduler-about.html[Controlling pod placement using the scheduler]
* link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/cnf-numa-aware-scheduling.html[Scheduling NUMA-aware workloads]
include::modules/telco-core-installation.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/installing/installing_with_agent_based_installer/installing-with-agent-based-installer.html[Installing an {product-title} cluster with the Agent-based Installer]
include::modules/telco-core-security.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/authentication/managing-security-context-constraints.html[Managing security context constraints]
include::modules/telco-core-scalability.adoc[leveloffset=+1]
[id="telco-core-additional-config"]
@@ -44,6 +118,11 @@ include::modules/telco-core-scalability.adoc[leveloffset=+1]
include::modules/telco-core-rds-disconnected.adoc[leveloffset=+2]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/updating/updating_a_cluster/updating_disconnected_cluster/index.html[About cluster updates in a disconnected environment]
include::modules/telco-core-kernel.adoc[leveloffset=+2]
:!telco-core:

7
telco_ref_design_specs/ran/telco-ran-ref-du-components.adoc
View File

@@ -42,6 +42,13 @@ include::modules/telco-ran-topology-aware-lifecycle-manager-talm.adoc[leveloffse
include::modules/telco-ran-gitops-operator-and-ztp-plugins.adoc[leveloffset=+2]
[role="_additional-resources"]
.Additional resources
* link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/ztp_far_edge/ztp-preparing-the-hub-cluster.html#ztp-preparing-the-ztp-git-repository-ver-ind_ztp-preparing-the-hub-cluster[Preparing the {ztp} site configuration repository for version independence]
* link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/ztp_far_edge/ztp-advanced-policy-config.html#ztp-adding-new-content-to-gitops-ztp_ztp-advanced-policy-config[Adding custom content to the {ztp} pipeline]
include::modules/telco-ran-agent-based-installer-abi.adoc[leveloffset=+2]
[id="telco-ran-additional-components_{context}"]

2
telco_ref_design_specs/ran/telco-ran-ref-du-crs.adoc
View File

@@ -14,7 +14,7 @@ CR fields you can change are annotated in the CR with YAML comments.
[NOTE]
====
You can extract the complete set of RAN DU CRs from the `ztp-site-generate` container image.
See link:https://docs.openshift.com/container-platform/latest/scalability_and_performance/ztp_far_edge/ztp-preparing-the-hub-cluster.html#ztp-preparing-the-ztp-git-repository_ztp-preparing-the-hub-cluster[Preparing the GitOps ZTP site configuration repository] for more information.
See link:https://docs.openshift.com/container-platform/4.15/scalability_and_performance/ztp_far_edge/ztp-preparing-the-hub-cluster.html#ztp-preparing-the-ztp-git-repository_ztp-preparing-the-hub-cluster[Preparing the GitOps ZTP site configuration repository] for more information.
====
include::modules/telco-ran-crs-day-2-operators.adoc[leveloffset=+1]