feature: configurable backup schedules and retention for development environments

[shreddedbacon]

Checklist

• Affected Issues have been mentioned in the Closing issues section
• Documentation has been written/updated
• PR title is ready for changelog and subsystem label(s) applied

As described in #3073 it could be useful to define separate schedules and retention periods for development environments.

The aim of this PR is to allow backups for development environments of type branch or pullrequest to have different backup schedules and retention periods configured. It is possible to allow pullrequests to have a completely different schedule to all other environments as well. Individual environments can also have their schedule and retention adjusted individually

The behaviour will be as below:

• Currently the default values are passed in via remote-controller or fall back to hardcoded values in kubectl-build-deploy-dind
• Will now check if the environment being deployed is branch or pullrequest
• If the environment is a branch type, and is a development environment
  • Checks if LAGOON_BACKUP_DEV_RETENTION and LAGOON_BACKUP_DEV_SCHEDULE are defined, and will use the values of these to override the defaults
  • If LAGOON_BACKUP_DEV_RETENTION and LAGOON_BACKUP_DEV_SCHEDULE are not defined
    • Checks if ones that remote-controller could inject exist LAGOON_FEATURE_BACKUP_DEV_RETENTION and LAGOON_FEATURE_BACKUP_DEV_SCHEDULE
  • If any of these are not defined, it will fall back to what is provided by remote-controller or hardcoded
• If the environment is a pullrequest type
  • Checks if LAGOON_BACKUP_PR_RETENTION and LAGOON_BACKUP_PR_SCHEDULE are defined, and will use the values of these to override the defaults
  • If LAGOON_BACKUP_PR_RETENTION and LAGOON_BACKUP_PR_SCHEDULE are not defined
    • Checks if ones that remote-controller could inject exist LAGOON_FEATURE_BACKUP_PR_RETENTION and LAGOON_FEATURE_BACKUP_PR_SCHEDULE
  • If any of these are not defined, it will fall back to checking the DEV environment variables are defined before finally falling back to what is provided by remote-controller or hardcoded

The way to define these variables is as follows:

X_RETENTION variables should be defined as H:D:W:M, which is hourly, daily, weekly, monthly as colon separated values.
Example, 0:7:6:1, where

• 0 Hourly
• 7 Daily
• 6 Weekly
• 1 Montly

X_SCHEDULE variables are just the cron definition.
Example, M H(22-2) * * *

Closing issues

closes #3073

[tobybellwood]

Should the controller injected variables follow the existing LAGOON_FEATURE_FLAG_{DEFAULT|FORCE} schema?

[shreddedbacon]

Should the controller injected variables follow the existing LAGOON_FEATURE_FLAG_{DEFAULT|FORCE} schema?

Maybe, will think about this

[cdchris12]

We're already setting these values in production via .lagoon.yml; why are we implementing these settings entirely in the API ? Feels weird to have a different method of setting production vs branch/pr configurations.

https://github.com/uselagoon/lagoon/blob/main/images/kubectl-build-deploy-dind/build-deploy-docker-compose.sh#L1144-L1147

[tobybellwood]

I'd be more in preference for adding production settings via the API (in addition to .lagoon.yml for now) rather than the gnarly beast of adding dev/pr backup config to .lagoon.yml - the potential for merge errors/retention mismatches is too great.

Having all settings configurable via the API then allows us more flexibility for future UI development.