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: test/operator-framework-e2e/README.md
+18-20Lines changed: 18 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,13 @@
1
1
# Cross-component E2E for operator framework
2
2
3
3
This is a cross-component demo with all OLM v1 repositories. The ginkgo test does the following:
4
-
-Automates the creation of `plain+v0` bundles and FBCs for a set of bundle manifest directories.
4
+
-Uses operator-sdk and kustomize to build `plain+v0` bundles and create catalogs to include the bundles.
5
5
- Installs, upgrades and deletes a `plain+v0` operator.
6
6
- Uses operator-sdk to build `registry+v1` bundles and create catalogs to include the bundles.
7
7
- Installs, upgrades and deletes a `registry+v1` operator.
8
8
9
+
The steps in the ginkgo test can be summarized as follows:
10
+
9
11
1. start with an empty directory
10
12
2. call operator-sdk to initialize and generate an operator
11
13
3. generate a bundle directory
@@ -27,10 +29,9 @@ This is a cross-component demo with all OLM v1 repositories. The ginkgo test doe
27
29
28
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:
29
31
30
-
- Setting up a kind cluster.
32
+
- Setting up a kind cluster named `operator-controller-op-dev-e2e`.
31
33
- Installing the operator controller onto the cluster.
32
-
- Downloading the opm tool.
33
-
- Installing the operator-sdk.
34
+
- Setting up `opm`, `operator-sdk` and `kustomize` using bingo.
34
35
- Setting up a local registry server for building and loading images.
35
36
36
37
- The following structs defined are required as input for both plain+v0 and registry+v1 bundles:
@@ -47,11 +48,11 @@ This is a cross-component demo with all OLM v1 repositories. The ginkgo test doe
47
48
imageRef string
48
49
}
49
50
```
50
-
- `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]
51
52
- `bundles` - Stores the data relevant to different versions of the bundle.
52
53
- `bInputDir` - The input directory containing the specific version of the bundle data.
53
54
- `bundleVersion` - The specific version of the bundle data.
54
-
- `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>`
55
56
- For getting catalog related inputs:
56
57
```
57
58
type CatalogDInfo struct {
@@ -63,11 +64,11 @@ This is a cross-component demo with all OLM v1 repositories. The ginkgo test doe
63
64
fbcFileName string
64
65
}
65
66
```
66
-
- `baseFolderPath` - Base path of the folder for the catalogs.
67
+
- `baseFolderPath` - Base/root path of the folder for the catalogs.
67
68
- `operatorName` - Name of the operator to be installed from the bundles.
68
69
- `desiredChannelName` - Desired channel name for the operator.
69
70
- `catalogDir` - This is formed. The directory to store the FBC. The formed value will be of the format: `<operator-name>-catalog`
70
-
- `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`
71
72
- `fbcFileName` - Name of the FBC file. This is hard-coded as `catalog.yaml`.
72
73
- For getting information related to the install/upgrade action for operators:
73
74
```
@@ -80,20 +81,17 @@ This is a cross-component demo with all OLM v1 repositories. The ginkgo test doe
80
81
- `upgradeVersion` - Version of the operator to be upgraded on the cluster.
81
82
82
83
### Plain bundles
83
-
- Plain bundle manifests are taken as input.
84
-
85
-
- 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.
86
86
```
87
-
bundles/
88
-
└── plain-v0/
89
-
├── plain.v<version>/
90
-
│ ├── manifests
91
-
│ └── Dockerfile
92
-
└── plain.v<version>/
93
-
├── manifests
94
-
└── Dockerfile
87
+
type SdkProjectInfo struct {
88
+
projectName string
89
+
domainName string
90
+
group string
91
+
version string
92
+
kind string
93
+
}
95
94
```
96
-
- The bundles should be present in the testdata folder.
97
95
98
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