We implement that by actually raising `KeyError` in `inventory.delete_by_path`
(as advertised in the docstring), since it makes more sense to catch a
`KeyError` than a generic `ClanError`.
When a machine is deleted with `clan machines delete`, remove its
vars and legacy secrets, and update any secrets that reference the
machine's key.
This command is a superset of `clan secrets machine delete`, and I am
wondering if we could remove the `clan secrets machine` subcommand,
unless there is an use case for having a machine defined without its
key, and any secrets/vars?
Note:
- This deletes the `ListSecretsOptions` dataclass, as it did not seem to
bring any value, especially since `list_secrets` was receiving its
individual members instead of the whole dataclass. We can always bring
it back if complexity grows to demand it.
- `delete` lets you delete a specific var under a specific generator;
- `delete_store` deletes an entire store.
The `delete` method could be useful to "garbage-collect" unused vars as
a machine's configuration changes.
The `delete_store` method can be used to delete all the vars for a
machine when the machine is deleted. The current behavior is to leave
everything behind.
Important point:
- `delete_store` needs to be idempotent because public and
"private"/"secret" vars for a machine can share the same physical
store (directory), and deleting either type of store (public or
private) will delete both.
This reduces overload on the CI, as it already runs multiple test instances in parallel (with-core, without-core, etc), and otherwise would spawn 96 workers for each of those.
Calling it fix in double quotes since that's still quite hand-crafted,
but at least you can now specify options with `@` inside them (e.g.
`ProxyJump`) and have it work properly.
Moreover this fixes the syntax for GET-like variables in the networking
clanCore module. Only the fixed syntax is supported since that's what
was tested, and actually parsed in the code.
