Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1447249

Summary:	'oadm registry --fs-group=xx' command result in pods deployment pending if don't add "- system:serviceaccount:default:deployer" to scc/hostnetwork->users
Product:	OpenShift Container Platform	Reporter:	ge liu <geliu>
Component:	Image Registry	Assignee:	Oleg Bulatov <obulatov>
Status:	CLOSED ERRATA	QA Contact:	ge liu <geliu>
Severity:	low	Docs Contact:
Priority:	low
Version:	3.6.0	CC:	aos-bugs, bparees, dyan, geliu, mfojtik
Target Milestone:	---
Target Release:	3.6.z
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	No Doc Update
Doc Text:	This bug is about documentation itself.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-06-07 08:40:35 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 ge liu 2017-05-02 08:36:33 UTC

OCP / image registry
M/M

openshift v3.6.49
kubernetes v1.5.2+43a9be4
etcd 3.1.0

Description of problem:
create registry to set fs-group options with command 'oadm registry --fs-group=xx', the registry pods deployment will pending in Running.. status for long time and become error at last, after investigating with dev, the root cause is: add "- system:serviceaccount:default:deployer" to scc/hostnetwork->users, then the problem disappears, so we need improvement on scc documents about this issue, thanks

How reproducible:
Always

Steps to Reproduce:
1. create registry to special fs-group id by command line: 'oadm registry --fs-group=xx' 
2. registry pods deployment will pending in Running.. status for long time and become error at last
3. add "- system:serviceaccount:default:deployer" to scc/hostnetwork->users
4. rerun  command line: 'oadm registry --fs-group=xx', the problem disappears

Actual results:
there is not doc about this tips for customer to set fs-group options 
Expected results:
there is doc about this tips for customer to set fs-group options

Comment 1 Ben Parees 2018-03-05 19:16:45 UTC

Oleg another one, probably just some doc updates to: https://docs.openshift.org/latest/install_config/registry/deploy_registry_existing_clusters.html

though i'm a little confused as to why setting an fsgroup would require "scc/hostnetwork", so it's probably worth validating this behavior and talking to the storage/security folks.

Comment 2 Oleg Bulatov 2018-03-06 14:58:51 UTC

The integrated registry runs in the default namespace and have restrictions from SCC.

By default the registry gets the restricted SCC, and it restricts fsgroups based on the namespace annotation:

    $ oc get ns default -o go-template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
    1000000000/10000

So, if you want to use --fs-group, you should select the ID from the range: 1000000000 <= id < 1000000000+10000. For example:

    oc adm registry --fs-group=1000000000

But you should be aware that on different clusters you may have different ranges in annotations. So a value that works on a cluster may not work on another cluster.

ge liu, can you confirm that selecting proper value helps?

Comment 3 ge liu 2018-03-07 08:42:51 UTC

 Oleg Bulatov, I remembered that I used 1000020000 or 1000030000, and it seems that there is not notification in doc about this limitation, right?

Comment 4 Oleg Bulatov 2018-03-07 10:05:26 UTC

https://docs.openshift.com/enterprise/3.1/install_config/persistent_storage/pod_security_context.html#sccs-defaults-allowed-ranges

Comment 5 Oleg Bulatov 2018-04-19 13:37:48 UTC

https://github.com/openshift/openshift-docs/pull/8804

Comment 8 errata-xmlrpc 2018-06-07 08:40:35 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.

https://access.redhat.com/errata/RHBA-2018:1801