allow passing arbitrary flags to borg #235
Labels
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: borgmatic-collective/borgmatic#235
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What I'm trying to do and why
in #234, i tried to reproduce a backup script i had which was using
--keep-exclude-tags
. you have been very nice and immediately implemented support for it in release 1.4.4, but I'm wondering what would happen if a new borg release would come out while you're on a holiday and we all want to use that shiny new feature.Other notes / implementation ideas
Could we get a way to inject arbitrary commandline arguments into the various borg commands that borgmatic issues? i would understand why we wouldn't want to do that if borgmatic talks directly to the (non-existent, really) borg API, but that's not how it works. as I understand it, it shells out to borg commands, and generates the "right" combination of commandline arguments to make it do what's specified in the config file.
If we're going to give this a shot, some thoughts on design:
There are several different Borg sub-commands that borgmatic invokes (prune, create, check, etc.), and the flags for each one are different.. with the exception of global parameters. So would there need to be support for passing arbitrary flags to each of the Borg sub-commands separately? Example borgmatic options that could support that:
borg_create_options
,borg_prune_options
,borg_global_options
.Due to the nature of this arbitrary flags feature, borgmatic can't validate any of the arbitrary flags passed to Borg. That means that we'd need to add a prominent warning to the documentation that a user is responsible for reconciling any arbitrary flags with those flags produced by standard borgmatic configuration. In fact, if a user has a particular Borg flag configured as an arbitrary flag, and then a future version of borgmatic adds native support for that flag, the user's configuration may stop working as intended.
having per-command variables and a global option sets is exactly what i had in mind. it does mean quite a good chunk of optons, unfortunately... maybe it could be a hash of some sort?
and yes, i think this is a "wheels off" approach: people can and might just shoot themselves in the foot, by design.
You mean a separate section in the YAML configuration just for these options?
i guess so? maybe something like:
?
Got it. I could see that working in terms of organization.
This is now implemented for several (non-interactive) Borg sub-commands, and released in borgmatic 1.4.17. To configure, check out the new
extra_borg_options
in thestorage
section of borgmatic's configuration. Here's an example:Enjoy! And thanks for the suggestion.