> Is there any way to propagate tags to all res...
# yaml
Is there any way to propagate tags to all resources using YAML?
Currently no. There's no support for stack transforms, we've been thinking about maybe enabling that via an external policy but might also be worth supporting some simple transforms in yaml directly so feel free to raise a request.
How can I use Stack Reference with YAML
Yes, the code you posted to the thread looks right to me but it does look like the docs pages is missing a section. Raised an issue for that https://github.com/pulumi/pulumi-hugo/issues/2798
Can I use logic and loops in YAML?
No the design is intended to be for very simple uses cases, our thinking is if you need logic and loops you shouldn't be using YAML. There is an issue for this https://github.com/pulumi/pulumi-yaml/issues/191 but the current stand is either upgrade to a full language (which is what
pulumi convert
helps with) or use a templating system like CUE or Jinja.
Figuring out arrays in YAML was a huge pain in the ass.
Structured config like arrays and objects is still being improved. As you've pointed out the errors aren't great because it's pretty much a raw dump of the schema validation, we have an issue tracking that at https://github.com/pulumi/pulumi/issues/11129.
My major blocker now is the array from configuration. Why is this so terrible?
I think (and I haven't touched the yaml codebase for a bit) because yaml never had support for arrays or objects as config. The engine can handle them but YAML doesn't. I'm working on a new set of tests to cover all the language to makes sure they're consistent about their support for config values. Fixing this should fall out from that work.
This seems to successfully get the vpc, but how do make it a local resource?
Not totally sure what your asking here given the code snippet? Do you mean how do you define a vpc resource for pulumi to create instead of get?
Thank for for the feedback, this is helpful. Regarding stack references, am I doing something incorrect?
Copy code
  vpcId: ${shared-infrastructure.outputs["vpcId"]}

    type: pulumi:pulumi:StackReference
      name: ${sharedInfrastructureStackName}
    type: aws:ec2/vpc:Vpc
      # This fails as a stack reference, but succeeds if I hardcode the VPC ID here
      id: ${vpcId}
I have an existing VPC that was created by another team that rolls out the underlying infrastructure. We insulate our Pulumi stacks with a "shared-infrastructure" layer that's responsible for providing Stack outputs for reference for existing infrastructure, or standing up new infrastructure that's required across that account.
Please keep me posted on the YAML array situation if you need a guinea pig.
That looks like what I would expect, a quick test you could do use take that yaml and run
pulumi convert --language typescript
and see what TS code it gives you and see if that program works as expected. If it does then it's probably a bug in the yaml runtime.
Looks incorrect:
Copy code
const sharedInfrastructure = new pulumi.StackReference("shared-infrastructure", {name: sharedInfrastructureStackName});
const vpcId = sharedInfrastructure.outputs.vpcId;
const sharedVpc = new aws.ec2.Vpc("shared-vpc", {});
That does look wrong, can you open an issue at https://github.com/pulumi/pulumi-yaml/issues with those code snippets.
Also, maybe this is intentional, but when I ran it without the
flag, it overwrote my
oh, it overwrote more than that...
I think the default is to output to the same directory, which does overwrite any Pulumi.yaml already there. Not sure if the sensible thing there is to default to something like --out=./out, require a prompt to say it's ok to overwrite or do like
pulumi new
and require --out to be empty. Worth raising another issue at https://github.com/pulumi/pulumi/issues to point out this UX is not ideal as is though, we can take some ideas of what would be the most preferable behaviour.
I would suggest either 1. A warning with prompt to continue, or 2. A default directory