You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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
: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
The text was updated successfully, but these errors were encountered: