Base64 decode and multi-line literals in yaml files

[betermieux]

The current shell templates create yaml files, which define multi-line strings using the literal block operator, i.e.:

key : |
  value

This seems to add a newline a the end of the value. On my box, base64 decode produces:

Error from server (BadRequest): error when creating "STDIN": Secret in version "v1" cannot be handled as a Secret: v1.Secret: ObjectMeta: v1.ObjectMeta: TypeMeta: Kind: Data: decode base64: illegal base64 data at input byte 108, parsing 158 ...CoiCg==\n"... at {"apiVersion":"v1","data":{"ceph.mon.keyring":"W21vbi5dDQogIGtleSA9IHRvcHNlY3JldA0KICBjYXBzIG1vbiA9ICJhbGxvdyAqIg==\n"},"kind":"Secret","metadata":{"name":"ceph-mon-keyring","namespace":"ceph"},"type":"Opaque"}

I have changed multi-line literals to single line literals where base64 data is used as values. This should be correct for base64 data, which is always a single line since tr -d '\n' is applied. After the changes ceph is deployed correctly.

[betermieux]

1. Well, in my case, the pod "ceph-mon-keyring-generator" fails, the above mentioned base64 decode error is the last line of the containers log. Which is strange, since the same container should produce the same error on all systems. BTW, the underlying node is an Ubuntu 16.04 LTS, Kubernetes is at 1.8.4.

2. I haven't traced all calls, but in all but one case, the string is piped through tr -d '\n', which should result in a single line. The remaining case uses the string $(kubectl get secret ${PVC_CEPH_STORAGECLASS_ADMIN_SECRET_NAME} --namespace=${PVC_CEPH_STORAGECLASS_DEPLOYED_NAMESPACE} -o json | jq -r '.data | .[]'), which should be a single line too, but I am not 100% sure.

You don't have to merge the PR, but I succesfully deployed a ceph cluster using my changes. Maybe it helps other users who hit this error.

[rootfs]

related: #41