Installer failed to create DNS records when using STS token

[brianredbeard]

Version

0.9.0

Platform (aws|libvirt|openstack):

AWS

What happened?

After performing an installation I am prompted to log into the OpenShift web console. After waiting 10 minutes, the corresponding DNS records for console-openshift-console.apps.... had not been created.

What you expected to happen?

Proper DNS records to be created for the relevant route resources.

How to reproduce it (as minimally and precisely as possible)?

NOTE: This installation was performed using an STS token. The installation was executed in a controlled environment requiring the use of audited privilege escalation by users.

1. Retrieve an STS token for your user.
2. Perform the install
3. Wait

Anything else we need to know?

Route resources were created correctly:

[bharrington@leviathan OPENSHIFT.RwRC]$ oc get routes --all-namespaces
NAMESPACE                  NAME                           HOST/PORT                                                                     PATH      SERVICES            PORT      TERMINATION          WILDCARD
openshift-console          console                        console-openshift-console.apps.west2.os4.rvu.io                                         console             https     reencrypt/Redirect   None
openshift-image-registry   image-registry-default-route   image-registry-default-route-openshift-image-registry.apps.west2.os4.rvu.io             image-registry      <all>     reencrypt            None
openshift-monitoring       alertmanager-main              alertmanager-main-openshift-monitoring.apps.west2.os4.rvu.io                            alertmanager-main   web       reencrypt/Redirect   None
openshift-monitoring       grafana                        grafana-openshift-monitoring.apps.west2.os4.rvu.io                                      grafana             https     reencrypt/Redirect   None
openshift-monitoring       prometheus-k8s                 prometheus-k8s-openshift-monitoring.apps.west2.os4.rvu.io                               prometheus-k8s      web       reencrypt/Redirect   None
openshift-osin             openshift-osin                 openshift-osin-openshift-osin.apps.west2.os4.rvu.io                                     openshift-osin      443       reencrypt/Redirect   None

Ingress operator pod is running:

[bharrington@leviathan OPENSHIFT.RwRC]$ oc --namespace=openshift-ingress-operator get pods 
NAME                                READY     STATUS    RESTARTS   AGE
ingress-operator-794cc7b555-rmlg8   1/1       Running   0          28m

Ingress operator shows 403 failures (likely due to a combination of token expiration and not minting any relevant credentials needed for it's own operation):

ingress-operator.log

References

Loosely related to:

• Minimal installer role policy definition required #111

[crawford]

This belongs to the ingress operator. The installer doesn't actually create these records. Would you mind moving the issue over there?

[abhinavdahiya]

This belongs to the ingress operator. The installer doesn't actually create these records. Would you mind moving the issue over there?

opened issue on https://github.com/openshift/cluster-ingress-operator regarding the invalid reporting of the clusteroperator status.

But I think expired creds is not a bug in ingress operator completely, it is partially as ingress operator assumes valid creds are being provided by installer. So I think we should keep this open here.

[abhinavdahiya]

@dgoodwin we need that baby creds-minter :P

[dgoodwin]

We're getting closer! https://github.com/openshift/cloud-credential-operator

@joelddiaz is working on code the installer could consume to pre-flight check if the creds given can (a) mint other creds, or failing that (b) power everything in the cluster.

[sdodson]

@dgoodwin this is done, right?

[joelddiaz]

@sdodson done as of #1156

[sdodson]

/close

[openshift-ci-robot]

@sdodson: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.