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
This commit introduces a change to the way that the way the API function
bundle.GenerateFunc manages directory structure. Currently, the output
of that function creates a metadata folder with generated annotations
inside the given manifest directory. However, this is not how bundle
images are actually formatted, and the Dockerfile does some indirection
in order to copy the files into the correct directory.
However, we should consider the default behvaior of `generate` to be
"run once" (especially given that by default the regeneration does not
happen in the build function by default). The expectation is that
generate is a scaffolding method. Given that, we should scaffold the
metadata directory in the same manner as it would actually appear in the
union filesystem on the resulting container image.
In order to accomplish this, this PR makes a few functional changes:
- By default, create the metadata directory in the same parent directory
as the given manifest directory. This, at a high level, mirrors the
directory tree that will exist on the resulting bundle.
- Generates the dockerfile in the current working directory that the
function is called from. Modifies the dockerfile to point to the
relative path of the generated files
- Adds an option output directory parameter to the function (as well
as the shadowed `opm alpha bundle build/generate` commands) to
allow the user to generate a *new* bundle directory.
bundleBuildCmd.Flags().BoolVarP(&overwriteArgs, "overwrite", "o", false, "To overwrite annotations.yaml locally if existed. By default, overwrite is set to `false`.")
71
72
73
+
bundleBuildCmd.Flags().StringVarP(&outputDirArgs, "output-dir", "u", "", "Optional output directory for operator manifests")
Copy file name to clipboardexpand all lines: docs/design/operator-bundle.md
+25-5
Original file line number
Diff line number
Diff line change
@@ -119,13 +119,14 @@ Flags:
119
119
-e, --default string The default channel for the bundle image
120
120
-d, --directory string The directory where bundle manifests for a specific version are located.
121
121
-h, --help help for generate
122
+
-u, --output-dir string Optional output directory for operator manifests
122
123
-p, --package string The name of the package that bundle image belongs to
123
124
124
125
Note:
125
126
* All manifests yaml must be in the same directory.
126
127
```
127
128
128
-
The `--directory/-d`, `--channels/-c`, `--package/-p` are required flags while `--default/-e` is optional.
129
+
The `--directory/-d`, `--channels/-c`, `--package/-p` are required flags while `--default/-e` and `--output-dir/-u` are optional.
129
130
130
131
The command for `generate` task is:
131
132
```bash
@@ -145,17 +146,35 @@ The `--package` or `-p` is the name of package fo the operator such as `etcd` wh
145
146
146
147
All information in `annotations.yaml` is also existed in `LABEL` section of `Dockerfile`.
147
148
148
-
After the generate command is executed, the `Dockerfile` is generated in the same directory where the YAML manifests are located while the `annotations.yaml` file is located in a folder named `metadata`. For example:
149
+
After the generate command is executed, the `Dockerfile` is generated in the directory where command is run. By default, the `annotations.yaml` file is located in a folder named `metadata` in the same root directory as the input directory containing manifests. For example:
149
150
```bash
150
151
$ tree test
151
152
test
152
-
├── etcdcluster.crd.yaml
153
-
├── etcdoperator.clusterserviceversion.yaml
153
+
├── my-manifests
154
+
│ ├── etcdcluster.crd.yaml
155
+
│ └── etcdoperator.clusterserviceversion.yaml
154
156
├── metadata
155
157
│ └── annotations.yaml
156
158
└── Dockerfile
157
159
```
158
160
161
+
If the `--output-dir` parameter is specified, that directory becomes the parent for a new pair of folders `manifests/` and `metadata/`, where `manifests/` is a copy of the passed in directory of manifests and `metadata/` is the folder containing annotations.yaml:
162
+
163
+
```bash
164
+
$ tree test
165
+
test
166
+
├── my-manifests
167
+
│ ├── etcdcluster.crd.yaml
168
+
│ └── etcdoperator.clusterserviceversion.yaml
169
+
├── my-output-manifest-dir
170
+
│ ├── manifests
171
+
│ │ ├── etcdoperator.clusterserviceversion.yaml
172
+
│ │ └── etcdoperator.clusterserviceversion.yaml
173
+
│ └── metadata
174
+
│ └── annotations.yaml
175
+
└── Dockerfile
176
+
```
177
+
159
178
The `Dockerfile` can be used manually to build the bundle image using container image tools such as Docker, Podman or Buildah. For example, the Docker build command would be:
160
179
161
180
```bash
@@ -175,7 +194,8 @@ Flags:
175
194
-d, --directory string The directory where bundle manifests for a specific version are located
176
195
-h, --help help for build
177
196
-b, --image-builder string Tool to build container images. One of: [docker, podman, buildah] (default "docker")
178
-
-0, --overwrite To overwrite annotations.yaml if existing
197
+
-u, --output-dir string Optional output directory for operator manifests
198
+
-0, --overwrite To overwrite annotations.yaml if existing
179
199
-p, --package string The name of the package that bundle image belongs to
180
200
-t, --tag string The name of the bundle image will be built
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
11
+
12
+
_The Prometheus Open Cloud Service is Public Alpha. The goal before Beta is for additional user testing and minor bug fixes._
13
+
14
+
### Monitoring applications
15
+
16
+
Prometheus scrapes your application metrics based on targets maintained in a ServiceMonitor object. When alerts need to be sent, they are processsed by an AlertManager.
17
+
18
+
[Read the complete guide to monitoring applications with the Prometheus Open Cloud Service](https://coreos.com/tectonic/docs/latest/alm/prometheus-ocs.html)
19
+
20
+
## Supported Features
21
+
22
+
**High availability**
23
+
Multiple instances are run across failure zones and data is replicated. This keeps your monitoring available during an outage, when you need it most.
24
+
**Updates via automated operations**
25
+
New Prometheus versions are deployed using a rolling update with no downtime, making it easy to stay up to date.
26
+
**Handles the dynamic nature of containers**
27
+
Alerting rules are attached to groups of containers instead of individual instances, which is ideal for the highly dynamic nature of container deployment.
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
11
+
12
+
_The Prometheus Open Cloud Service is Public Alpha. The goal before Beta is for additional user testing and minor bug fixes._
13
+
14
+
### Monitoring applications
15
+
16
+
Prometheus scrapes your application metrics based on targets maintained in a ServiceMonitor object. When alerts need to be sent, they are processsed by an AlertManager.
17
+
18
+
[Read the complete guide to monitoring applications with the Prometheus Open Cloud Service](https://coreos.com/tectonic/docs/latest/alm/prometheus-ocs.html)
19
+
20
+
## Supported Features
21
+
22
+
**High availability**
23
+
Multiple instances are run across failure zones and data is replicated. This keeps your monitoring available during an outage, when you need it most.
24
+
**Updates via automated operations**
25
+
New Prometheus versions are deployed using a rolling update with no downtime, making it easy to stay up to date.
26
+
**Handles the dynamic nature of containers**
27
+
Alerting rules are attached to groups of containers instead of individual instances, which is ideal for the highly dynamic nature of container deployment.
0 commit comments