You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/ztp-adding-new-content-to-gitops-ztp.adoc
+23-23Lines changed: 23 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ Perform the following procedure to add new content to the {ztp} pipeline.
13
13
14
14
. Create a subdirectory named `source-crs` in the directory that contains the `kustomization.yaml` file for the `PolicyGenTemplate` custom resource (CR).
15
15
16
-
. Add your custom CRs to the `source-crs` subdirectory, as shown in the following example:
16
+
. Add your user-provided CRs to the `source-crs` subdirectory, as shown in the following example:
17
17
+
18
18
[source,text]
19
19
----
@@ -42,54 +42,54 @@ example
42
42
apiVersion: ran.openshift.io/v1
43
43
kind: PolicyGenTemplate
44
44
metadata:
45
-
name: "group-dev"
46
-
namespace: "ztp-clusters"
45
+
name: "group-dev"
46
+
namespace: "ztp-clusters"
47
47
spec:
48
48
bindingRules:
49
-
dev: "true"
50
-
mcp: "master"
49
+
dev: "true"
50
+
mcp: "master"
51
51
sourceFiles:
52
52
# These policies/CRs come from the internal container Image
= Preparing the {ztp} site configuration repository for version independence
8
8
9
-
You can use {ztp} to manage source custom resources (CRs) for managed clusters that are running different versions of {product-title}.
10
-
This means that the version of {product-title} running on the hub cluster can be independent of the version running on the managed clusters.
9
+
You can use {ztp} to manage source custom resources (CRs) for managed clusters that are running different versions of {product-title}.
10
+
This means that the version of {product-title} running on the hub cluster can be independent of the version running on the managed clusters.
11
11
12
12
.Procedure
13
13
14
14
. Create a directory structure with separate paths for the `SiteConfig` and `PolicyGenTemplate` CRs.
15
15
16
16
. Within the `PolicyGenTemplate` directory, create a directory for each {product-title} version you want to make available.
17
-
For each version, create the following resources:
17
+
For each version, create the following resources:
18
18
* `kustomization.yaml` file that explicitly includes the files in that directory
19
19
* `source-crs` directory to contain reference CR configuration files from the `ztp-site-generate` container
20
20
21
-
. In the `/siteconfig` directory, create a subdirectory for each {product-title} version you want to make available. For each version, create at least one directory for reference CRs to be copied from the container. There is no restriction on the naming of directories or on the number of reference directories. If you want to work with custom CRs, you must create a separate directory for those.
21
+
. In the `/siteconfig` directory, create a subdirectory for each {product-title} version you want to make available. For each version, create at least one directory for reference CRs to be copied from the container. There is no restriction on the naming of directories or on the number of reference directories. If you want to work with user-provided CRs, you must create a separate directory for those.
22
22
+
23
-
The following example describes a structure using custom CRs for different versions of {product-title}:
23
+
The following example describes a structure using user-provided CRs for different versions of {product-title}:
24
24
+
25
25
[source,text]
26
26
----
27
27
├── policygentemplates
28
-
│ ├── kustomization.yaml <1>
28
+
│ ├── kustomization.yaml <1>
29
29
│ ├── version_4.13 <2>
30
30
│ │ ├── common-ranGen.yaml
31
31
│ │ ├── group-du-sno-ranGen.yaml
@@ -42,50 +42,50 @@ The following example describes a structure using custom CRs for different versi
42
42
│ ├── kustomization.yaml <3>
43
43
│ ├── ns.yaml
44
44
│ └── source-crs/ <4>
45
-
└── siteconfig
45
+
└── siteconfig
46
46
├── kustomization.yaml
47
47
├── version_4.13
48
48
│ ├── helix56-v413.yaml
49
49
│ ├── kustomization.yaml
50
-
│ ├── extra-manifest/ <5>
51
-
│ └── custom-manifest/ <6>
52
-
└── version_4.14
50
+
│ ├── extra-manifest/ <5>
51
+
│ └── custom-manifest/ <6>
52
+
└── version_4.14
53
53
├── helix57-v414.yaml
54
54
├── kustomization.yaml
55
-
├── extra-manifest/ <5>
56
-
└── custom-manifest/ <6>
55
+
├── extra-manifest/ <5>
56
+
└── custom-manifest/ <6>
57
57
58
58
----
59
59
<1> Create a top-level `kustomization` yaml file.
60
60
<2> Create the version-specific directories within the custom `/policygentemplates` directory.
61
-
<3> Create a `kustomization.yaml` file for each version.
62
-
<4> Create a `source-crs` directory for each version to contain reference CRs from the `ztp-site-generate` container.
61
+
<3> Create a `kustomization.yaml` file for each version.
62
+
<4> Create a `source-crs` directory for each version to contain reference CRs from the `ztp-site-generate` container.
63
63
<5> Create a directory within the custom `/siteconfig` directory to contain extra manifests from the `ztp-site-generate` container.
64
-
<6> Create a folder to hold custom CRs.
64
+
<6> Create a folder to hold user-provided CRs.
65
65
+
66
66
[NOTE]
67
67
====
68
-
In the previous example, each version subdirectory in the custom `/siteconfig` directory contains two further subdirectories, one containing the reference manifests copied from the container, the other for custom manifests that you provide.
69
-
The names assigned to those directories are examples.
70
-
If you use custom CRs, the last directory listed under `extraManifests.searchPaths` in the `SiteConfig` CR must be the directory containing custom CRs.
68
+
In the previous example, each version subdirectory in the custom `/siteconfig` directory contains two further subdirectories, one containing the reference manifests copied from the container, the other for custom manifests that you provide.
69
+
The names assigned to those directories are examples.
70
+
If you use user-provided CRs, the last directory listed under `extraManifests.searchPaths` in the `SiteConfig` CR must be the directory containing user-provided CRs.
71
71
====
72
72
73
73
. Edit the `SiteConfig` CR to include the search paths of any directories you have created.
74
74
The first directory that is listed under `extraManifests.searchPaths` must be the directory containing the reference manifests.
75
-
Consider the order in which the directories are listed.
75
+
Consider the order in which the directories are listed.
76
76
In cases where directories contain files with the same name, the file in the final directory takes precedence.
77
77
+
78
78
.Example SiteConfig CR
79
79
+
80
-
[source,yaml]
80
+
[source,yaml]
81
81
----
82
82
extraManifests:
83
83
searchPaths:
84
84
- extra-manifest/ <1>
85
85
- custom-manifest/ <2>
86
86
----
87
87
<1> The directory containing the reference manifests must be listed first under `extraManifests.searchPaths`.
88
-
<2> If you are using custom CRs, the last directory listed under `extraManifests.searchPaths` in the `SiteConfig` CR must be the directory containing those custom CRs.
88
+
<2> If you are using user-provided CRs, the last directory listed under `extraManifests.searchPaths` in the `SiteConfig` CR must be the directory containing those user-provided CRs.
89
89
90
90
. Edit the top-level `kustomization.yaml` file to control which {product-title} versions are active. The following is an example of a `kustomization.yaml` file at the top level:
0 commit comments