Add watcher target to deploy operator via olm

[raukadah]

This pr adds two targets:
* make watcher: It generates olm.yaml file and installs the
watcher-operator using oc.
* make watcher_cleanup: It generates the olm.yaml file and undeploy
the watcher-operator using oc.

It also provides $CATALOG_IMAGE var to pass custom watcher-operator index image.

Jira: https://issues.redhat.com/browse/OSPRH-11419

[amoralej]

Why not to stick tot the starndard way of doing things of other operators via install_yamls? I think, it'd be good at least for consistency with the rest.

[amoralej]

This is failing in my test:

$ make watcher error: arguments in resource/name form must have a single resource and name bash ci/olm.sh oc apply -f ci/olm.yaml namespace/openstack-operators created catalogsource.operators.coreos.com/watcher-operator-index created operatorgroup.operators.coreos.com/openstack created subscription.operators.coreos.com/watcher-operator created timeout 30 bash -c 'until [ "" == "Succeeded" ]; do sleep 5; done' make: *** [Makefile:383: watcher] Error 124

I'd say it's not related to timeout, i tested with a much longer one and get the same issue.

[raukadah]

Thank you @amoralej for testing it! I realized I also hit the same issue in multiple runs. I have fixed it now.

[cescgina]

@raukadah I'm hitting the same problem, I think the problem is that by the time the first oc get csv runs, the csv does not yet exist, so it can't capture any name to use in the second command

[raukadah]

@cescgina Thank you for the review. Can you try now?

[cescgina]

@raukadah thanks, the last version works perfectly!

[raukadah]

Why not to stick tot the starndard way of doing things of other operators via install_yamls? I think, it'd be good at least for consistency with the rest.

@amoralej Thank you for review it. While implementing I went with both approach Install_yamls one targets and keeping target in watcher-operator repo.

The service operator target in install_yamls are not much used for development. For installing watcher-operator in install_yamls and VA based CI, we will be needing manifest files to deploy watcher operator. So, we wanted to keep the manifest file in watcher-operator and reuse the same at all places. That's why we have not went via install_yamls route.
If we want to go via install_yamls route to follow the same standard, I will update the pr.

In future, watcher-operator will be installed via openstack-operator. It might not needed.

[raukadah]

Why not to stick tot the starndard way of doing things of other operators via install_yamls? I think, it'd be good at least for consistency with the rest.

@amoralej Thank you for review it. While implementing I went with both approach Install_yamls one targets and keeping target in watcher-operator repo.

The service operator target in install_yamls are not much used for development. For installing watcher-operator in install_yamls and VA based CI, we will be needing manifest files to deploy watcher operator. So, we wanted to keep the manifest file in watcher-operator and reuse the same at all places. That's why we have not went via install_yamls route. If we want to go via install_yamls route to follow the same standard, I will update the pr.

In future, watcher-operator will be installed via openstack-operator. It might not needed.

Based on the discussion on team call, we will be defining the make targets in install_yamls and then clone the install_yamls repo and then reuse it in watcher-operator repo. Thank you @amoralej :-)

[marios]

Why not to stick tot the starndard way of doing things of other operators via install_yamls? I think, it'd be good at least for consistency with the rest.

@amoralej Thank you for review it. While implementing I went with both approach Install_yamls one targets and keeping target in watcher-operator repo.
The service operator target in install_yamls are not much used for development. For installing watcher-operator in install_yamls and VA based CI, we will be needing manifest files to deploy watcher operator. So, we wanted to keep the manifest file in watcher-operator and reuse the same at all places. That's why we have not went via install_yamls route. If we want to go via install_yamls route to follow the same standard, I will update the pr.
In future, watcher-operator will be installed via openstack-operator. It might not needed.

Based on the discussion on team call, we will be defining the make targets in install_yamls and then clone the install_yamls repo and then reuse it in watcher-operator repo. Thank you @amoralej :-)

My understanding was we would have the make targets defined in this repo (as you have done here) and then we can also add targets in install_yamls which would call these ones (if we need/wanted to have them in install_yamls too for consistency or if anyone else wanted to install this).

Is that right? ^ I am a bit confused by Chkumar last comment that we clone install_yamls and re-use it here for the installation (which implies the targets are defined in install_yamls)

[amoralej]

Why not to stick tot the starndard way of doing things of other operators via install_yamls? I think, it'd be good at least for consistency with the rest.

@amoralej Thank you for review it. While implementing I went with both approach Install_yamls one targets and keeping target in watcher-operator repo.
The service operator target in install_yamls are not much used for development. For installing watcher-operator in install_yamls and VA based CI, we will be needing manifest files to deploy watcher operator. So, we wanted to keep the manifest file in watcher-operator and reuse the same at all places. That's why we have not went via install_yamls route. If we want to go via install_yamls route to follow the same standard, I will update the pr.
In future, watcher-operator will be installed via openstack-operator. It might not needed.

Based on the discussion on team call, we will be defining the make targets in install_yamls and then clone the install_yamls repo and then reuse it in watcher-operator repo. Thank you @amoralej :-)

My understanding was we would have the make targets defined in this repo (as you have done here) and then we can also add targets in install_yamls which would call these ones (if we need/wanted to have them in install_yamls too for consistency or if anyone else wanted to install this).

Is that right? ^ I am a bit confused by Chkumar last comment that we clone install_yamls and re-use it here for the installation (which implies the targets are defined in install_yamls)

That was also my understanding of the conversation.

From my side, we can move on with this PR.

[raukadah]

Why not to stick tot the starndard way of doing things of other operators via install_yamls? I think, it'd be good at least for consistency with the rest.

@amoralej Thank you for review it. While implementing I went with both approach Install_yamls one targets and keeping target in watcher-operator repo.
The service operator target in install_yamls are not much used for development. For installing watcher-operator in install_yamls and VA based CI, we will be needing manifest files to deploy watcher operator. So, we wanted to keep the manifest file in watcher-operator and reuse the same at all places. That's why we have not went via install_yamls route. If we want to go via install_yamls route to follow the same standard, I will update the pr.
In future, watcher-operator will be installed via openstack-operator. It might not needed.

Based on the discussion on team call, we will be defining the make targets in install_yamls and then clone the install_yamls repo and then reuse it in watcher-operator repo. Thank you @amoralej :-)

My understanding was we would have the make targets defined in this repo (as you have done here) and then we can also add targets in install_yamls which would call these ones (if we need/wanted to have them in install_yamls too for consistency or if anyone else wanted to install this).
Is that right? ^ I am a bit confused by Chkumar last comment that we clone install_yamls and re-use it here for the installation (which implies the targets are defined in install_yamls)

That was also my understanding of the conversation.

From my side, we can move on with this PR.

Thank you @amoralej @marios for correcting it. We will define the target here in watcher-operator and reuse it in install_yamls. But I still think adding target in install_yamls (calling watcher-operator target) will confuse the user. I think we can keep the watcher-operator target only.

[cescgina]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amoralej

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [amoralej]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment