Skip to content

Commit 00a6d87

Browse files
Merge pull request #73 from konflux-ci/HACDOCS-965-olm
Hacdocs 965 olm
2 parents c1356fb + 25d1884 commit 00a6d87

File tree

1 file changed

+41
-0
lines changed

1 file changed

+41
-0
lines changed
Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
= Building an Operator Lifecycle Manager (OLM) Operator in {ProductName}
2+
3+
If you are developing an application that aligns with the link:https://operatorframework.io/[Operator Framework], and managing it with link:https://olm.operatorframework.io/docs/[Operator Lifecycle Manager (OLM)], you can build that application in {ProductName}. We refer to such applications as OLM Operators.
4+
5+
OLM Operators include the following elements:
6+
7+
* Operator, which manages Operands
8+
* Operands, which are components or resources that the Operator manages
9+
* Bundle, which packages the Operator and Operands together as defined by a ClusterServiceVersion (CSV) file
10+
11+
Note the difference between an "OLM Operator" and an "Operator." An OLM Operator refers to the whole application, and an Operator is one part of the OLM Operator.
12+
13+
The first procedure in this document explains how to use {ProductName} to build an OLM Operator in the most basic sense--building its Operator and bundle images. The second procedure is optional but recommended. It explains how you can automatically update the image references in the CSV of the bundle.
14+
15+
16+
== Building the Operator and the bundle
17+
18+
[NOTE]
19+
====
20+
This procedure assumes that the source code for your Operator and bundle, including the Dockerfiles, are in the same git repository, per OLM convention.
21+
====
22+
23+
.Procedure
24+
25+
. In the {ProductName} UI, xref:../how-tos/creating.adoc[create a new application] for your OLM Operator in {ProductName}.
26+
. In your new application, xref:../how-tos/creating.adoc[add a new component] for your Operator. Be sure to specify the correct path to the Operator's Dockerfile within its git repository.
27+
. Add another component for your bundle. Enter the same URL that you used for the Operator, but enter the path to the bundle's Dockerfile.
28+
. (Optional) If you are using a File-based Catalog (FBC) for your OLM Operator, you must build the FBC as another component in its own separate application in {ProductName}.
29+
. (Optional) You may want to configure {ProductName} to xref:../how-tos/configuring/redundant-rebuilds.adoc[prevent redundant rebuilds] for this application. For example, you can configure {ProductName} to rebuild your bundle image only if a commit is made to its Dockerfile or the `/bundle` directory, instead of rebuilding it whenever any commit is made to your OLM Operator's git repository.
30+
31+
== Automating updates for image references in the CSV
32+
33+
.Procedure
34+
35+
. In the {ProductName} UI, in your OLM Operator's application, go to the *Components* tab and copy the URL for the Operator's container image. The URL should include `sha256:`.
36+
. Using your preferred text editor, in the git repo for your OLM Operator, open the CSV file for your bundle. In that file, update the image reference to the Operator to be the URL you just copied. Commit this change.
37+
. In the {ProductName} UI, follow the instructions in xref:../how-tos/configuring/component-nudges.adoc[this document] to define the relationship between the Operator and the bundle. The Operator nudges the bundle.
38+
. (Optional) For any Operands with image references in your bundle's CSV, you can repeat this same basic process:
39+
.. Add the Operands as components in {ProductName}.
40+
.. Wait for the first build of those components to finish.
41+
.. Copy the URL to the images and paste it as a reference in the bundle's CSV file.

0 commit comments

Comments
 (0)