Bug 1516564 - components don't end up with same versions as core
Summary: components don't end up with same versions as core
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Installer
Version: 3.7.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.11.0
Assignee: Russell Teague
QA Contact: Johnny Liu
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-22 23:01 UTC by Erik M Jacobs
Modified: 2018-10-11 07:19 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
All component image definitions have been updated to use a standard pattern based on provided inventory variables. This provides a consistent image source and version for each component.
Clone Of:
Last Closed: 2018-10-11 07:19:06 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:2652 None None None 2018-10-11 07:19:41 UTC
Red Hat Bugzilla 1518806 None None None Never

Internal Links: 1518806

Description Erik M Jacobs 2017-11-22 23:01:21 UTC
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] - 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] - 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] -
  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.

Comment 1 Luke Meyer 2017-11-22 23:55:54 UTC
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.

Comment 2 Scott Dodson 2017-11-27 14:33:07 UTC
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.

Comment 3 Erik M Jacobs 2017-11-27 16:05:43 UTC
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.

Comment 4 Vadim Rutkovsky 2018-01-17 13:56:10 UTC
This looks like a duplicate of #1530183

Comment 5 Scott Dodson 2018-01-17 14:45:20 UTC

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

Comment 6 Luke Meyer 2018-01-18 15:08:04 UTC
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?

Comment 7 Scott Dodson 2018-01-18 20:50:00 UTC
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.

Comment 8 Scott Dodson 2018-08-02 13:58:43 UTC
This should be uniform with the exception of registry-console in 3.10. If openshift_image_tag is specified then that is used.

Comment 9 Scott Dodson 2018-08-09 13:32:53 UTC
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 

Comment 10 Johnny Liu 2018-08-09 16:06:57 UTC
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.

Comment 11 Johnny Liu 2018-08-10 07:17:54 UTC
When specify openshift_image_tag=v3.11.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-
[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-

Comment 12 Johnny Liu 2018-08-10 07:19:22 UTC
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-
[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-
[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-

So move this bug to VERIFIED.

Comment 14 errata-xmlrpc 2018-10-11 07:19:06 UTC
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.


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