-
Notifications
You must be signed in to change notification settings - Fork 58
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
Support for structured config #258
Comments
From what I can tell, this is really critical, as it blocks the ability to configure the AWS Provider to assume a role for deployment execution, since My desired use case is to use a Service-Linked Role for the operator service account so the operator can assume roles, then define the role to use in the stack's |
Looking the CRD spec, this option:
would work with the current implementation? (or now does it just support simple,non-structured values?) About the Also, here we are thinking that would be great if we could inject values from a ConfigMap. Maybe something like that?
|
This is a key functionality for me to elect Pulumi for new-gen platform engineering. I would need to configure the stack CR config parameters for my entire stack. I need to convert all my YAML style configurations to map[string][string] if i use pulumi at this moment. waiting eagerly for #575 |
@geowalrus4gh please I would love to hear your thoughts about the PR and my suggested implementation. It's a key feature for us as well 😅 |
Quick note - while reviewing #575 I confirmed that structured config is somewhat supported although it's not obvious and may not be a viable workaround for all scenarios (particularly secrets). Config values retrieved with Stack CR:
index.ts
Output:
I'm still working through the PR but wanted to share in case it might be helpful to anyone currently blocked by this. |
Hello!
Issue details
Pulumi supports structured configuration which allows using
config.GetObject
. This is really a great feature to represent arrays as yaml array and represent the entire config as go struct.Currently Stack object config field is of type map[string]string. Having support for yaml arrays and object will be helpful.
The value would assumedly come from any of the supported sources, mainly:
Secret
with a key containing a YAML-encoded stringIdeally this feature would be orthogonal to whether or not the value is Pulumi secret.
There may be need for a new configuration block to allow for non-secret structured configuration. Note that
secretsRef
defines Pulumi secrets from a secret or from a literal value, while non-secrets are simply typed asmap[string]string
.Note that the Automation API recently added support for structured configuration: pulumi/pulumi#12265
Examples
Some examples for discussion purposes.
These examples assume the following program:
And intend to generate the following stack configuration:
Using a YAML value from a Kubernetes
Secret
as a Pulumi secret:Using an inline YAML value as a Pulumi secret:
Using inline YAML as a non-secret (via a hypothetical
config2
block):Open Questions
string
as opposed toapiextensionsv1.JSON
. If we were to change the API to useJSON
, then the values would be interpreted as JSON values (e.g.true
would become a bool). Is that an acceptable (breaking) change? Or should ajsonValue
field be introduced? Or should literals be string-encoded? Note thatProgram.spec.configuration.default
is a JSON value (not encoded).json.RawMessage
rather thanapiextensionsv1.JSON
? See Grafana and Tanzu for examples.The text was updated successfully, but these errors were encountered: