-
Notifications
You must be signed in to change notification settings - Fork 57
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
vdk-core: support overriding configs with secrets #3125
vdk-core: support overriding configs with secrets #3125
Conversation
projects/vdk-core/src/vdk/internal/builtin_plugins/config/secrets_config.py
Show resolved
Hide resolved
projects/vdk-core/src/vdk/internal/builtin_plugins/config/secrets_config.py
Outdated
Show resolved
Hide resolved
projects/vdk-core/src/vdk/internal/builtin_plugins/config/secrets_config.py
Outdated
Show resolved
Hide resolved
4713e03
to
9ac75cb
Compare
projects/vdk-core/src/vdk/internal/builtin_plugins/config/secrets_config.py
Outdated
Show resolved
Hide resolved
I was wondering if we need to finalize the configuration at vdk_configure. So I am ok if we ship the current implementation as it is. But this is not the first time we've had to create workarounds due to the limitation that configuration options can only be set during that phase. In the JobConfigIniPlugin, we check if the command is run and search for the config.ini file. Perhaps we could allow for more dynamic configuration? As it is currently, vdk_configure is used to define the available configuration options, but the actual values can be provided or overridden later by dynamically added providers.
Configuration providers can be dynamically added at any point in the application's lifecycle.
|
projects/vdk-core/src/vdk/internal/builtin_plugins/config/secrets_config.py
Show resolved
Hide resolved
fd63463
to
b3d3612
Compare
b3d3612
to
a95415f
Compare
Follow-up #3156 |
0a48b0e
to
7a6ad23
Compare
projects/vdk-plugins/vdk-plugin-control-cli/tests/test_secrets_plugin.py
Show resolved
Hide resolved
50e91e8
to
3bb12a2
Compare
Why? VDK doesn't provide a way to set sensitive configuration like passwords, such as trino_password. The only way to currently do this is by adding config keys and fetching the values from secrets. What? Add a plugin that reconfigures the Configuration object in CoreContext based on secrets. Do this in the initialize_job hook. In this setup, secrets override options set by regular configs. For example if you set trino_password to "password" in config.ini, but also have a secret called trino_passowrd="another password", the value of trino_password will be "another_passowrd". How was this tested? Functional test CI/CD What kind of change is this? Feature/non-breaking Signed-off-by: Dilyan Marinov <[email protected]>
3bb12a2
to
888b38d
Compare
Uncomment test after #3125 Signed-off-by: Dilyan Marinov <[email protected]>
Uncomment test after #3125 Signed-off-by: Dilyan Marinov <[email protected]> Co-authored-by: Dilyan Marinov <[email protected]> Co-authored-by: Duygu Hasan <[email protected]>
Why?
VDK doesn't provide a way to set sensitive configuration like passwords, such as trino_password. The only way to currently do this is by adding config keys and fetching the values from secrets.
What?
Add a plugin that reconfigures the Configuration object in CoreContext based on secrets. Do this in the initialize_job hook. In this setup, secrets override options set by regular configs. For example if you set trino_password to "password" in config.ini, but also have a secret called trino_passowrd="another password", the value of trino_password will be "another_passowrd".
Note: The Configuration class and the CoreContext class are annotated with
@dataclass(frozen=True)
. This enforces encapsulation, so in order to mutate the Configuration object after it's created, we have to add more public methods to the Configuration class.https://docs.python.org/3/library/dataclasses.html#frozen-instances
How was this tested?
Functional test
CI/CD
What kind of change is this?
Feature/non-breaking