No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

It doesn’t have an `id` field in the YAML either.

hmm yes that would work, let me see how i can extract it from the Output

This will improve soon, but for now: `whatever.metadata.apply(m =&gt; m.name)`

i was going to ask if that was the most correct :+1:

Soon this will just be something like `foo.metadata.name`

handling that on the outputs was one of the bigger :confused:’s for me

i was also thinking it would be nice to export `core.v1.Container`, because i have some pods that have many containers and i define them as separate values to keep the deployment from getting too long

i can’t type them to Container for validation in my IDE

as it happens we are starting to build higher-level interfaces for this sort of thing.

you can see a WIP PR for this change here: <https://github.com/pulumi/pulumi-kubernetes/pull/399/files>

you can imagine something like:

`container("nginx", "nginx").mountFile("foo.txt", "nginx").deploy(3)` or something.

the `Output&lt;T&gt;` stuff is weird because we need a way to communicate that the values are computed, but common patterns should be very little code.

yeah if this goes well i figure i would be generating some helpers to modify or spawn resources that meet our internal standards

so like inject require labels, specific annotations on ingresses, that kind of thing.

in the mean time you can use `@pulumi/kubernetes/types/input`

You can use that to prototpye individual containers.

perfect, i tried that before but i didnt know how to import that correctly

We hide it because it’s a ton of types and most of them are not useful.