Skip to main content

ALLOW_REINITIALIZE_ANNOTATION

Constant ALLOW_REINITIALIZE_ANNOTATION 

Source
pub const ALLOW_REINITIALIZE_ANNOTATION: &str = "kopiur.home-operations.com/allow-reinitialize";
Expand description

Acknowledges a deliberate RE-INITIALIZATION of a Repository/ClusterRepository whose backend was wiped: kopiur refuses to auto-create a fresh kopia repository over a once-Ready one (the pinned status.uniqueId), and this annotation is the human “yes, I know the history is gone — make a new one”.

Value: the repository’s CURRENT status.uniqueId, verbatim. Honored only while it equals that pin, which is what makes it self-expiring: the moment the re-initialize succeeds a NEW unique id is minted, the annotation no longer matches, and the ack is inert — so a copy left behind in a GitOps manifest can never authorize a second wipe. Contrast with ALLOW_MASS_DELETION_ANNOTATION (an RFC3339 timestamp, compared against each pending deletion) and with ALLOW_IDENTITY_CHANGE_ANNOTATION (presence-only, consumed at a single admission instant): this one is read continuously by the controller, so it needs a value that goes stale on its own. kopiur never writes or removes it — there is no “honored” stamp to keep in sync.

A value that is present but does NOT match the pin is ignored (fail-safe) and raises one Warning event naming the expected value.