Bug 1278832 - [Docs] [Containers] Add documentation so that a sysadmin knows how to proceed to add Kubernetes/OpenShift/Atomic
[Docs] [Containers] Add documentation so that a sysadmin knows how to proceed...
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Documentation (Show other bugs)
Unspecified Unspecified
high Severity medium
: GA
: 5.5.0
Assigned To: Petr Kovar
Depends On:
  Show dependency treegraph
Reported: 2015-11-06 09:05 EST by Marianne Feifer
Modified: 2016-01-07 18:56 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-01-07 18:56:24 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Marianne Feifer 2015-11-06 09:05:38 EST
Description of problem:

From Federico Simoncelli:

Hi, I'd like to document the ManageIQ service account creation, more or less:


in a more official page, and then add a link in the ManageIQ
containers provider page to that documentation so that a sysadmin
knows how to proceed to add Kubernetes/OpenShift/Atomic.

Do you have a suggestion on where I can put that documentation?

Also, remember that it will also reach downstream and since we want to
limit the differences (upstream vs downstream) it would be great if
the documentation page would be the same one.

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

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:  See the talk article referenced above. Would be good to have KB as well as in Guides.

Document URL: 

Section Number and Name: 

Describe the issue: 

Suggestions for improvement: 

Additional information:
Comment 2 Federico Simoncelli 2015-11-06 10:17:46 EST
My latest notes for ManageIQ service account creation are:

 $  oc create -n default -f - <<EOF
apiVersion: v1
kind: ServiceAccount
  name: manageiq

 $ oadm policy add-cluster-role-to-user cluster-reader system:serviceaccount:default:manageiq
 $ oadm policy add-scc-to-user privileged system:serviceaccount:default:manageiq

To fetch the token then we currently have:

 $ oc get secrets `oc describe serviceaccount manageiq | awk '/Tokens:/ { print $2 }'` --template '{{.data.token}}' | base64 -d

which is a little shaky as the line with "Tokens:" may get a secret that is not a token.

David, Clayton do you have something nicer for this?

Maybe we can bake something out of this starting point:

 $ oc get serviceaccount -n default manageiq --template '{{range .secrets}}{{.name}} {{end}}'
Comment 3 David Eads 2015-11-06 10:32:17 EST
I would try something like: 

oc get sa/builder --template='{{range .secrets}}{{ .name }} {{end}}' | xargs -n 1 oc get secret --template='{{ if .data.token }}{{ .data.token }}{{end}}' | base64 -d -

gets the service account, iterates over the secret names, checks them one by one to see if they have a token key in the map, does a decode.

You can add an echo and a head to get just one.
Comment 4 David Eads 2015-11-06 10:34:16 EST
Here's one with the head.

oc get sa/default --template='{{range .secrets}}{{ .name }} {{end}}' | xargs -n 1 oc get secret --template='{{ if .data.token }}{{ .data.token }}{{ printf "\n" }}{{end}}' | head -n 1 | base64 -d -
Comment 5 Andrew Dahms 2015-11-10 01:32:40 EST
Assigning to Petr for review.
Comment 8 Andrew Dahms 2016-01-07 18:56:24 EST
This content is now live on the Customer Portal.


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