-
Notifications
You must be signed in to change notification settings - Fork 115
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
Provider config should be available as outputs #2486
Labels
customer/feedback
Feedback from customers
customer/lighthouse
Lighthouse customer bugs and enhancements
kind/enhancement
Improvements or new features
Milestone
Comments
mnlumi
added
customer/feedback
Feedback from customers
customer/lighthouse
Lighthouse customer bugs and enhancements
labels
Aug 2, 2023
Related: |
EronWright
added a commit
that referenced
this issue
Oct 18, 2023
<!--Thanks for your contribution. See [CONTRIBUTING](CONTRIBUTING.md) for Pulumi's contribution guidelines. Help us merge your changes more quickly by adding more details such as labels, milestones, and reviewers.--> ### Proposed changes Closes #2486 This PR exposes the provider input properties as outputs, and normalizes those inputs to provide the effective values. This opens up some new scenarios: 1. Use the provider's namespace as an input property, in a uniform way. 2. A better experience when the ambient kubeconfig is changed; Pulumi reports a diff to `namespace`, `context` or `cluster` as appropriate, which helps to explain why downstream changes may be occurring. ### Detailed Changes The following provider inputs are normalized such that they contain the effective values in stack state: 1. `namespace` - normalized to contain the ambient namespace or `default`. 2. `context`- normalized to contain the ambient context name. 3. `cluster` normalized to contain the ambient cluster name. The `kubeconfig` property is not normalized, which means that the application would need to manually load the ambient config. It seems like a bad idea to normalize the `kubeconfig` for a few reasons: 1. it bloats the stack state to include the entire kubeconfig contents. 2. the kubeconfig may contain a secret in rare situations but isn't modeled as a secret input. 6. the application can workaround it, since the raw output is now available. The Helm provider was simplified to always take the merged kubeconfig (`apiConfig`) from the kube provider, as opposed to reloading it in some cases. This should have no effect on the behavior. Some minor improvements to kubeconfig loading logic: 1. Use a non-interactive loader for the kubeconfig, since the provider is a non-interactive server (see [original PR](e85e033#diff-5e83e1a18ae8dd9641b49e491350ae5b8afaf7fdb60dfcf4d4447a17e334e473R26)). The rationale is to be consistent with the (newer) Helm code. 2. When the `kubeconfig` property is path-like, don't try to parse it as content. This improves the error message. 3. Fallback to using the `default` namespace (as opposed to undefined) for diff purposes when the config could not be loaded. The special-case logic around 'replacement' was simplified to consider only the normalized server name. That is, the provider recommends replacement when the `name` field of the active server has changed. The earlier code had major limitations - it didn't consider the ambient kubeconfig, and didn't support kubeconfig paths. ### Testing New tests were added and/or updated: 1. `TestProvider` - updated to verify that the provider's `namespace` output property is useable as an input to other resources. 2. `TestProviderOutputs` - added to verify provider outputs and the normalization logic. 3. `Test_loadKubeconfig` - added to verify kubeconfig loading/parsing logic. New utility code was developed for easily asserting that certain engine events occurred during `ExtraRuntimeValidation`; see `util.go#AssertEvents`. ### Example Here's an example showing the use of the provider's new `namespace` output property, and showing the improved change detection related to the ambient namespace. The program relies on the ambient kubeconfig, uses the ambient namespace to create a `Deployment`, and binds the provider's `namespace` output property to the stack outputs: ```yaml name: issue-2486-yaml runtime: yaml description: A minimal Kubernetes Pulumi YAML program outputs: namespace: ${k8s.namespace} deployment: ${deployment.metadata.namespace}/${deployment.metadata.name} resources: k8s: type: pulumi:providers:kubernetes deployment: type: kubernetes:apps/v1:Deployment options: provider: ${k8s} properties: spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx ``` The procedure deploys the stack, changes the ambient namespace, and then previews the changes: ```plain ❯ pulumi up -f Updating (dev) View in Browser (Ctrl+O): https://app.pulumi.com/eron-pulumi-corp/issue-2486-yaml/dev/updates/8 Type Name Status Info + pulumi:pulumi:Stack issue-2486-yaml-dev created (3s) 4 warnings + ├─ pulumi:providers:kubernetes k8s created (0.12s) + └─ kubernetes:apps/v1:Deployment deployment created (2s) Outputs: deployment: "default/deployment-bf4abb76" namespace : "default" Resources: + 3 created Duration: 4s ❯ kubectl config set-context --current --namespace eron Context "docker-desktop" modified. ❯ pulumi preview Previewing update (dev) View in Browser (Ctrl+O): https://app.pulumi.com/eron-pulumi-corp/issue-2486-yaml/dev/previews/2cf2c42a-0a95-42b3-b193-ffca7f401fc7 Type Name Plan Info pulumi:pulumi:Stack issue-2486-yaml-dev 4 warnings ~ ├─ pulumi:providers:kubernetes k8s update [diff: ~namespace] +- └─ kubernetes:apps/v1:Deployment deployment replace [diff: ~metadata] Resources: ~ 1 to update +-1 to replace 2 changes. 1 unchanged ``` The resultant stack state: ```json { "urn": "urn:pulumi:dev::issue-2486-yaml::pulumi:providers:kubernetes::k8s", "custom": true, "id": "78fe6e28-5f2e-4823-af95-df9021ce46f9", "type": "pulumi:providers:kubernetes", "inputs": { "cluster": "docker-desktop", "context": "docker-desktop", "namespace": "default" }, "outputs": { "cluster": "docker-desktop", "context": "docker-desktop", "namespace": "default" }, "parent": "urn:pulumi:dev::issue-2486-yaml::pulumi:pulumi:Stack::issue-2486-yaml-dev", "created": "2023-10-06T00:06:46.065029Z", "modified": "2023-10-06T00:06:46.065029Z" }, ``` ### Related issues (optional) <!--Refer to related PRs or issues: #1234, or 'Fixes #1234' or 'Closes #1234'. Or link to full URLs to issues or pull requests in other GitHub repositories. -->
rquitales
pushed a commit
that referenced
this issue
Oct 24, 2023
This reverts #2598. <!--Thanks for your contribution. See [CONTRIBUTING](CONTRIBUTING.md) for Pulumi's contribution guidelines. Help us merge your changes more quickly by adding more details such as labels, milestones, and reviewers.--> ### Proposed changes <!--Give us a brief description of what you've done and what it solves. --> Mitigates #2626 ### Related issues (optional) Original issue: #2486
Reopening this because the PR was reverted. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
customer/feedback
Feedback from customers
customer/lighthouse
Lighthouse customer bugs and enhancements
kind/enhancement
Improvements or new features
Hello!
Issue details
It should be possible to get the configuration values of a Provider as outputs. For example, the
kubeconfig
orenableServerSideApply
setting would be useful to see.To make this change, the
provider
field in the schema needs to includeproperties
as well as the existinginputProperties
. Once this change is made, the SDKs will be generated with the appropriate output properties for string types. pulumi/pulumi#13435 is tracking a change required to support other primitive types as well.Example:
Affected area/feature
The text was updated successfully, but these errors were encountered: