borgmatic-collective/borgmatic
borgmatic-collective
/
borgmatic
15
57
Fork 40
Code Issues 53 Pull Requests 1 Actions Packages Releases 121 Activity

Inherit common configuration #381

New Issue
Closed
opened 2020-12-09 17:52:53 +00:00 by witten · 2 comments
witten commented 2020-12-09 17:52:53 +00:00
Owner
Copy Link

What I'm trying to do and why

I have a bunch of different applications to backup, each with slightly different options. But they have many options in common, and I don't want to repeat those options for each application.

I could use the existing include merging feature, but that results in an awkward configuration files where you have to do multiple includes, one per section.

It would be great if there was a more supported way to inherit and reuse common configuration options across the entire configuration file.

Other notes / implementation ideas

One idea is to update the existing include merging feature to do "deep merging". That might look something like this:

/etc/borgmatic/common.yaml contents:

location:
   ...
   
retention:
   keep_daily: 1
   keep_hourly: 2

And /etc/borgmatic.d/myapp.yaml contents:

<<: !include /etc/borgmatic/common.yaml
retention:
    keep_daily: 5

This would perform a deep merge of all sections including the retention section, such that the resulting interpreted option values would be a keep_daily of 5 and a keep_hourly of 2.

If you tried this today with a current borgmatic version, the entire retention section in /etc/borgmatic.d/myapp.yaml would replace the entire retention section from the common file—not what the user wants under this use case.

Note that if this deep merging change were made, it would technically be a breaking change to the existing include merging behavior.

#### What I'm trying to do and why I have a bunch of different applications to backup, each with slightly different options. But they have many options in common, and I don't want to repeat those options for each application. I could use the existing [include merging](https://torsion.org/borgmatic/docs/how-to/make-per-application-backups/#include-merging) feature, but that results in an awkward configuration files where you have to do multiple includes, one per section. It would be great if there was a more supported way to inherit and reuse common configuration options across the *entire* configuration file. #### Other notes / implementation ideas One idea is to update the existing include merging feature to do "deep merging". That might look something like this: `/etc/borgmatic/common.yaml` contents: ```yaml location: ... retention: keep_daily: 1 keep_hourly: 2 ``` And `/etc/borgmatic.d/myapp.yaml` contents: ```yaml <<: !include /etc/borgmatic/common.yaml retention: keep_daily: 5 ``` This would perform a deep merge of all sections including the retention section, such that the resulting interpreted option values would be a `keep_daily` of `5` and a `keep_hourly` of `2`. If you tried this today with a current borgmatic version, the *entire* `retention` section in `/etc/borgmatic.d/myapp.yaml` would replace the entire `retention` section from the common file—not what the user wants under this use case. Note that if this deep merging change were made, it would technically be a breaking change to the existing include merging behavior.
witten commented 2022-04-26 04:23:19 +00:00
Author
Owner
Copy Link

Implemented in master! Now you can do this:

<<: !include /etc/borgmatic/common.yaml

location:
   ...

retention:
    keep_daily: 5

... where common.yaml is:

retention:
    keep_hourly: 24
    keep_daily: 7

And it'll do the right thing and produce a keep_hourly value of 24 and an overridden keep_daily value of 5.

Implemented in master! Now you can do this: ```yaml <<: !include /etc/borgmatic/common.yaml location: ... retention: keep_daily: 5 ``` ... where `common.yaml` is: ```yaml retention: keep_hourly: 24 keep_daily: 7 ``` And it'll do the right thing and produce a `keep_hourly` value of `24` and an overridden `keep_daily` value of `5`.
witten commented 2022-04-26 17:10:36 +00:00
Author
Owner
Copy Link

Released in borgmatic 1.6.0!

Released in borgmatic 1.6.0!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
spot-check
1.8.10
1.8.9
1.8.8
1.8.7
1.8.6
1.8.5
1.8.4
1.8.3
1.8.2
1.8.1
1.8.0
1.7.15
1.7.14
1.7.13
1.7.12
1.7.11
1.7.10
1.7.9
1.7.8
1.7.7
1.7.6
1.7.5
1.7.4
1.7.3
1.7.2
1.7.1
1.7.0
1.6.6
1.6.5
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.24
1.5.23
1.5.22
1.5.21
1.5.20
1.5.19
1.5.18
1.5.17
1.5.16
1.5.15
1.5.14
1.5.13
1.5.12
1.5.11
1.5.10
1.5.9
1.5.8
1.5.7
1.5.7.dev0
1.5.6
1.5.5
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.4.22
1.4.21
1.4.20
1.4.19
1.4.18
1.4.17
1.4.16
1.4.15
1.4.14
1.4.13
1.4.12
1.4.11
1.4.10
1.4.9
1.4.8
1.4.7
1.4.6
1.4.5
1.4.4
1.4.3
1.4.2
1.4.1
1.4.0
1.3.26
1.3.25
1.3.24
1.3.23
1.3.22
1.3.21
1.3.20
1.3.19
1.3.18
1.3.17
1.3.16
1.3.15
1.3.14
1.3.13
1.3.12
1.3.11
1.3.10
1.3.9
1.3.8
1.3.7
1.3.6
1.3.5
1.3.4
1.3.3
1.3.2
1.3.1
1.3.0
1.2.18
1.2.17
1.2.16
1.2.15
1.2.14
1.2.13
1.2.12
1.2.11
1.2.10
1.2.9
1.2.8
1.2.7
1.2.6
1.2.5
1.2.4
1.2.3
1.2.2
1.2.1
1.2.0
1.1.15
1.1.14
1.1.13
1.1.12
1.1.11
1.1.10
1.1.9
1.1.7
1.1.6
1.1.5
1.1.4
1.1.3
1.1.2
1.1.1
1.1.0
1.0.3
1.0.2
1.0.1
1.0.0
0.1.8
0.1.7
0.1.6
0.1.5
0.1.4
0.1.3
0.1.2
0.1.1
0.1.0
0.0.7
0.0.6
0.0.5
0.0.4
0.0.3
0.0.2
Labels
Clear labels   
bug

   
data loss

   
design finalized

   
good first issue

   
new feature area

   
question / support

   
security

   
waiting for response
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#381
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?