Skip to content

Conversation

@smklein
Copy link
Collaborator

@smklein smklein commented Jul 15, 2023

Fixes #3637

@smklein smklein marked this pull request as ready for review July 15, 2023 04:24
@smklein smklein requested review from andrewjstone and iliana July 15, 2023 04:24
Copy link
Contributor

@iliana iliana left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this fixes the issue!

@smklein smklein enabled auto-merge (squash) July 15, 2023 04:27
@smklein smklein merged commit f47fc26 into main Jul 15, 2023
@smklein smklein deleted the safer-wipe branch July 15, 2023 04:37
smklein added a commit that referenced this pull request Jul 17, 2023
…ore (#3642)

This builds on #3638 , with
a slightly more fine-tuned mechanism.

- `crypt/zone` is created on new U.2s, if it doesn't already exist
- If it **does** exist, then Sled Agent needs to make a call: Should I
delete the dataset, possibly containing zones from last boot, or should
I leave it alone (for idempotency)?
- In #3638 , we used "was the filesystem previously mounted" as a proxy
for this information. However, in cases where the sled agent reboots,
this information gets out-of-date -- the filesystem could be mounted,
but sled agent should remove the corresponding dataset.

This PR introduces a filesystem property, simply called 'oxide:agent',
which is a randomly generated string created statically during the
lifetime of the Sled Agent. If the sled agent reboots, this value will
be regenerated, which instructs the sled agent to wipe `crypt/zone` and
re-create it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Wiping crypt/zone is too aggressive

4 participants