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
These will be made available as annotations on the operator deployments, so that they can be used via downward API if desired. This may be particularly useful for operators that are tightly coupled to another particular image.
The images in the `image` list will be used to determine the set of related images that are required for the operator.
75
37
76
-
### Implementation
38
+
The images in this list will be considered related even if applying the config to the ClusterServiceVersion would not
39
+
transform it (i.e. the `name` of an image does not need to exist in the CSV).
77
40
78
-
#### ClusterServiceVersion Spec and Status
41
+
The kustomization will be applied to the CSV, so the `image` config may be used to overwrite the images in the deployment in the CSV.
79
42
80
-
Spec needs to be updated to include the fields described above, and the openapi validation should be updated as well.
43
+
### Why kustomize?
81
44
82
-
Note that the `name` field for related images must satisfy the annotation name conventions.
45
+
There are several other existing approaches to associating images with an application.
83
46
84
-
#### Install Strategy
47
+
CNAB: Using CNAB's `bundle.json` would allow us to associate image metadata, but comes with a heavy spec. CNAB bundles cannot be applied directly to a kubernetes cluster, they require additional tooling.
85
48
86
-
Most of the change will take place in the install strategy; which knows how to take the deployment spec defined in a CSV and check if the cluster is up-to-date, and apply changes if needed.
49
+
ImageStream: OpenShift ClusterOperators include an `image-references` file that contains an ImageStream object. This allows listing objects, but is not meaningful when applied to a cluster (despite being a real object), and can only be applied to OpenShift clusters.
87
50
88
-
- The install strategy will now need to know about related images.
89
-
- `CheckInstalled` will check that the annotations on the operator deployments include the `relatedImages` annotations.
90
-
- `Install` will also need to project the relatedImages as annotations on the deployment.
91
-
92
-
#### Implementation Stages
51
+
By using Kustomize's metadata, we:
93
52
94
-
- [ ] API Changes
95
-
- [ ] Annotation Projection on Deployments
53
+
- Have a way to list out images needed by the operator
54
+
- Have a way to override the images needed by the operator (without touching the base manifests)
55
+
- Retain `kubectl` compatibility; operator bundles can be applied to a cluster with `kubectl apply -k -f bundle`
96
56
97
-
### User Documentation
57
+
### Operator Registry Changes
98
58
99
-
#### Associating Related Images
59
+
If a bundle includes an `kustomization.yaml` file, images in this file are extracted during the `load` operation of a bundle into an
60
+
operator-registry database. With the following rules:
100
61
101
-
Operators often need to make use of other container images to perform their functions. For example, the etcd operator
102
-
makes use of etcd container images to create etcd clusters as requested by the user.
62
+
- Images are pulled from the ClusterServiceVersion `container` definitions as if kustomize has been run over it.
63
+
- Images are pulled from the `kustomization.yaml` file regardless of whether they are "used" by the bundle.
103
64
104
-
To indicate that such images are used by the operator, a ClusterServiceVersion author can fill out the `relatedImages`
105
-
field on the CSV spec.
65
+
If a bundle does not include a `kustomization.yaml` file, images are extracted from the ClusterServiceVersion `container` definitions.
106
66
107
-
These fields are optional, but should be filled out whenever possible. Tooling can take advantage of this information
108
-
to ensure that all required images are available in the cluster.
67
+
The `Query` interface for an operator-registry database will have two new APIs:
`ListImages`will list all images in an operator-registry database.
125
78
126
-
#### Using related images via downwardAPI
79
+
### Example
127
80
128
-
The related images can be consumed by the operator deployment. This may be useful if, for example, the operator
129
-
and operand images are tightly coupled. The `annotation` field from the `relatedImages` is used as the name of the annotation.
81
+
```sh
82
+
$ tree bundle
83
+
bundle
84
+
├── csv.yaml
85
+
└── kustomization.yaml
86
+
```
130
87
131
-
These will be made available as annotations on the operator deployments, so that they can be used via downward API if desired. This may be particularly useful for operators that are tightly coupled to another particular image.
Note that `quay.io/coreos/etcd-operator@sha256:66a37fd61a06a43969854ee6d3e21087a98b93838e284a6086b13917f96b0d9b` is not
121
+
included, since it would be replaced with `:latest` if the `kustomization.yaml` were applied.
122
+
123
+
### Future Work
124
+
125
+
#### Override Operand
126
+
127
+
Add a `relatedImages` field to the ClusterServiceVersion, and make use of kustomize's [transformer configs](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/transformerconfigs/images/README.md) to teach it about those fields.
128
+
`relatedImages`can be projected into operator deployments via downward API, which will allow the kustomization file to override operand images in addition to opeator images.
0 commit comments