CLI - pvbackup create, schedule, sync and delete

[vh05]

Describe the feature you'd like to have. Create:

1. Create the secret referring restic config file
2. Create the replication source
3. save the details to relatioship file

Schedule:

1. Set schedule on the replication source for
2. Scheduled backups

Sync:

1. Trigger single manual backup by setting manual trigger

Delete:

1. Delete the replicationSource
2. Delete the secret
3. Delete the relationship file

@JohnStrunk please add your thoughts to this

[vh05]

/assign @v-harihar

[vh05]

@JohnStrunk Are we going to back up the PV to another cluster or cloud resource ? What is the destination here ?

[JohnStrunk]

This will be the CLI interface to the Restic data mover. I don't think we really care what the destination is. We just need a way for the user to provide the restic configuration. That way, if it's a target that restic supports, we should be able to move data to/from it.

The main way that restic takes its configuration is via env vars. We need to figure out a reasonable method for the user to communicate the restic config... There's a lot of parameters, and they vary based on the target. Viper may be of use here to allow env vars, a toml file, or CLI options (not sure I'd recommend the cli options since it's insecure).

[vh05]

@JohnStrunk I will just keep posting the question based on my study

1. I assume user should configure backup (kubectl volsync pvbackup create) for interested source dir
2. Is it only schedule based or user can trigger backup?
3. About env variables, if it is toml way, then how user is going to build it? Are we going to accept the CLI args then we update it or the toml file is directly fed by user ?

[JohnStrunk]

1. I assume user should configure backup (kubectl volsync pvbackup create) for interested source dir

A source PVC, not a directory.

2. Is it only schedule based or user can trigger backup?

Both manual trigger and scheduled should be supported. Just like for kubectl volsync replication [sync|schedule]

3. About env variables, if it is toml way, then how user is going to build it? Are we going to accept the CLI args then we update it or the toml file is directly fed by user ?

I don't have a good answer, but here are the considerations:

• We're trying to allow the user to create the restic config Secret in a way that is natural (fits w/ the overall CLI experience)
• The info provided is sensitive since it contains credentials. This means it needs to be provided in a way that isn't prone to leaks. While I'm open to permitting specification on the command-line, it shouldn't be the only way since this leaks the data both into the shell history file and the process table.
  • Secrets today are commonly created by (1) applying a yaml of the Secret w/ stringData or (2) by supplying a filename to be encoded into a field in the Secret kubectl create secret generic mysecret --from-file=key=filename.txt.
    See: kubectl create secret generic -h