Bug 1685417 - Default asb/tsb operator image in marketplace should be downstream image
Summary: Default asb/tsb operator image in marketplace should be downstream image
Keywords:
Status: CLOSED DUPLICATE of bug 1685458
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Service Broker
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.1.0
Assignee: Shawn Hurley
QA Contact: Zhang Cheng
URL:
Whiteboard:
Depends On:
Blocks: 1680535 1689787 1689788
TreeView+ depends on / blocked
 
Reported: 2019-03-05 07:15 UTC by Zihan Tang
Modified: 2019-03-29 20:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1672005
Environment:
Last Closed: 2019-03-29 20:16:24 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Zihan Tang 2019-03-05 07:15:23 UTC
Description of problem:
Using marketplace to subscribe tsb/asb operator, it should not use upstream image as default.


Version-Release number of selected component (if applicable):
4.0.0-0.nightly-2019-03-05-034154

How reproducible:
always

Steps to Reproduce:
1. install ocp 4.0
2. create namespace openshift-ansible-service-broker or openshift-template-service-broker
3. subscribe automation broker operator or templateservicebroker operator from  Operator Hub-> Community. 
4. check images of operator

Actual results:
the images of operators:

docker.io/automationbroker/automation-broker-operator:v4.0
docker.io/automationbroker/template-service-broker-operator:v4.0

Expected results:
should linked to some downstream images

Additional info:
Other comminuty operators also have this kind of issue.
It's better to use a same solution for this.
refer to: 
https://bugzilla.redhat.com/show_bug.cgi?id=1672005
https://bugzilla.redhat.com/show_bug.cgi?id=1628066

Comment 1 Zihan Tang 2019-03-05 07:28:55 UTC
cc @aravindh
Till now, Redhat-comminuty operators(etcd/Prometheus/Logging/ASB/TSB) all have this issue, what's the suggestion from marketplace design side?

Comment 2 Aravindh Puthiyaparambil 2019-03-05 15:14:08 UTC
(In reply to Zihan Tang from comment #1)
> cc @aravindh
> Till now, Redhat-comminuty operators(etcd/Prometheus/Logging/ASB/TSB) all
> have this issue, what's the suggestion from marketplace design side?

I am not sure what you mean by Redhat-community operators. There are community operators (https://github.com/operator-framework/community-operators/tree/master/community-operators) where the images are not built by OSBS. These operators will always be onboarded through the community operators repository and are added on the cluster using "community-operators" OperatorSource CR. Then there are Red Hat operators that are *temporarily* being onboarded through https://github.com/operator-framework/community-operators/tree/master/redhat-operators/. These operators should have images built by OSBS. Once OSBS has their onboarding pipeline ready then we will stop onboarding "redhat-operators" through the repo. Either way, these operators will always be added to the cluster using the "redhat-operators" OperatorSource CR. I hope this clarifies the direction.

Comment 3 Shawn Hurley 2019-03-05 16:17:48 UTC
I am closing this as it is a duplicate.

*** This bug has been marked as a duplicate of bug 1685458 ***

Comment 4 Zihan Tang 2019-03-06 06:21:26 UTC
(In reply to Shawn Hurley from comment #3)
> I am closing this as it is a duplicate.
> 
> *** This bug has been marked as a duplicate of bug 1685458 ***

In this bug, I mean the default operator image when subscribe from 'Operartor Hub'
docker.io/automationbroker/automation-broker-operator:v4.0
docker.io/automationbroker/template-service-broker-operator:v4.0

In Bug 1685458 Default image to install ASB/TSB by operator, I mean 
docker.io/ansibleplaybookbundle/origin-ansible-service-broker:v4.0
docker.io/ansibleplaybookbundle/origin-template-service-broker:v4.0
should be downstream.

This may be all fixed in https://github.com/operator-framework/community-operators/blob/master/community-operators/automationbroker/automationbrokeroperator.v0.2.0.clusterserviceversion.yaml#L206 and #L210
But I'm not sure whether they will be resolved in the same downtream image process you mentioned, so I temporarily reopen this bug.
If it is YES, please re-close this. Thanks.

Comment 5 Zhang Cheng 2019-03-06 06:40:31 UTC
In fact, we more hope let's trace these two problems in separate places.

Comment 6 Zihan Tang 2019-03-06 10:16:16 UTC
(In reply to aravindh from comment #2)
> (In reply to Zihan Tang from comment #1)
> > cc @aravindh
> > Till now, Redhat-comminuty operators(etcd/Prometheus/Logging/ASB/TSB) all
> > have this issue, what's the suggestion from marketplace design side?
> 
> I am not sure what you mean by Redhat-community operators. There are
> community operators
> (https://github.com/operator-framework/community-operators/tree/master/
> community-operators) where the images are not built by OSBS. These operators
> will always be onboarded through the community operators repository and are
> added on the cluster using "community-operators" OperatorSource CR. 
Sorry for not clear about it. 
I mean 'Redhat-community operators' are these comminuty operators in https://github.com/operator-framework/community-operators but are developed and tested by Redhat team such as automationbroker operator, templateservicebroker operator, cluster-logging operators etc. 
when image in ClusterServiceVersion (https://github.com/operator-framework/community-operators/blob/master/community-operators/automationbroker/automationbrokeroperator.v0.2.0.clusterserviceversion.yaml) link to a specific version such as operator:v4.0, if we release new z stream image(such as 4.1), developer have to create new PR to change the image tag, for example to operator:v4.1. Is this correct? 
In this situation, no matter what kind of operator it is (comminuty or Red Hat operators), If image tag changes, it needs code change in community-operators repo to update the clusterserviceversion file. Is this correct?

So if in this case, we should always use 'latest' as image tag in csv, right?

Besides, how about the image repo suggested to be used for these non-OSBS build operators. Now some are using docker.io, some are using quay.io.

Comment 7 Aravindh Puthiyaparambil 2019-03-06 16:00:30 UTC
(In reply to Zihan Tang from comment #6)
> (In reply to aravindh from comment #2)
> > (In reply to Zihan Tang from comment #1)
> > > cc @aravindh
> > > Till now, Redhat-comminuty operators(etcd/Prometheus/Logging/ASB/TSB) all
> > > have this issue, what's the suggestion from marketplace design side?
> > 
> > I am not sure what you mean by Redhat-community operators. There are
> > community operators
> > (https://github.com/operator-framework/community-operators/tree/master/
> > community-operators) where the images are not built by OSBS. These operators
> > will always be onboarded through the community operators repository and are
> > added on the cluster using "community-operators" OperatorSource CR. 
> Sorry for not clear about it. 
> I mean 'Redhat-community operators' are these comminuty operators in
> https://github.com/operator-framework/community-operators but are developed
> and tested by Redhat team such as automationbroker operator,
> templateservicebroker operator, cluster-logging operators etc. 
> when image in ClusterServiceVersion
> (https://github.com/operator-framework/community-operators/blob/master/
> community-operators/automationbroker/automationbrokeroperator.v0.2.0.
> clusterserviceversion.yaml) link to a specific version such as
> operator:v4.0, if we release new z stream image(such as 4.1), developer have
> to create new PR to change the image tag, for example to operator:v4.1. Is
> this correct? 

Yes

> In this situation, no matter what kind of operator it is (comminuty or Red
> Hat operators), If image tag changes, it needs code change in
> community-operators repo to update the clusterserviceversion file. Is this
> correct?

Yes, code change == change in the CSV yaml

> 
> So if in this case, we should always use 'latest' as image tag in csv, right?

That is up to the operator author.

> 
> Besides, how about the image repo suggested to be used for these non-OSBS
> build operators. Now some are using docker.io, some are using quay.io.

For community operators, it is their choice. When it comes to "redhat-operators" they will point to images built by OSBS.

Comment 9 Shawn Hurley 2019-03-29 20:16:24 UTC
These bugs are the exact same underylying issue and should only be tracked in 1 bug

*** This bug has been marked as a duplicate of bug 1685458 ***


Note You need to log in before you can comment on or make changes to this bug.