pulumi / pulumi-yaml

YAML language provider for Pulumi
Apache License 2.0
39 stars 12 forks source link

Nested provider properties are not fully supported #455

Open t0yv0 opened 1 year ago

t0yv0 commented 1 year ago

What happened?

When using explicit providers with YAML, I cannot extract nested properties from the explicit provider.

Expected Behavior

Nested properties work the same as top-level string properties.

Steps to reproduce

name: gcp-props

runtime: yaml

resources:
  provider:
    type: pulumi:providers:gcp
    properties:
      project: pulumi-development
      batching:
        enableBatching: true
        sendAfter: 3s

outputs:
  project: ${provider.project}
  batching: ${provider.batching}
  sendAfter: ${provider.batching.sendAfter}
pulumi preview
Diagnostics:
  pulumi:pulumi:Stack (gcp-props-dev):
    Error: batching does not exist on provider
      on Pulumi.yaml line 16:
      16:   batching: ${provider.batching}
    Existing properties are: id, region, urn, zone, project and 128 others
    Error: batching does not exist on provider
      on Pulumi.yaml line 17:
      17:   sendAfter: ${provider.batching.sendAfter}
    Existing properties are: id, region, urn, zone, project and 128 others

Notice how .project accessor succeeds but .batching does not. It seems to work for sending data to the provider but not getting it back.

Output of pulumi about

CLI          
Version      3.64.0
Go Version   go1.20.3
Go Compiler  gc

Plugins
NAME  VERSION
gcp   unknown
yaml  unknown

Host     
OS       darwin
Version  13.1
Arch     x86_64

This project is written in yaml

Current Stack: t0yv0/gcp-props/dev

Found no resources associated with dev

Found no pending operations associated with dev

Backend        
Name           pulumi.com
URL            https://app.pulumi.com/t0yv0
User           t0yv0
Organizations  t0yv0, pulumi

No dependencies found

Pulumi locates its logs in /var/folders/gk/cchgxh512m72f_dmkcc3d09h0000gp/T/ by default

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

t0yv0 commented 1 year ago

boolean properties might be also affected.

t0yv0 commented 1 year ago

Very curious, this also affects TypeScript. Some fundamental limitation?

const gcpp = new gcp.Provider("gcpp", {
    region: "pulumi-development",
    batching: {
        enableBatching: true,
        sendAfter: "5s",
    },
    userProjectOverride: true,
});

I can access gcpp.region but not gcpp.batching and cpp.userProjectOverride though they all seem to be defined approx the same way in the TF provider.

justinvp commented 1 year ago

Very curious, this also affects TypeScript. Some fundamental limitation?

Summarizing discussion from Slack: Providers didn't originally expose output properties in generated SDKs, although a change was made to expose output properties typed as string. Output properties of other types are not currently exposed. These others are JSON encoded, so would need to be deserialized.

t0yv0 commented 1 year ago

Thanks @justinvp ! I've definitely worked around this limitation for my use case so this remains a nice-to-have. We could either deserialize JSON or (even better, but larger change) stop using nested JSON for transmitting provider configuration data. Thanks!