Direction for 0.3.5 (moved out of 0.3.4): a CLI-only wait doesn't protect real deploys, because every supported deploy runs through Cloud's runner (run_deployment). Planned fix (option A): inside run_deployment, before planning, read each target Machine's own row, with a bounded per-Machine timeout that falls back to the Entry's row. No wire, daemon or Store change. Ship it as one PR after the 0.3.4 soak. Related: #3310.
server set: a deploy through another Entry or Cloud can still plan from old Machine settings#3301
Follow-up to #3297 (fixed in #3300 for the Entry the CLI connects through).
ployz server set now waits until the Entry it used lists every changed field a deploy plans from: labels, --accepts-builds, --accepts-services and --accepts-ingress. A deploy that goes through another Entry can still plan from the old values until the replicated Machines table reaches that Entry:
- a context with several connections, where the next command picks a different Server;
- a Cloud Deployment, which uses Ployz Cloud's own connections.
Example. ployz server set MY-SERVER --label-add zone=east, then at once a Cloud Deployment of a Service pinned to zone=east. Cloud's Entry may not list the label yet, so placement finds no Server.
Option. UpdateMachine reports a published revision of the Machines table, and a later deploy can require that its Entry has reached it before it plans. That needs an additive RPC field on MachineUpdated and a matching optional requirement on the deploy request. That is a STABLE PROMISE change, additive only.