conductor 1.9.0

Since 1.8.1:

• story:instance-rules-text: an instance mapping takes standing_rules, a text that every session of the instance reads, whatever its role. POST and PUT /v1/instances take it, at most 16384 bytes of UTF-8 without a NUL; GET /v1/instances/{name} answers it. A text that is, as a whole, a secret:<name> reference is refused.
• The same story: each session's prompt file starts with the text, under one heading line, inside a fenced block that no line of the text closes; the role's profile follows it unchanged. A mapping without the member renders the same pod and the same prompts as before.
• The same story: in a pod the text is in the rendered config file of the instance's Secret and no part of the pod's digest, so a change of the text alone replaces no pod. A session started after the change reads the new text; a running session keeps the text it started with.
• The same story: the instance calls alone write the text. The instance's own settings write, PUT /v1/config and conductor config put refuse the key.

Upgrade: the daemon's Role for instance pods needs one more verb on Secrets of the instance pods' namespace, update; the guide's Role names it. With an older Role, conductor doctor and conductor setup fail on that row, whether or not an instance names the member; a text set when the pod starts is still delivered, and a later change or removal is refused by the API, which the instance's detail says, naming the right. create, delete and update on Secrets can write or replace any Secret of that namespace, so nothing else belongs in it.

Not shown by a test: a kubelet updating the mounted file of a running pod, and anything on a cluster.

Container image

ghcr.io/beyond10x/conductor:1.9.0 at digest sha256:db89298a29c748f4eaf79b362137cd0bfc09e318ba5174a464a8fd0b611ab9b7

docker run --rm ghcr.io/beyond10x/conductor:1.9.0 conductor --version