Bug 1302956

Summary: LivenessProbe Fails for Secured Integrated Registry
Product: OpenShift Container Platform Reporter: Andrew Block <andrew.block>
Component: Image RegistryAssignee: Michail Kargakis <mkargaki>
Status: CLOSED CURRENTRELEASE QA Contact: Wei Sun <wsun>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.1.0CC: aos-bugs, jlee, jliggitt, jokerman, mmccomas, whearn
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-06-13 18:46:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andrew Block 2016-01-29 06:42:32 UTC
Description of problem:
A liveness probe was reintroduced in OpenShift Enterprise 3.1.1 for the integrated registry. The default scheme for the probe is HTTP. When a secured registry is configured, the probe fails causing the running pod to be killed and is repeatedly killed

Version-Release number of selected component (if applicable): 
Atomic OpenShift Enterprise 3.1.1


How reproducible:
Always when the registry is secured

Steps to Reproduce:
1. Follow instructions on how to secure the registry (https://docs.openshift.com/enterprise/3.1/install_config/install/docker_registry.html#securing-the-registry)

oadm ca create-server-cert --signer-cert=/etc/origin/master/ca.crt --signer-key=/etc/origin/master/ca.key --signer-serial=/etc/origin/master/ca.serial.txt --hostnames="docker-registry.default.svc.cluster.local,172.30.243.0"--cert=/etc/origin/master/registry.crt --key=/etc/origin/master/registry.key

oc secrets new registry-secret /etc/origin/master/registry.crt /etc/origin/master/registry.key

oc secrets add serviceaccounts/default secrets/registry-secret

oc volume dc/docker-registry --add --type=secret --secret-name=registry-secret -m /etc/secrets
	
oc env dc/docker-registry REGISTRY_HTTP_TLS_CERTIFICATE=/etc/secrets/registry.crt  REGISTRY_HTTP_TLS_KEY=/etc/secrets/registry.key


Actual results:

Monitor pods:

oc get pods -w

Pod containing registry terminates repeatedly


Expected results:
The registry deploys and runs successfully without downtime

Additional info:
The following command can be used to correct the issue where the deployment config name is docker-registry

oc get dc docker-registry -o yaml | sed -e 's/scheme: HTTP/scheme: HTTPS/g' | oc replace -f -

Comment 1 Michail Kargakis 2016-01-29 13:49:55 UTC
Reproduced. This feels more of a doc bug rather than a bug in the code. It's the responsibility of the user to update the probes alongside the envs in the DC. The only thing that concerns me is that the update should happen in one step (update both probes + envs) and not two (update envs, update probes) which makes `oc env` useless here. I am thinking that this should probably be a job for oadm registry.

Comment 2 Jordan Liggitt 2016-01-29 17:33:37 UTC
*** Bug 1303118 has been marked as a duplicate of this bug. ***

Comment 3 Jordan Liggitt 2016-01-29 17:34:25 UTC
It's either a doc bug or part of the CLI (though the CLI doesn't let you create a secured registry today)

Comment 4 Jordan Liggitt 2016-01-29 17:35:05 UTC
Details for docs added in https://github.com/openshift/openshift-docs/issues/1500

Comment 6 openshift-github-bot 2016-02-01 14:01:34 UTC
Commits pushed to master at https://github.com/openshift/openshift-docs

https://github.com/openshift/openshift-docs/commit/4b7e8754e6ee9a4d6368a96ef0d05c26e176314d
Bug 1302956: update scheme in probes when securing a registry

https://github.com/openshift/openshift-docs/commit/110c966bfb32e45c7a7d86c07a55820195a2a78a
Merge pull request #1510 from kargakis/bug-1302956

Bug 1302956: update scheme in probes when securing a registry

Comment 7 Wei Sun 2016-02-02 06:38:27 UTC
Following the doc ,the bug was fixed.

# openshift version
openshift v3.1.1.6
kubernetes v1.1.0-origin-1107-g4c8e6f4
etcd 2.1.2

Comment 8 Scott Dodson 2016-02-04 18:23:29 UTC
*** Bug 1304101 has been marked as a duplicate of this bug. ***

Comment 9 Scott Dodson 2016-06-13 18:46:05 UTC
Was fixed in 3.1.1.6