Installer does not properly quote strings in YAML files

[brianredbeard]

Version

$ openshift-install version
0.9.1

Platform (aws|libvirt|openstack):

AWS

What happened?

When rendering the various YAML files, the installer fails to quote the values which are strings. As such this leads to ambiguity in parsing of the files.

As an example, when performing an install with a random hexadecimal cluster name beginning with an integer the installer fails to quote the string. e.g.:

clusters:
- cluster:
    server: https://716064e0-api.os4.rvu.io:6443
  name: 716064e0
contexts:
- context:
    cluster: 716064e0
    user: admin
  name: admin
current-context: admin
preferences: {}

As a result, Kubernetes (for example) will fail to read the file with the following error:

[bharrington@leviathan OPENSHIFT.RwRC]$ oc --namespace=openshift-ingress-operator get pods 
error: Error loading config file "/home/bharrington/Downloads/OPENSHIFT.RwRC/auth/kubeconfig": [pos 1602]: json: expect char '"' but got char '7'

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

1. Create a cluster

For bonus points:
1b. Create a cluster with a numeric cluster name.

[crawford]

Do you mind sharing the contents of your kubeconfig?

Nevermind. I didn't recognize that snippet you posted.

[crawford]

According to the spec, 716064e0 is in fact a valid floating point number. Unfortunately, oc/kubectl uses a generic transformation between YAML and JSON, which doesn't know that that field should be a string.

[brianredbeard]

Along those lines though, the installer should know that the value supplied for metadata -> name is always a string (by virtue of the fact that the installer expects to use the value to generate DNS entries).

[crawford]

And the installer does know that. The issue is that the YAML library (as @squeed discovered) we are using doesn't follow the spec. The fix belongs upstream.

@squeed are you still working on that fix or should we take it over?

[crawford]

Upstream PR: go-yaml/yaml#428.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci-robot]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

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