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
Updated to generate plain manifests from an SDK project with kustomize;Restructed code to have a single It block in a describe block;Updated the README
11. delete the Operator CR (with kubectl operator)
22
+
12. delete the Catalog CR (with kubectl operator)
23
+
13. repeat steps 2-12 for each bundle format (e.g. registry+v1 and plain+v0)
9
24
## Objective
10
25
- Development on OLM v1 is split across multiple repositories, and the list of relevant repositories may grow over time. While we have demos showing improvements in functionality of components over time, it can be difficult to have a picture of the state of OLM v1 at any given time for someone not following its development closely. Having a single source to look for OLM v1 behavior can provide more clarity about the state of the project.
11
26
- With the scale of the OLM v1 project, it is useful to have a means to test components in the operator development + lifecycle pipeline together to create a more cohesive experience for all users.
@@ -14,10 +29,9 @@ This is a cross-component demo with all OLM v1 repositories. The ginkgo test doe
14
29
15
30
- Building operator-controller, deploying it into the cluster and rest of the configuration is done in the `MakeFile` of this repo under the target `operator-developer-e2e`. This includes:
16
31
17
-
- Setting up a kind cluster.
32
+
- Setting up a kind cluster named `operator-controller-op-dev-e2e`.
18
33
- Installing the operator controller onto the cluster.
19
-
- Downloading the opm tool.
20
-
- Installing the operator-sdk.
34
+
- Setting up `opm`, `operator-sdk` and `kustomize` using bingo.
21
35
- Setting up a local registry server for building and loading images.
22
36
23
37
- The following structs defined are required as input for both plain+v0 and registry+v1 bundles:
@@ -34,11 +48,11 @@ This is a cross-component demo with all OLM v1 repositories. The ginkgo test doe
34
48
imageRef string
35
49
}
36
50
```
37
-
- `baseFolderPath` - Base path of the folder for the specific bundle type input data.
51
+
- `baseFolderPath` - Base/root path of the folder for the specific bundle type input data.[path to plain-v0 or registry-v1 bundles testdata]
38
52
- `bundles` - Stores the data relevant to different versions of the bundle.
39
53
- `bInputDir` - The input directory containing the specific version of the bundle data.
40
54
- `bundleVersion` - The specific version of the bundle data.
41
-
- `imageRef` - This is formed. Stores the bundle image reference which will be of the format `localhost:5000/<operator_name>-bundle:v.<bundleVersion>`
55
+
- `imageRef` - This is formed. Stores the bundle image reference which will be of the format `localhost:5001/<operator_name>-bundle:v.<bundleVersion>`
42
56
- For getting catalog related inputs:
43
57
```
44
58
type CatalogDInfo struct {
@@ -50,11 +64,11 @@ This is a cross-component demo with all OLM v1 repositories. The ginkgo test doe
50
64
fbcFileName string
51
65
}
52
66
```
53
-
- `baseFolderPath` - Base path of the folder for the catalogs.
67
+
- `baseFolderPath` - Base/root path of the folder for the catalogs.
54
68
- `operatorName` - Name of the operator to be installed from the bundles.
55
69
- `desiredChannelName` - Desired channel name for the operator.
56
70
- `catalogDir` - This is formed. The directory to store the FBC. The formed value will be of the format: `<operator-name>-catalog`
57
-
- `imageRef` - This is formed. Stores the FBC image reference which will be of the format: `localhost:5000/<username>/<catalogDir>:test`
71
+
- `imageRef` - This is formed. Stores the FBC image reference which will be of the format: `localhost:5001/<username>/<catalogDir>:test`
58
72
- `fbcFileName` - Name of the FBC file. This is hard-coded as `catalog.yaml`.
59
73
- For getting information related to the install/upgrade action for operators:
60
74
```
@@ -67,20 +81,17 @@ This is a cross-component demo with all OLM v1 repositories. The ginkgo test doe
67
81
- `upgradeVersion` - Version of the operator to be upgraded on the cluster.
68
82
69
83
### Plain bundles
70
-
- Plain bundle manifests are taken as input.
71
-
72
-
- The plain bundle manifest directory taken as input should follow the below directory structure:
84
+
- The plain+v0 bundles are formed using `operator-sdk` and `kustomize`.
85
+
- The below input is used to form the bundle using operator-sdk.
73
86
```
74
-
bundles/
75
-
└── plain-v0/
76
-
├── plain.v<version>/
77
-
│ ├── manifests
78
-
│ └── Dockerfile
79
-
└── plain.v<version>/
80
-
├── manifests
81
-
└── Dockerfile
87
+
type SdkProjectInfo struct {
88
+
projectName string
89
+
domainName string
90
+
group string
91
+
version string
92
+
kind string
93
+
}
82
94
```
83
-
- The bundles should be present in the testdata folder.
84
95
85
96
- After the bundle image is created and loaded, the FBC is formed by a custom routine by using the operatorName, desiredChannelName, bundle imageRefs and bundleVersions.
0 commit comments