run_latest_build.sh does not deploy console

[mareklibra]

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

Feature:

OpenShift >3.7.1 deployment using ./run_latest_build.sh

Bug:

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

Most probably related to: openshift/origin#18207

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

ORIGIN_VERSION=v3.7.1 ./run_latest_build.sh

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:

• ./run_latest_build.sh
• access https://[MY_CLUSTER]:8443/console

[dymurray]

@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.

[dymurray]

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

Server https://127.0.0.1:8443
openshift v3.9.0-alpha.4+76c1143-274
kubernetes v1.9.1+a0ce1bc657

[dymurray@dymurray scripts]$ ./run_latest_build.sh 
Starting OpenShift using docker.io/openshift/origin:latest ...
Pulling image docker.io/openshift/origin:latest
Pulled 2/4 layers, 51% complete
Pulled 3/4 layers, 76% complete
Pulled 4/4 layers, 100% complete
Extracting
Image pull complete
OpenShift server started.

The server is accessible via web console at:
    https://172.17.0.1.nip.io:8443

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

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

Logged into "https://127.0.0.1:8443" as "system:admin" using existing credentials.

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

    default
    kube-public
    kube-service-catalog
    kube-system
  * myproject
    openshift
    openshift-infra
    openshift-node
    openshift-template-service-broker
    openshift-web-console

Using project "myproject".
Now using project "ansible-service-broker" on server "https://127.0.0.1:8443".

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

    oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-ex.git

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
subject=/CN=client
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

[eriknelson]

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.

[eriknelson]

@mareklibra Can you try with a recent oc binary?

[mareklibra]

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.