model: Use SingleLineString for all appropriate Strings

[tjkirch]

Don't want anyone inserting extra lines into our config files.

The String types that were not changed:

• retry_commands because it's conceivable to want a multi-line command; these are read-only so not relevant to API calls right now.
• The keys of Services and ConfigurationFiles maps, because they're handled dynamically in code and would require other changes I haven't figured out yet; these are read-only so not relevant to API calls right now.

Testing done:

Requests with newlines are now rejected in all these places; good requests are still OK.

bash-5.0# apiclient -u /settings -m PATCH -d '{"hostname": "hi\nthere"}'
Json deserialize error: Can't create SingleLineString with line terminator '2' at line 1 column 25

bash-5.0# apiclient -u /settings -m PATCH -d '{"hostname": "hi there"}' -v
204 No Content

All our templated files still show up OK, all units run OK, node joins cluster.

=== /etc/hostname ===
localhost

=== /etc/kubernetes/kubelet/env ===
NODE_IP=192.168.101.171
NODE_LABELS=
NODE_TAINTS=
POD_INFRA_CONTAINER_IMAGE=602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/pause-amd64:3.1

=== /etc/kubernetes/kubelet/config ===
---
kind: KubeletConfiguration
...SNIP...
clusterDNS:
- 10.100.0.10
...SNIP...
MaxPods: 29

=== /etc/kubernetes/kubelet/kubeconfig ===
---
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority: "/etc/kubernetes/pki/ca.crt"
    server: "https://16D8E306F5C75C5BF9C7FDA2A4DFAC90.yl4.us-west-2.eks.amazonaws.com"
    ...SNIP...

=== /etc/kubernetes/pki/ca.crt ===
-----BEGIN CERTIFICATE-----
MII ...SNIP... AA=
-----END CERTIFICATE-----

=== /etc/containerd/config.toml ===
...SNIP...
sandbox_image = "602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/pause-amd64:3.1"
...SNIP...

=== /etc/updog.toml ===
...SNIP...
seed = 572

=== /etc/chrony.conf ===
pool 169.254.169.123 iburst

pool 2.amazon.pool.ntp.org iburst
...SNIP...

[iliana]

Does this require a migration?

[tjkirch]

Does this require a migration?

The data would be stored the same way, so... not according to the traditional definition. What would happen is that the API would refuse to load invalid data you had stored previously, after the upgrade. We could write a migration that truncates invalid data rather than failing, but I highly doubt anyone inserted invalid data that they care about, since it wouldn't work in the tools loading the config files.

[iliana]

What would happen is that the API would refuse to load invalid data you had stored previously, after the upgrade.

How does the system behave in this state? Does it replace it with None and carry on?

I agree that we're still in the "this is unlikely input" stage but I want to make sure we're answering these questions every time we change settings codepaths :)

[tjkirch]

How does the system behave in this state? Does it replace it with None and carry on?

No, it'd be noisy and fail most requests related to settings; in its view, the data store would be essentially corrupted.