|
| 1 | +# Pull Bundle on a Cluster |
| 2 | + |
| 3 | +## Store a bundle in a `ConfigMap` |
| 4 | +Below is the directory layout of the operator bundle inside the image. |
| 5 | +```bash |
| 6 | +$ tree |
| 7 | +/ |
| 8 | +├── manifests |
| 9 | +│ ├── testbackup.crd.yaml |
| 10 | +│ ├── testcluster.crd.yaml |
| 11 | +│ ├── testoperator.v0.1.0.clusterserviceversion.yaml |
| 12 | +│ └── testrestore.crd.yaml |
| 13 | +└── metadata |
| 14 | + └── annotations.yaml |
| 15 | + |
| 16 | +$ cat /annotations.yaml |
| 17 | +annotations: |
| 18 | + operators.coreos.com.bundle.resources: "manifests+metadata" |
| 19 | + operators.coreos.com.bundle.mediatype: "operator-registry+v1" |
| 20 | +``` |
| 21 | + |
| 22 | +The following `ConfigMap` maps to the above operator bundle |
| 23 | +```yaml |
| 24 | +apiVersion: v1 |
| 25 | +kind: ConfigMap |
| 26 | +metadata: |
| 27 | + name: test |
| 28 | + namespace: test |
| 29 | + annotations: |
| 30 | + operators.coreos.com.bundle.resources: "manifests+metadata" |
| 31 | + operators.coreos.com.bundle.mediatype: "registry+v1" |
| 32 | +data: |
| 33 | + testbackup.crd.yaml: content of testbackup.crd.yaml |
| 34 | + testcluster.crd.yaml: content of testcluster.crd.yaml |
| 35 | + testoperator.v0.1.0.clusterserviceversion.yaml: content oftestoperator.v0.1.0.clusterserviceversion.yaml |
| 36 | + testrestore.crd.yaml: content of testrestore.crd.yaml |
| 37 | +``` |
| 38 | +
|
| 39 | +The `key` of a `ConfigMap` has the following format |
| 40 | +```go |
| 41 | + // Data contains the configuration data. |
| 42 | + // Each key must consist of alphanumeric characters, '-', '_' or '.'. |
| 43 | + // Values with non-UTF-8 byte sequences must use the BinaryData field. |
| 44 | + // The keys stored in Data must not overlap with the keys in |
| 45 | + // the BinaryData field, this is enforced during validation process. |
| 46 | + // +optional |
| 47 | + Data map[string]string `json:"data,omitempty" protobuf:"bytes,2,rep,name=data"` |
| 48 | +``` |
| 49 | + |
| 50 | +Notes: |
| 51 | +* The resource file name needs to be manipulated if it contains special characters. |
| 52 | +* The consumer of the `ConfigMap` does will not use the key name in `Data` section to identify the type of resource. It should inspect the content. |
| 53 | +* The consumer will iterate through the `Data` section and and add each resource to the bundle. |
| 54 | +* The annotations from the `annotations.yaml` file is copied to `metadata.annotations` to the `ConfigMap` |
| 55 | +* The `ConfigMap` may have a resource that contains a `PackageManifest` resource. The consumer needs to handle this properly. |
| 56 | + |
| 57 | + |
| 58 | +## Build a Bundle from ConfigMap |
| 59 | +```go |
| 60 | +import ( |
| 61 | + "github.com/operator-framework/operator-registry/pkg/registry" |
| 62 | + corev1 "k8s.io/api/core/v1" |
| 63 | +) |
| 64 | + |
| 65 | +// Manifest contains a bundle and a PackageManifest. |
| 66 | +type Manifest struct { |
| 67 | + Bundle *registry.Bundle |
| 68 | + PackageManifest *registry.PackageManifest |
| 69 | +} |
| 70 | + |
| 71 | +type Loader interface { |
| 72 | + Load(cm *corev1.ConfigMap) (manifest *Manifest, err error) |
| 73 | +} |
| 74 | +``` |
| 75 | + |
| 76 | +## Managing Lifecycle of the `ConfigMap` |
| 77 | + |
| 78 | +## Things that Happen after reading the configmap |
| 79 | + |
| 80 | + |
0 commit comments