[update-agent] provide ability to configure update channel

[colhom]

As of now, we'd have to ssh in to do this. Users seem to expect to be able to do this via Kubernetes.

The simplest approach would seem to be have update-agent check for external changes container-linux-update.v1.coreos.com/group node annotation and reconcile those changes with update-engine and the /etc/coreos/update.conf file on the host.

Alternatively, we could also carve out an update.v1.coreos.com/desired-group annotation (leaving the current /group annotation read-only from user perspective) and do a two-phase commit on changing a nodes update channel.

• (user) set desired-group
• update engine observes group != desired-group annotations
• changes made to /etc/coreos/update.conf
• send signal to update engine
• node reboots and has group == desired-group annotations

\cc @euank @alekssaul

[dghubble]

Dup #25, but let's track it here.

[dghubble]

I like it, I think its in-scope.

I favor the simpler container-linux-update.v1.coreos.com/group annotation approach unless there is a known situation that calls for the two-phase approach. Here, I the desired state would be the annotation value and the actual state would be the /etc/coreos/update.conf contents.

Edge cases:

1) Node annotation doesn't exist. Agent initializes it based on /etc/coreos/update.conf "actual state", if it exists, otherwise does nothing. 2) Even if the agent and a user/component try applying an annotation at the same time, there is a serial ordering to the writes. Agent can pickup the new desired state in the reconciliation loop.