Skip to content

Commit 54d70b2

Browse files
author
Stephen Smith
committed
telcodocs-82-ran-policies- peer review
1 parent 0f8d463 commit 54d70b2

6 files changed

+482
-0
lines changed

‎modules/ztp-applying-source-custom-resource-policies.adoc‎

Lines changed: 159 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,159 @@
1+
// Module included in the following assemblies:
2+
//
3+
// scalability_and_performance/ztp-deploying-disconnected.adoc
4+
5+
[id="ztp-applying-source-custom-resource-policies_{context}"]
6+
= Applying source custom resource policies
7+
8+
Source custom resource policies include the following:
9+
10+
* SR-IOV policies
11+
* PTP policies
12+
* Performance Add-on Operator policies
13+
* MachineConfigPool policies
14+
* SCTP policies
15+
16+
You need to define the source custom resource that generates the ACM policy with consideration of possible overlay to its metadata or spec/data.
17+
For example, a `common-namespace-policy` contains a `Namespace` definition that exists in all managed clusters.
18+
This `namespace` is placed under the Common category and there are no changes for its spec or data across all clusters.
19+
20+
.Namespace policy example
21+
22+
The following example shows the source custom resource for this namespace:
23+
24+
[source,yaml]
25+
----
26+
apiVersion: v1
27+
kind: Namespace
28+
metadata:
29+
name: openshift-sriov-network-operator
30+
labels:
31+
openshift.io/run-level: "1"
32+
----
33+
34+
.Example output
35+
36+
The generated policy that applies this `namespace` includes the `namespace` as it is defined above without any change, as shown in this example:
37+
38+
[source,yaml]
39+
----
40+
apiVersion: policy.open-cluster-management.io/v1
41+
kind: Policy
42+
metadata:
43+
name: common-sriov-sub-ns-policy
44+
namespace: common-sub
45+
annotations:
46+
policy.open-cluster-management.io/categories: CM Configuration Management
47+
policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
48+
policy.open-cluster-management.io/standards: NIST SP 800-53
49+
spec:
50+
remediationAction: enforce
51+
disabled: false
52+
policy-templates:
53+
- objectDefinition:
54+
apiVersion: policy.open-cluster-management.io/v1
55+
kind: ConfigurationPolicy
56+
metadata:
57+
name: common-sriov-sub-ns-policy-config
58+
spec:
59+
remediationAction: enforce
60+
severity: low
61+
namespaceselector:
62+
exclude:
63+
- kube-*
64+
include:
65+
- '*'
66+
object-templates:
67+
- complianceType: musthave
68+
objectDefinition:
69+
apiVersion: v1
70+
kind: Namespace
71+
metadata:
72+
labels:
73+
openshift.io/run-level: "1"
74+
name: openshift-sriov-network-operator
75+
----
76+
77+
.SRIOV policy example
78+
79+
The following example shows a `SriovNetworkNodePolicy` definition that exists in different clusters with a different specification for each cluster.
80+
The example also shows the source custom resource for the `SriovNetworkNodePolicy`:
81+
82+
[source,yaml]
83+
----
84+
apiVersion: sriovnetwork.openshift.io/v1
85+
kind: SriovNetworkNodePolicy
86+
metadata:
87+
name: sriov-nnp
88+
namespace: openshift-sriov-network-operator
89+
spec:
90+
# The $ tells the policy generator to overlay/remove the spec.item in the generated policy.
91+
deviceType: $deviceType
92+
isRdma: false
93+
nicSelector:
94+
pfNames: [$pfNames]
95+
nodeSelector:
96+
node-role.kubernetes.io/worker: ""
97+
numVfs: $numVfs
98+
priority: $priority
99+
resourceName: $resourceName
100+
----
101+
102+
.Example output
103+
104+
The `SriovNetworkNodePolicy` name and `namespace` are the same for all clusters, so both are defined in the source `SriovNetworkNodePolicy`.
105+
However, the generated policy requires the `$deviceType`, `$numVfs`, as input parameters in order to adjust the policy for each cluster.
106+
The generated policy is shown in this example:
107+
108+
[source,yaml]
109+
----
110+
apiVersion: policy.open-cluster-management.io/v1
111+
kind: Policy
112+
metadata:
113+
name: site-du-sno-1-sriov-nnp-mh-policy
114+
namespace: sites-sub
115+
annotations:
116+
policy.open-cluster-management.io/categories: CM Configuration Management
117+
policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
118+
policy.open-cluster-management.io/standards: NIST SP 800-53
119+
spec:
120+
remediationAction: enforce
121+
disabled: false
122+
policy-templates:
123+
- objectDefinition:
124+
apiVersion: policy.open-cluster-management.io/v1
125+
kind: ConfigurationPolicy
126+
metadata:
127+
name: site-du-sno-1-sriov-nnp-mh-policy-config
128+
spec:
129+
remediationAction: enforce
130+
severity: low
131+
namespaceselector:
132+
exclude:
133+
- kube-*
134+
include:
135+
- '*'
136+
object-templates:
137+
- complianceType: musthave
138+
objectDefinition:
139+
apiVersion: sriovnetwork.openshift.io/v1
140+
kind: SriovNetworkNodePolicy
141+
metadata:
142+
name: sriov-nnp-du-mh
143+
namespace: openshift-sriov-network-operator
144+
spec:
145+
deviceType: vfio-pci
146+
isRdma: false
147+
nicSelector:
148+
pfNames:
149+
- ens7f0
150+
nodeSelector:
151+
node-role.kubernetes.io/worker: ""
152+
numVfs: 8
153+
resourceName: du_mh
154+
----
155+
156+
[NOTE]
157+
====
158+
Defining the required input parameters as `$value`, for example `$deviceType`, is not mandatory. The `$` tells the policy generator to overlay or remove the item from the generated policy. Otherwise, the value does not change.
159+
====

‎modules/ztp-applying-the-ran-policies-for-monitoring-cluster-activity.adoc‎

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
// Module included in the following assemblies:
2+
//
3+
// scalability_and_performance/ztp-deploying-disconnected.adoc
4+
5+
[id="ztp-applying-the-ran-policies-for-monitoring-cluster-activity_{context}"]
6+
= Applying the RAN policies for monitoring cluster activity
7+
8+
Zero touch provisioning (ZTP) uses {rh-rhacm-first} as an orchestrator to apply the radio access network (RAN) policies using a policy-based governance approach to automatically monitor cluster activity.
9+
10+
The policy generator (PolicyGen) is a Kustomize plugin that facilitates creating ACM policies from predefined custom resources.
11+
There are three main items: Policy Categorization, Source CR policy, and PolicyGenTemplate. PolicyGen relies on these to generate the policies and
12+
their placement bindings and rules.
13+
14+
RAN policies are categorized into three main groups:
15+
16+
Common:: A policy that exists in the `Common` category is applied to all clusters to be represented by the site plan.
17+
18+
Groups:: A policy that exists in the `Groups` category is applied to a group of clusters. Every group of clusters could have their own policies that exist under the
19+
Groups category. For example, `Groups/group1` could have its own policies that are applied to the clusters belonging to `group1`.
20+
21+
Sites:: A policy that exists in the `Sites` category is applied to a specific cluster. Any cluster could have its own policies that exist in the `Sites` category.
22+
For example, `Sites/cluster1` will have its own policies applied to `cluster1`.

‎modules/ztp-generating-ran-policies.adoc‎

Lines changed: 108 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,108 @@
1+
// Module included in the following assemblies:
2+
//
3+
// scalability_and_performance/ztp-deploying-disconnected.adoc
4+
5+
[id="ztp-generating-ran-policies_{context}"]
6+
= Generating RAN policies
7+
8+
.Prerequisites
9+
10+
* Install Kustomize
11+
* Install golang
12+
13+
.Procedure
14+
15+
. Build the plug-in using the following commands:
16+
+
17+
[source,terminal]
18+
----
19+
$ cd ztp/ztp-policy-generator/kustomize/plugin/policyGenerator/v1/policygenerator/
20+
----
21+
+
22+
[source,terminal]
23+
----
24+
$ go build -o PolicyGenerator
25+
----
26+
+
27+
The `kustomization.yaml` file has a reference to the `policyGenerator.yaml` file. The following example shows the PolicyGenerator definition:
28+
+
29+
[source,yaml]
30+
----
31+
apiVersion: policyGenerator/v1
32+
kind: PolicyGenerator
33+
metadata:
34+
name: acm-policy
35+
namespace: acm-policy-generator
36+
# The arguments should be given and defined as below with same order --policyGenTempPath= --sourcePath= --outPath= --stdout --customResources
37+
argsOneLiner: ./ranPolicyGenTempExamples ./sourcePolicies ./out true false
38+
----
39+
+
40+
Where:
41+
42+
* `policyGenTempPath` is the path to the `policyGenTemp` files.
43+
* `sourcePath`: is the path to the source policies.
44+
* `outPath`: is the path to save the generated ACM policies.
45+
* `stdout`: If `true`, prints the generated policies to the console.
46+
* `customResources`: If `true` generates the CRs from the `sourcePolicies` files without ACM policies.
47+
48+
. Test PolicyGen by running the following commands:
49+
+
50+
[source,terminal]
51+
----
52+
$ cd cnf-features-deploy/ztp/ztp-policy-generator/
53+
----
54+
+
55+
[source,terminal]
56+
----
57+
$ XDG_CONFIG_HOME=./ kustomize build --enable-alpha-plugins
58+
----
59+
+
60+
An `out` directory is created with the expected policies, as shown in this example:
61+
+
62+
[source,terminal]
63+
----
64+
out
65+
├── common
66+
│ ├── common-log-sub-ns-policy.yaml
67+
│ ├── common-log-sub-oper-policy.yaml
68+
│ ├── common-log-sub-policy.yaml
69+
│ ├── common-pao-sub-catalog-policy.yaml
70+
│ ├── common-pao-sub-ns-policy.yaml
71+
│ ├── common-pao-sub-oper-policy.yaml
72+
│ ├── common-pao-sub-policy.yaml
73+
│ ├── common-policies-placementbinding.yaml
74+
│ ├── common-policies-placementrule.yaml
75+
│ ├── common-ptp-sub-ns-policy.yaml
76+
│ ├── common-ptp-sub-oper-policy.yaml
77+
│ ├── common-ptp-sub-policy.yaml
78+
│ ├── common-sriov-sub-ns-policy.yaml
79+
│ ├── common-sriov-sub-oper-policy.yaml
80+
│ └── common-sriov-sub-policy.yaml
81+
├── groups
82+
│ ├── group-du
83+
│ │ ├── group-du-mc-chronyd-policy.yaml
84+
│ │ ├── group-du-mc-mount-ns-policy.yaml
85+
│ │ ├── group-du-mcp-du-policy.yaml
86+
│ │ ├── group-du-mc-sctp-policy.yaml
87+
│ │ ├── group-du-policies-placementbinding.yaml
88+
│ │ ├── group-du-policies-placementrule.yaml
89+
│ │ ├── group-du-ptp-config-policy.yaml
90+
│ │ └── group-du-sriov-operconfig-policy.yaml
91+
│ └── group-sno-du
92+
│ ├── group-du-sno-policies-placementbinding.yaml
93+
│ ├── group-du-sno-policies-placementrule.yaml
94+
│ ├── group-sno-du-console-policy.yaml
95+
│ ├── group-sno-du-log-forwarder-policy.yaml
96+
│ └── group-sno-du-log-policy.yaml
97+
└── sites
98+
└── site-du-sno-1
99+
├── site-du-sno-1-policies-placementbinding.yaml
100+
├── site-du-sno-1-policies-placementrule.yaml
101+
├── site-du-sno-1-sriov-nn-fh-policy.yaml
102+
├── site-du-sno-1-sriov-nnp-mh-policy.yaml
103+
├── site-du-sno-1-sriov-nw-fh-policy.yaml
104+
├── site-du-sno-1-sriov-nw-mh-policy.yaml
105+
└── site-du-sno-1-.yaml
106+
----
107+
+
108+
The common policies are flat because they will be applied to all clusters. However, the groups and sites have subdirectories for each group and site as they will be applied to different clusters.

0 commit comments

Comments
 (0)