Add per-connection driver properties #99
Merged
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.
Summary
connectionProperties
parameter to several API methods, includingDeployerProvider
andConfigProvider
.K8sContext
now constructs anApiClient
from theconnectionProperties
, or failing that, fromkube/config
.defaultContext()
and related singleton methods, ensuring the driver is re-entrant and can handle simultaneous connections with different configurations.Details
Previously, we treated
K8sContext
as a lazy-loaded singleton, which was shared across connections. This was preventing us from productionizing the driver in a multi-tenant service, where different clients may want to use distinct namespaces, usernames, etc. To solve this problem, we now constructK8sContext
dynamically from connection-level properties. This required some minor API changes, in order to thread the connection properties through to the various plugins. In particular,DeployerProvider
andConfigProvider
now have access to the connection properties.K8sDeployer
etc use this to constructApiClient
s etc.Testing
Verified the driver loads from the CLI, unit tests pass, and integration tests pass.