Red Hat Bugzilla – Bug 1516564
components don't end up with same versions as core
Last modified: 2018-10-11 03:19:41 EDT
howing all projects on server https://ip-172-18-8-175.ec2.internal:8443 https://docker-registry-default.router.default.svc.cluster.local (passthrough) (svc/docker-registry[default]) dc/docker-registry deploys registry.reg-aws.openshift.com/openshift3/ose-docker-registry:v3.7.9 deployment #1 deployed 41 minutes ago - 1 pod svc/kubernetes[default] - 172.30.0.1 ports 443->8443, 53->8053, 53->8053 https://registry-console-default.router.default.svc.cluster.local (passthrough) (svc/registry-console[default]) dc/registry-console deploys registry.reg-aws.openshift.com/openshift3/registry-console:v3.7 deployment #1 deployed 40 minutes ago - 1 pod svc/router[default] - 172.30.137.72 ports 80, 443, 1936 dc/router deploys registry.reg-aws.openshift.com/openshift3/ose-haproxy-router:v3.7.9 deployment #1 deployed 43 minutes ago - 1 pod https://apiserver-kube-service-catalog.router.default.svc.cluster.local (passthrough) to pod port secure (svc/apiserver[kube-service-catalog]) pod/apiserver-c2wd4 runs openshift3/ose-service-catalog:v3.7 svc/controller-manager[kube-service-catalog] - 172.30.90.172:6443 pod/controller-manager-zs64v runs openshift3/ose-service-catalog:v3.7 https://alerts-openshift-metrics.router.default.svc.cluster.local (reencrypt) (svc/alerts[openshift-metrics]) statefulset/prometheus manages openshift3/oauth-proxy:v3.7, openshift3/prometheus:v3.7, openshift3/oauth-proxy:v3.7, openshift3/prometheus-alert-buffer:v3.7, openshift3/prometheus-alertmanager:v3.7, created 38 minutes ago - 1 pod https://prometheus-openshift-metrics.router.default.svc.cluster.local (reencrypt) (svc/prometheus[openshift-metrics]) statefulset/prometheus manages openshift3/oauth-proxy:v3.7, openshift3/prometheus:v3.7, openshift3/oauth-proxy:v3.7, openshift3/prometheus-alert-buffer:v3.7, openshift3/prometheus-alertmanager:v3.7, created 38 minutes ago - 1 pod Router and Registry inherit the full NVR (3.7.9) but the rest of the components appear to only inherit the NV (3.7). While this works because of the way we tag things, this is not ideal.
Components that are built from oreg_url (default: openshift3/ose-${component}:${version}) get the version from the binary. Components "hosted" on top of OCP (logging, metrics, prometheus, registry-console, service catalog...) get the default in their template under openshift-ansible, unless you supply an override in your inventory. And every single one has a different override.
OpenShift addons are intended to move towards being less tightly coupled rather than more tightly coupled. When the router and registry move to be more aligned with how other components are installed we'll similarly make them install whatever the latest v${major}.${minor} version is as well. If an admin chooses to override this with a specific version we'll of course respect that.
The primary issue here, like with the other bug, is that the behaviors are unexpected/unpredictable and cause unexpected problems. For example, in a disconnected environment, this behavior would cause unexpected problems. If the intention is to make these components less tightly coupled, then we need even more explicit information, either in the examples or the documentation, about the levers, the intended behaviors, and the expected outcomes.
This looks like a duplicate of #1530183
*** This bug has been marked as a duplicate of bug 1530183 ***
I'd say instead that https://bugzilla.redhat.com/show_bug.cgi?id=1530183 is a single instance of the general problem outlined here. Perhaps we should point to the plan for addressing the general problem?
I agree that this bug most thoroughly summarizes the general issue and scope. Bug 1530183 won't address the router and registry but should for everything else that's template based.
This should be uniform with the exception of registry-console in 3.10. If openshift_image_tag is specified then that is used.
Whenever specifying openshift_image_tag you should get image tags as defined. If you only specify openshift_release you'll end up with v3.10 or v3.11, etc. Registry console is being addressed in https://bugzilla.redhat.com/show_bug.cgi?id=1613100
Verify this bug with openshift-ansible-3.11.0-0.11.0.git.0.3c66516None, and PASS. Trigger an install without openshift_image_tag setting, after installation, checking. # oc describe po apiserver-hmjbj -n kube-service-catalog|grep Image: Image: registry.reg-aws.openshift.com:443/openshift3/ose-service-catalog:v3.11 # oc describe po router-1-ckdnn|grep Image: Image: registry.reg-aws.openshift.com:443/openshift3/ose-haproxy-router:v3.11 # oc describe po docker-registry-1-rflt2|grep Image: Image: registry.reg-aws.openshift.com:443/openshift3/ose-docker-registry:v3.11 All the component is using v3.11 image tag.
When specify openshift_image_tag=v3.11.0-0.10.0.0 in inventory file, trigger an install on AH, all the components are using the specified image tag. [root@ip-172-18-9-130 ~]# oc describe po docker-registry-1-25tlt|grep Image: Image: registry.reg-aws.openshift.com:443/openshift3/ose-docker-registry:v3.11.0-0.10.0.0 [root@ip-172-18-9-130 ~]# oc describe po router-1-t4xxv|grep Image: Image: registry.reg-aws.openshift.com:443/openshift3/ose-haproxy-router:v3.11.0-0.10.0.0
Follow comment 11, continue... [root@ip-172-18-9-130 ~]# oc describe po webconsole-64f88cc59d-z7rrq -n openshift-web-console|grep Image: Image: registry.reg-aws.openshift.com:443/openshift3/ose-web-console:v3.11.0-0.10.0.0 [root@ip-172-18-9-130 ~]# oc describe po apiserver-66mwm -n kube-service-catalog|grep Image: Image: registry.reg-aws.openshift.com:443/openshift3/ose-service-catalog:v3.11.0-0.10.0.0 [root@ip-172-18-9-130 ~]# oc describe po asb-1-thngp -n openshift-ansible-service-broker|grep Image: Image: registry.reg-aws.openshift.com:443/openshift3/ose-ansible-service-broker:v3.11.0-0.10.0.0 So move this bug to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2652