-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature request] Allow profiles and sections to be disabled #282
Comments
Was also thinking about something like this as there are use cases where a dedicated profile may be created just for a subset of commands. Just not yet sure about how to configure it most efficiently. Disabling individual sections is one option but if you want to enforce that only a handful of commands is used it wouldn’t scale very well. Maybe an include / exclude list of available commands might be better e.g. that could also be used to prevent sections of a base (e.g. default) profile from getting used accidentally. |
Funny enough this week I was considering introducing dot profiles but then I remembered it might not work with TOML. When you need a base profile that you can't really run because it's incomplete, you prefix it with a dot: .base_profile:
source: /
real_profile:
inherit:
- .base_profile
Need to find a nice way to do that in TOML though 🤔 |
Maybe use a prefix like “__” (e.g. __default) and allow to configure the base profile prefix in global for the case that anyone needs to use this name. (Would have also been the case for dot prefixes) A limit of available commands would also be helpful in addition but the base profile filter by prefix would simply disable all commands (using the name is a nice solution as it doesn’t inherit and this can even be used within the inheritance chain) |
Making it configurable with a default of |
Ok in this case we have 2 different ways of configuring it: The original proposal: profiles:
default:
enabled: false
check-only:
inherit: default
enabled: true # must be set as default is disabled
backup:
enabled: false
backup-only:
inherit: default
prune:
enabled: false
restore:
enabled: false
mount:
enabled: false
my-backup:
inherit: backup-only
enabled: true # must be set as default is disabled Is straight forward but very verbose. Was thinking about something like this as an alternative, when integrating the dot profile idea (@creativeprojects, @snstamml what do you think?): version: "2"
global:
base-profiles: "__*" # default, doesn't need to be set
profiles:
__base:
# disabled by default
check-only:
inherit: __base
commands:
enabled: [check]
#disabled: [backup] # -- would disable just backup..
__backup-only:
inherit: __base
commands:
enabled: [backup]
my-backup:
inherit: __backup-only With "commands" section only being available in version 2 because of the quirks we have with list inheritance (or maybe we address it in a 1.1 format). |
The second version seems more readable in general. Clarifications
Maybe it's easier with some examples: profiles:
__base_all: # default values
profile_all: # all commands enabled, as there's nothing specified in the inheritance path
inherit: __base_all
__base_backup: # only backup command available
commands:
enabled: [backup]
profile_backup: # only backup command available, from inheritance
inherit: __base_backup
profile_check_only: # only check command available, inheritance path only has defaults
inherit: __base_all
commands:
enabled: [check]
profile_backup_check: # check command available, also backup from inheritance
inherit: __base_backup
commands:
enabled: [check]
__base_no_forget: # forget command disabled
commands:
disabled: [forget]
__profile_forget: # forget command enabled
inherit: __base_no_forget
commands:
enabled: [forget] Am I missing some corner cases?
It's not a bad idea actually. |
Exactly
Exactly
No, that's also how I'm seeing it, ...with one exception: Inheritance still works as usual (list inheritance with append, as otherwise it replaces the parent) profile_backup_check: # check command available, also backup from inheritance
inherit: __base_backup
commands:
enabled...: [check]
That is the major corner case. Whether enabled or disabled has the higher priority on a conflict. Likely it makes sense to say what is allowed is allowed and cannot be denied. This rule then applies in the final enabled/disabled filter lists after applying all inheritance / composition rules.
Agree. Was thinking to make 1.1 the default if not specified. This means we could remove any issues that we discovered so far that were not intended in the first place and only for the corner case that someone relies on it, we introduce the breaking change that a version must be set. With this change we could even detect version 2 by default when "profiles" is set. So that a version is required only when a specific behaviour must be enforced. Nevertheless that is all optional and out of the scope of this issue. |
There's another thing that is bothering me: the introduction of a |
Is doesn't need to be called Maybe it helps if we flatten it |
2 more thoughts: The filter should really only apply to commands specified in a request (CLI). It should not affect command chains like
|
As resticprofile execute a restic command "blindly", accidently running an unconfigured command like "forget" could be fatal. As a safety measure, it would be helpful if a section could be disabled deliberately, e.g.:
Similarly, as a convenience, a complete profile could be disabled in the same way:
The text was updated successfully, but these errors were encountered: