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
cc @aravindh Till now, Redhat-comminuty operators(etcd/Prometheus/Logging/ASB/TSB) all have this issue, what's the suggestion from marketplace design side?
(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.
I am closing this as it is a duplicate. *** This bug has been marked as a duplicate of bug 1685458 ***
(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.
In fact, we more hope let's trace these two problems in separate places.
(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.
(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.
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 ***