search

integr8ly / application-monitoring-operator

Operator for installing the Application Monitoring Stack on OpenShift (Prometheus, AlertManager, Grafana)
Apache License 2.0
30 stars 44 forks source link

Switch to upstream images as default #65

Closed david-martin closed 5 years ago

david-martin commented 5 years ago

Implementation for #64. (downstream image https://issues.jboss.org/browse/INTLY-2596)

TODO:

To test, can use the auto built image with tag use-upstream-images-as-default

quay.io/integr8ly/application-monitoring-operator:use-upstream-images-as-default

These changes may supercede issues #52, #58, #59, #62.

david-martin commented 5 years ago

First test on OS4 looks good. Install works. OAuth Proxy works. Will proceed with changes to add crd flag next.

For anyone looking to try this out right now, you can apply the below change locally, the run make cluster/install

diff --git a/deploy/operator.yaml b/deploy/operator.yaml
index 6777658..cad2b78 100644
--- a/deploy/operator.yaml
+++ b/deploy/operator.yaml
@@ -15,7 +15,7 @@ spec:
       serviceAccountName: application-monitoring-operator
       containers:
         - name: application-monitoring-operator
-          image: quay.io/integreatly/application-monitoring-operator:0.0.17
+          image: quay.io/integreatly/application-monitoring-operator:use-upstream-images-as-default
           ports:
             - containerPort: 60000
               name: metrics
david-martin commented 5 years ago

@pb82 I'm questioning the original approach I was going to take for supporting the use of upstream and downstream (potentially protected) images. The approach was going to be a flag in the ApplicationMonitoring CRD to say to use public or protected images (defaulting to public). However, the idea of building in the list of protected images to this operator isn't sitting well with me. I think that is an anti-pattern compared to any downstream/productisation we may have done in the past.

A more upstream friendly approach might be to just have it use the public images, but have the list of images & tags maintained in a central location (i.e. templateHelper). Then for downstream use, we can modify the list in 1 file, and build the downstream image on RHEL from that modified source.

How does this sound?

I realise that initially this means we'll use upstream/public images for integr8ly until such a time as we do productised builds of this operator

david-martin commented 5 years ago

@pb82 rebased, if you could reapprove at your convience