also looking at this
feat(consolidation): report an attach's credential radius, and rename a server in place
#175
12 files
+1138
-14
| @@ -154,6 +154,7 @@ See [Preview environments](/features/preview-environments) for policy, source li | ||
| 154 | 154 | | `cloud server:list` / `server:create <name>` / `server:destroy <name>` | Manage servers. | |
| 155 | 155 | | `cloud server:ssh <name>` / `server:logs <name>` / `server:monitoring <name>` | Connect / logs / metrics. | |
| 156 | 156 | | `cloud server:deploy <name>` / `server:reboot` / `server:resize <name> <type>` | Deploy / reboot / resize. | |
| 157 | | `cloud server:rename <name> <new-name> [--apply]` | Rename a server in place. Prints the plan; `--apply` performs it. | | |
| 157 | 158 | | `cloud server:recipe <name> <recipe>` | Run a reusable script across servers. | |
| 158 | 159 | | `cloud server:worker:add/list/restart/remove` | Queue workers (Supervisor). | |
| 159 | 160 | | `cloud server:cron:add/list/remove` | Scheduled jobs / cron. | |
| @@ -164,6 +165,49 @@ See [Preview environments](/features/preview-environments) for policy, source li | ||
| 164 | 165 | |
| 165 | 166 | See [Laravel / Forge-style](/features/laravel) for the `infrastructure.compute` + `sites` config. |
| 166 | 167 | |
| 168 | ### Renaming a server | |
| 169 | ||
| 170 | A name is spelled in four places, and a rename is only done when all four agree: | |
| 171 | the provider record, the local driver state pin | |
| 172 | (`storage/cloud/state/<stack>.json`), the box's own hostname, and the fleet | |
| 173 | inventory record. The state pin is the one that is not cosmetic — a deploy | |
| 174 | REFUSES a pinned server whose live name no longer matches the recorded one, a | |
| 175 | guard against a stale pin sending a database operation to another project's box | |
| 176 | — so renaming at the provider alone quietly invalidates it. | |
| 177 | ||
| 178 | ```bash | |
| 179 | cloud server:rename bughq hq-production-server # plan only | |
| 180 | cloud server:rename bughq hq-production-server --apply # perform it | |
| 181 | ``` | |
| 182 | ||
| 183 | Without `--apply` it prints the plan and changes nothing: | |
| 184 | ||
| 185 | ``` | |
| 186 | server:rename bughq | |
| 187 | → Rename the server at the provider | |
| 188 | bughq → hq-production-server | |
| 189 | → Update the recorded name in the local driver state | |
| 190 | bughq → hq-production-server | |
| 191 | ok Set the hostname on the box [already done] | |
| 192 | → Rename the fleet inventory record | |
| 193 | bughq → hq-production-server | |
| 194 | 3 step(s) would run | |
| 195 | Re-run with --apply to perform it. | |
| 196 | ``` | |
| 197 | ||
| 198 | Every step asks reality whether it is already done, so a rename that dies | |
| 199 | halfway is resumed by running the same command again — the finished steps skip | |
| 200 | themselves rather than being attempted twice — and a completed rename re-runs as | |
| 201 | `Nothing to do`. A step whose capability is missing is dropped and reported | |
| 202 | under `not covered`: a hand-enrolled server has no provider record, a project | |
| 203 | deploying purely from labels has no state pin, and a box whose host key is not | |
| 204 | pinned cannot be reached to set a hostname (`cloud server:validate` first). | |
| 205 | ||
| 206 | Renaming is reversible by renaming back, so it needs no typed confirmation. It | |
| 207 | is also non-interactive by construction — the plan is data and the authorization | |
| 208 | is a flag — so it runs unattended from CI, and `--json` emits both the plan and | |
| 209 | the outcome. Each step appends to the operation log as it starts and finishes. | |
| 210 | ||
| 167 | 211 | ## Databases |
| 168 | 212 | |
| 169 | 213 | `cloud db:create` · `db:list` · `db:connect` · `db:tunnel` · `db:users:add` · `db:users:list` · |