Bug 1289762

Summary:	/etc/kubernetes/config has typo for privileged containers option
Product:	Red Hat Enterprise Linux 7	Reporter:	Micah Abbott <miabbott>
Component:	kubernetes	Assignee:	Jan Chaloupka <jchaloup>
Status:	CLOSED ERRATA	QA Contact:	atomic-bugs <atomic-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	boeroboy, gouyang
Target Milestone:	rc	Keywords:	Extras
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	kubernetes-1.2.0-0.2.alpha1.git8632732.el7_2	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-02-16 16:30:26 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 Micah Abbott 2015-12-08 22:04:49 UTC

Description of problem:
The '/etc/kubernetes/config' file has a typo in the 'KUBE_ALLOW_PRIV' option; it lists '--allow_privileged' as the option to the 'kubelet', but the correct option is '--allow-privileged'.  Note: dash vs underscore

Version-Release number of selected component (if applicable):

kubernetes-master-1.0.3-0.2.gitb9a88a7.el7.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Install kubernetes-master
2. Inspect /etc/kubernetes/config
3.

Actual results:

Option listed is '--allow_privileged'

Expected results:

Option should be '--allow-privileged'

Additional info:

See upstream docs:  http://kubernetes.io/v1.1/docs/admin/kubelet.html



-bash-4.2# rpm -q kubernetes-master
kubernetes-master-1.0.3-0.2.gitb9a88a7.el7.x86_64
-bash-4.2# rpm -ql kubernetes-master 
/etc/kubernetes
/etc/kubernetes/apiserver
/etc/kubernetes/config
/etc/kubernetes/controller-manager
/etc/kubernetes/scheduler
/usr/bin/kube-apiserver
/usr/bin/kube-controller-manager
/usr/bin/kube-scheduler
/usr/bin/kube-version-change
/usr/lib/systemd/system/kube-apiserver.service
/usr/lib/systemd/system/kube-controller-manager.service
/usr/lib/systemd/system/kube-scheduler.service
/usr/lib/tmpfiles.d/kubernetes.conf
/usr/share/doc/kubernetes-master-1.0.3
/usr/share/doc/kubernetes-master-1.0.3/CONTRIB.md
/usr/share/doc/kubernetes-master-1.0.3/CONTRIBUTING.md
/usr/share/doc/kubernetes-master-1.0.3/DESIGN.md
/usr/share/doc/kubernetes-master-1.0.3/LICENSE
/usr/share/doc/kubernetes-master-1.0.3/README.md
/usr/share/man/man1/kube-apiserver.1.gz
/usr/share/man/man1/kube-controller-manager.1.gz
/usr/share/man/man1/kube-scheduler.1.gz
-bash-4.2# cat /etc/kubernetes/config 
###
# kubernetes system config
#
# The following values are used to configure various aspects of all
# kubernetes services, including
#
#   kube-apiserver.service
#   kube-controller-manager.service
#   kube-scheduler.service
#   kubelet.service
#   kube-proxy.service
# logging to stderr means we get it in the systemd journal
KUBE_LOGTOSTDERR="--logtostderr=true"

# journal message level, 0 is debug
KUBE_LOG_LEVEL="--v=0"

# Should this cluster be allowed to run privileged docker containers
KUBE_ALLOW_PRIV="--allow_privileged=false"

# How the controller-manager, scheduler, and proxy find the apiserver
KUBE_MASTER="--master=http://127.0.0.1:8080"

Comment 5 errata-xmlrpc 2016-02-16 16:30:26 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://rhn.redhat.com/errata/RHBA-2016-0184.html

Comment 6 John Boero 2016-03-04 14:57:21 UTC

Hi I just ran into this in Fedora 23 as well.  Suddenly pulled the updates that fixed it and left me confused.  Note that the man pages are still ambiguous, with references to both --api_servers and --api-servers etc.  Very confusing for users and no helpful output when mistaken.  Should another bug be filed for documentation?  .rpmnew config files leave me scratching my head with a partially functional cluster.

Thanks!
JohnnyB

Comment 7 Jan Chaloupka 2016-03-04 15:06:08 UTC

Hi John,

atm both form of flags with dashes/underscores are supported. Flags with underscore are deprecated although still supported for backward compatibility.

If there are both forms supported, prefer flags with dashes.

If there is a flag that should be supported and is not, please report a bug.

Jan