Skip to content
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

"Resettable" Parameters #1395

Open
ANeumann82 opened this issue Mar 6, 2020 · 0 comments
Open

"Resettable" Parameters #1395

ANeumann82 opened this issue Mar 6, 2020 · 0 comments

Comments

@ANeumann82
Copy link
Member

What would you like to be added:
A parameter flag/type that will be unset after a plan is executed, or another methods to unset a parameter after a plan is finished.

Why is this needed:
There are multiple use cases.

UseCase 1: The BACKUP_NAME specifies the name of a backup that is to be created or restored
This parameter needs to be unique on every execution and should not be reused. If the parameter is not unset after the backup plan is finished, a user could forget to set it again for the next execution.

UseCase 2: The 'RESTORE_FLAG': This parameter can be used on installation of a new C* cluster to restore an existing backup. It sets up an initContainer that downloads the data and prepares the new cluster to use this data.
The initContainer is only used on the very first start of the cluster and should not exist on subsequent restarts of the nodes, additionally the RESTORE_FLAG is useless/not used after the initial deploy plan is done.

Idea 1
We could have a flag on a parameter:
resettable: true
KUDO would recognize the flag and unset specific parameters.

Needs some planning on after which plans a parameter is reset, etc.

Idea 2
Add new task, TaskSetParameters:

  - name: backup-done
    kind: SetParams
    spec:
      params:
        - name: 'RESTORE_FLAG'
           value: nil

This is a lot more powerful, but also provides a lot more ways to introduce complexity: Parameter values could change inside a plan execution, what about triggered plans from param changes, etc.

Idea 1 seems a bit easier to handle.

Should be considered in the same realm as #1383

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant