-
Notifications
You must be signed in to change notification settings - Fork 2.3k
TASK [template_service_broker : Reconcile with RBAC file] fails #6086
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
In those passing jobs (until 2017-11-07) I see
which might be the reason why we did not see the failure earlier. |
I have got
and But that origin-clients-3.6.1 was installed by the ansible playbook, so it should know it has installed old version ... |
I have this issue as well...any thoughts on how I can get past this? :) |
I haven't tested/verified this yet but this commit seems to have introduced the breakage: |
@tomassedovic, I don't think that's the one. Semantially, it's still That commit is part of some bigger branch which AFAICT causes |
* Fix the openshift-ansible CI breakage A change in openshift-ansible has broken our CI (and deployments): https://travis-ci.org/openshift/openshift-ansible-contrib/jobs/301329799 ``` TASK [template_service_broker : Reconcile with RBAC file] ********************** Monday 13 November 2017 11:16:35 +0000 (0:00:00.818) 0:15:06.296 ******* fatal: [master-0.openshift-1829.example.com]: FAILED! => {"changed": true, "cmd": "oc process -f \"/tmp/tsb-ansible-C1kuTw/rbac-template.yaml\" | oc auth reconcile -f -", "delta": "0:00:00.355587", "end": "2017-11-13 11:16:36.444135", "failed": true, "rc": 1, "start": "2017-11-13 11:16:36.088548", "stderr": "Error: unknown shorthand flag: 'f' in -f\n\n\nUsage:\n oc auth [options]\n\nAvailable Commands:\n can-i Check whether an action is allowed\n\nUse \"oc <command> --help\" for more information about a given command.\nUse \"oc options\" for a list of global command-line options (applies to all commands).", "stderr_lines": ["Error: unknown shorthand flag: 'f' in -f", "", "", "Usage:", " oc auth [options]", "", "Available Commands:", " can-i Check whether an action is allowed", "", "Use \"oc <command> --help\" for more information about a given command.", "Use \"oc options\" for a list of global command-line options (applies to all commands)."], "stdout": "", "stdout_lines": []} ``` The openshift-ansible issue tracking this: openshift/openshift-ansible#6086 The issue appears to be caused by the ad977b701124f5e134e8c2a0cbc6e907ce177366 commit. And it's not present in the previous commit, i.e.: 56b529e493a5f55ecfc75bc20a807a3d73e03507 Fix examples image streams tag: openshift-ansible-3.7.2-1-8-g56b529e So we switch the CI to use that until the upstream issue is resolved. * Remove an empty line
i can confirm the problem, i have this problem too |
I can also confirm this issue, just cloned the master branch and got this failure. Fedora 27.1 Atomic Host |
@simo5, we seem to be hitting |
Why does the release-3.7 branch even start by deploying 3.6 and then eventually upgrading to 3.7? It would seem better to start with 3.7. |
We do both. The vast majority of clusters will be upgraded from the last release, so just doing a fresh install of the newest code simply doesn't give us the signal we need. |
Thanks, @stevekuznetsov Is there an option I can set that would start a new cluster on 3.7? That might avoid the error discussed in this issue for some of us. |
I would not expect a brand new install to require a reconciliation. /cc @sdodson |
It might help if I explain that I was using openshift-ansible indirectly as part of https://github.com/dwmkerr/terraform-aws-openshift which first uses Terraform to provision some AWS resources and then uses openshift-ansible. The key interaction with openshift-ansible is in the install-from-bastion.sh script which invokes |
Do you have the ability to specify any openshift-ansible variables? Setting |
I could probably do that. But isn't the release-3.7 branch of openshift-ansible pointing to some version of 3.7? even if rc? My impression from the openshift-ansible README.md had been that using branch release-3.7 would use OpenShift 3.7 and therefore Kubernetes 1.7.x. I'm not doing any of this for production. Just for being able to do a demo on OpenShift that uses HashiCorp's Terraform to provision the infrastructure and Vault to secure secrets. (I work at HashiCorp as an SE.) Using 3.7 would have been better for me since Kubernetes 1.7 defaults to using --service-account-lookup on the API Server. But I was able to enable that with OpenShift 3.6 in this setup today. So, using 3.7 is no longer so pressing. I do appreciate the suggestions and help. |
Same issue here on 6b6b422. |
I confirm that using
on my RHEL 7.4. Is it expected that master branch no longer supports 3.6 and that |
see: openshift/openshift-ansible#6086 Signed-off-by: Sébastien Han <[email protected]>
@adelton thanks, this is fixing my deployment too. |
@adelton The CI tests build origin from source on every pull request. |
Ah, so they do not use the repos? Wouldn't it be nice, for the openshift-ansible repo PR/CI tests, to (also) check that it works with the existing Origin repo bits? After all, that's what users will see and use. |
I just tested with git clone -b release-3.7 https://github.com/rberlind/openshift-ansible and openshift_repos_enable_testing=true in my inventory template cfg file. I did not get the "Reconcile with RBAC file" error that I had previously seen and which this ticket originally reported. However, the next task "Verify that TSB is running" failed after 120 attempts. The specific error was: (7) Failed connect to apiserver.openshift-template-service-broker.svc:443; Connection refused" It seems to me there are 2 problems here:
If I add the DNS to /etc/hosts on master, I can do following: But maybe that is hitting something other than the template-service-broker after I Note that Also, when I run Dec 01 13:05:22 ip-10-0-1-219.ec2.internal atomic-openshift-master-api[11848]: I1201 13:05:22.293422 11848 rbac.go:116] RBAC DENY: user "system:serviceaccount:openshift-template-service-broker:apiserver" groups ["system:serviceaccounts" "system:serviceaccoun ... Any ideas? |
One other possibility here is that my inventory.cfg file does not have openshift_template_service_broker_namespaces set. https://docs.openshift.org/latest/install_config/install/advanced_install.html#configuring-template-service-broker suggests that it must be set: "To configure the TSB, one or more projects must be defined as the broker’s source namespace(s) for loading templates and image streams into the service catalog. Set the desired projects by modifying the following in your inventory file’s [OSEv3:vars] section: |
That did not help, but I was able to install OpenShift Origin 3.7 by disabling the service catalog and TSB with: openshift_enable_service_catalog=false |
Unfortunately, on Fedora 27, the
installed and I still get the same |
@adelton koji only seems to have origin-3.6.0 for F27 so that would explain why you are getting 3.6.0. See https://koji.fedoraproject.org/koji/packageinfo?packageID=21564 |
Anyone managed to get this working? We just started evaluating OpenShift and this is totally breaking our experience. We thought we were doing something wrong at first :( |
As I mentioned, I was able to get OpenShift 3.7 installed and running, but I had to set the following flags to disable the service catalog and template service openshift_enable_service_catalog=false In that sense, I did not get OpenShift 3.7 fully deployed. |
|
It appears CentOS has not pusblished a 3.7.0 RPM for openshift yet, even in the testing repo (I only see alpha and rc0). We will have to investigate the work-around with the older client as @adelton noted, we want 3.6 to be deployable on 3.7. @WoLfulus in the mean time, if you a just trying to test out openshift and openshift-ansible, 3.6 is already available, I recommend starting with that branch for now until 3.7 RPMs are published. |
@michaelgugino there is openshift-clients listed in https://buildlogs.centos.org/centos/7/paas/x86_64/openshift-origin/ |
@bogdando When I view that page, I only see an alpha and rc release for that package. The package version derived from the release, I'm not sure it will pick up alpha and rc packages by default. |
@michaelgugino with centos 7.4 (and /update: Yeah, e2e worked for me |
@deads2k Can you pinpoint which release would resolve this error? It seems that
The task that it's running is the following
|
vendor/k8s.io/kubernetes/pkg/kubectl/cmd/auth/reconcile.go is new in OpenShift 3.7. |
I try to install the OpenShift 3.6 too and i have this issue as well, can anybody help to solve this issue? |
@tracestats use the release-3.6 branch. We recommend using the release branch that corresponds to the release of openshift you desire to deploy. |
@michaelgugino thank you! It works :) |
Using branch release-3.6 to deploy oo36 worked. Thanks for the tip! |
I also faced same issue around service catalog. I disabled below parameters as mentioned by @rberlind in host inventory file: openshift_enable_service_catalog=false And the deployment of OpenShift Origin 3.7 was successful: INSTALLER STATUS ******************************************************************************************************************************************************* My question: Is service catalog a mandatory feature for OpenShift environment? |
I no longer test 3.7 installs with |
* Fix the openshift-ansible CI breakage A change in openshift-ansible has broken our CI (and deployments): https://travis-ci.org/openshift/openshift-ansible-contrib/jobs/301329799 ``` TASK [template_service_broker : Reconcile with RBAC file] ********************** Monday 13 November 2017 11:16:35 +0000 (0:00:00.818) 0:15:06.296 ******* fatal: [master-0.openshift-1829.example.com]: FAILED! => {"changed": true, "cmd": "oc process -f \"/tmp/tsb-ansible-C1kuTw/rbac-template.yaml\" | oc auth reconcile -f -", "delta": "0:00:00.355587", "end": "2017-11-13 11:16:36.444135", "failed": true, "rc": 1, "start": "2017-11-13 11:16:36.088548", "stderr": "Error: unknown shorthand flag: 'f' in -f\n\n\nUsage:\n oc auth [options]\n\nAvailable Commands:\n can-i Check whether an action is allowed\n\nUse \"oc <command> --help\" for more information about a given command.\nUse \"oc options\" for a list of global command-line options (applies to all commands).", "stderr_lines": ["Error: unknown shorthand flag: 'f' in -f", "", "", "Usage:", " oc auth [options]", "", "Available Commands:", " can-i Check whether an action is allowed", "", "Use \"oc <command> --help\" for more information about a given command.", "Use \"oc options\" for a list of global command-line options (applies to all commands)."], "stdout": "", "stdout_lines": []} ``` The openshift-ansible issue tracking this: openshift/openshift-ansible#6086 The issue appears to be caused by the ad977b701124f5e134e8c2a0cbc6e907ce177366 commit. And it's not present in the previous commit, i.e.: 56b529e493a5f55ecfc75bc20a807a3d73e03507 Fix examples image streams tag: openshift-ansible-3.7.2-1-8-g56b529e So we switch the CI to use that until the upstream issue is resolved. * Remove an empty line
Uh oh!
There was an error while loading. Please reload this page.
Description
Provide a brief description of your issue here.
On a RHEL 7.4 machine, running
fails.
Version
Please put the following version information in the code block
indicated below.
ansible --version
If you're operating from a git clone:
git describe
If you're running from playbooks installed via RPM or
atomic-openshift-utils
rpm -q atomic-openshift-utils openshift-ansible
Place the output between the code block below:
N/A
Steps To Reproduce
Expected Results
Describe what you expected to happen.
No error, ansible-playbook passing and all-on-one OpenShift setup created.
Observed Results
Describe what is actually happening.
For long output or logs, consider using a gist
Additional Information
Provide any additional information which may help us diagnose the
issue.
$ cat /etc/redhat-release
)The failure started to show up on 2017-11-09 morning and is determinstic. Previous runs up until 2017-11-07 evening were passing.
The text was updated successfully, but these errors were encountered: