Skip to content
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 does not deploy console #752

mareklibra opened this issue Feb 12, 2018 · 5 comments
Closed does not deploy console #752

mareklibra opened this issue Feb 12, 2018 · 5 comments


Copy link

@mareklibra mareklibra commented Feb 12, 2018

This form is for bug reports and feature requests. Major features will go through a spec process.


OpenShift >3.7.1 deployment using ./


For :latest openshift, the ./ skips deployment of the Web Console.

Most probably related to: openshift/origin#18207

For lower version (v3.7.1), the script works fine:


What happened:
WebConsole can not be accessed, url https://[MY_CLUSTER]:8443/console leads to:

missing service (service "webconsole" not found)
missing route (service "webconsole" not found)

What you expected to happen:
Web console is deployed and can be accessed

How to reproduce it:

  • ./
  • access https://[MY_CLUSTER]:8443/console
Copy link

@dymurray dymurray commented Feb 12, 2018

@marekjelen do you mind telling me what version of oc you are using? oc version. It might be using a different version of the binary than 3.7.1.

Copy link

@dymurray dymurray commented Feb 12, 2018

I had success using 3.9 binaries as shown below:

[dymurray@dymurray scripts]$ oc version
oc v3.9.0-alpha.4+0d9f796-159
kubernetes v1.9.1+a0ce1bc657
features: Basic-Auth GSSAPI Kerberos SPNEGO

openshift v3.9.0-alpha.4+76c1143-274
kubernetes v1.9.1+a0ce1bc657
[dymurray@dymurray scripts]$ ./ 
Starting OpenShift using ...
Pulling image
Pulled 2/4 layers, 51% complete
Pulled 3/4 layers, 76% complete
Pulled 4/4 layers, 100% complete
Image pull complete
OpenShift server started.

The server is accessible via web console at:

You are logged in as:
    User:     developer
    Password: <any value>

To login as administrator:
    oc login -u system:admin

Logged into "" as "system:admin" using existing credentials.

You have access to the following projects and can switch between them with 'oc project <projectname>':

  * myproject

Using project "myproject".
Now using project "ansible-service-broker" on server "".

You can add applications to this project with the 'new-app' command. For example, try:

    oc new-app centos/ruby-22-centos7~

to build a new example application in Ruby.
Generating a 4096 bit RSA private key
writing new private key to '/tmp/etcd-cert/key.pem'
Generating RSA private key, 2048 bit long modulus
e is 65537 (0x10001)
Signature ok
Getting CA Private Key
service "asb" created
service "asb-etcd" created
serviceaccount "asb" created
clusterrolebinding "asb" created
clusterrole "asb-auth" created
clusterrolebinding "asb-auth-bind" created
clusterrole "access-asb-role" created
persistentvolumeclaim "etcd" created
deploymentconfig "asb" created
deploymentconfig "asb-etcd" created
secret "asb-auth-secret" created
secret "registry-auth-secret" created
secret "etcd-auth-secret" created
secret "broker-etcd-auth-secret" created
configmap "broker-config" created
serviceaccount "ansibleservicebroker-client" created
clusterrolebinding "ansibleservicebroker-client" created
secret "ansibleservicebroker-client" created
route "asb-1338" created
clusterservicebroker "ansible-service-broker" created

Copy link

@eriknelson eriknelson commented Feb 12, 2018

The root issue here is the oc binary in the path and has nothing to do with our script. I don't think this is a bug that should be aligned against the broker project, but I'm open to dissenting opinion.

Copy link

@eriknelson eriknelson commented Feb 12, 2018

@mareklibra Can you try with a recent oc binary?

Copy link

@mareklibra mareklibra commented Feb 13, 2018

Indeed, the root issue is in "old" version of oc which is in fact the latest officially released. Taking the one from 3.9 alpha 3 helps.

I think the script should either:

  • pull images conforming the oc version on path
  • or download corresponding oc for its run
  • or at least check&warn for incompatibility so ORIGIN_VERSION shall be explicitly set

Since the script downloads :latest images, requirement to have "latest" oc version is not obviously valid. The proper version here is the one, which was not yet released.

IMO, this issue will repeat for ongoing versions as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants