One fix in lo kubehz deploy and lo kubehz register, in Go and bash (#247). It keeps the agent on the cluster record that register made. No change to the piped output of the other commands.

Fixes

• The bind Secret goes in before the agent. lo kubehz deploy now stages the kubehz-agent-bind Secret before it applies the agent CronJob, in both the operator and the cronjob modes. Before, a CronJob run in the gap between the two could register without the bind secret, and the agent then reported to a second record instead of the announced row.
  • If staging the Secret fails while .kubehz-bind exists, the deploy stops before it changes the agent. The error says what changed so far.
  • Without .kubehz-bind, the deploy warns: the agent registers a separate pending row, and you claim that row with lo kubehz claim-code.
  • --dry-run says that the Secret goes in first. It never prints the value.
• Every register call sends the stored bind secret. A re-run of lo kubehz register now presents the secret from .kubehz-bind, so the platform keeps the same cluster record. lo sends the value only when the file is a readable regular file of exactly 64 lowercase hex characters.
• The bind secret is written in place. lo replaces .kubehz-bind under its own name with mode 0600, so the file is always covered by the .gitignore line that lo init project writes. A directory, or a link to one, in that place is refused with a warning.

Upgrade

• The deploy now needs patch on Secrets in the kubehz-system namespace, and create when the Secret is new. It no longer needs delete. The built-in admin and edit roles have these verbs. A kubeconfig without patch used to warn and now stops the deploy with the verbs named.
• A cluster whose agent already reports to a separate record keeps it. Claim that record with lo kubehz claim-code.