Parameter overrides should not clobber other previous parameter values #2701
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
carolynvs
force-pushed
the
uncomment-tests
branch
from
39a818a
to
b958785
Compare
A user should be able to override a parameter value and not have all other previously used parameter values disregarded. porter install --param logLevel=debug --param featureA=enabled porter upgrade --param logLevel=info Currently, any time an override is set, all previous override values are being thrown away. We should update the installation record to use previous values, and any new values specified. So in the example above, both parameters logLevel AND featureA should be remembered on the installation after upgrade is run. As part of this fix, I found some relevant unit tests that had been accidentally commented out and not added back while refactoring. I've uncommented the tests and updated them to work with the new function that resolves parameters. I have also added a smoke test that checks for this regression so that we can't quite so easily break it again in the future. Fixes getporter#2700 Signed-off-by: Carolyn Van Slyck <[email protected]>
I have included the shared docker targets in our Porter magefile so that you can run `mage restartDockerRegistry` and reset our test registry when running tests manually. We call that target in our magefile automatically for you when running smoke tests, but if you are running the test one-off, you need a way to access this target so that you can clear out old test data between runs. Signed-off-by: Carolyn Van Slyck <[email protected]>
carolynvs
force-pushed
the
uncomment-tests
branch
from
b958785
to
ae82b58
Compare
An installation keeps track of previously used parameter overrides over time. Some parameters may apply to only specific actions. When a run is executed and some of the parameters remembered by the installation are not relevant to that run (for example, a parameter only applies to install and we are running upgrade), those irrelevant parameters were previously being persisted on the run regardless. I have fixed the code for creating a new run for an installation to only copy over parameters that apply to the run's action. When this isn't in place, we can end up in a spot where sensitive parameters that don't apply to the current action are prepared to be stored in a secret, but never stored (because they don't apply) but later on we try to resolve all parameters associated with the run and we fail to restore that irrelevant sensitive parameter. The error is confusing, it will just be that we couldn't find a secret named RUNID-PARAM_NAME and it won't be immediately clear why that particular paramter wasn't persisted for that run, unless you realize that it didn't apply... This only became a problem when I fixed how we remember parameters on an installation so that we remember ALL previously used parameters, and not just the paramters used on the last run. Before we never got into this situation where irrelevant parameters were on the installation, but now that can happen and we need to be more careful about how we copy paramters from an installation to a run. Signed-off-by: Carolyn Van Slyck <[email protected]>
Signed-off-by: Carolyn Van Slyck <[email protected]>
As we are now adding/removing/overwriting parameter overrides defined on an installation, let's keep them sorted so that it's easier to compare in tests or to look at when debugging. Signed-off-by: Carolyn Van Slyck <[email protected]>
Signed-off-by: Carolyn Van Slyck <[email protected]>
sgettys
approved these changes
Apr 6, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this change
A user should be able to override a parameter value and not have all other previously used parameter values disregarded.
Currently, any time an override is set, all previous override values are being thrown away. We should update the installation record to use previous values, and any new values specified. So in the example above, both parameters logLevel AND featureA should be remembered on the installation after upgrade is run.
Note that if a user overrides a value using
--param, the only way to remove that override is to edit the installation and remove it. You can't "unset" a parameter override via a CLI flag.As part of this fix, I found some relevant unit tests that had been accidentally commented out and not added back while refactoring. I've uncommented the tests and updated them to work with the new function that resolves parameters. I have also added a smoke test that checks for this regression so that we can't quite so easily break it again in the future.
When I fixed this bug, I found that when we persist the parameters from the installation on the Run (to remember what parameters were used for a particular run of the bundle), we were copying ALL parameters, including ones that don't apply to the current action. I've fixed that as well so that we only persist parameters that apply to the Run's action. The installation will continue to keep a record of all previous parameter values, but for the Run we only persist parameter values used by that particular action.
What issue does it fix
Fixes #2700
Notes for the reviewer
N/A
Checklist
Reviewer Checklist