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

There are a few answers for this :slightly_smiling_face: (A short thread).

When you read the output, it will be a single Output object, wrapped around whatever type you're outputting. So iterating over it depends on the wrapped type. It also has to be done inside an apply, since it's an output.

We could explore the best way to do this, but first, would there be a way to change your logic to avoid doing it? Creating resources inside an apply, which in this case would be necessary, is never ideal and is always worth putting a bit of effort into avoiding (if possible).

For example, if you know that the list will always be 8 entries long (until something changes enough that you're prepared to update the code), then IMO it would be better to simply repeat the code 8 times, or even to loop 8 times.

Either way, you can use your applies inside the constructors to get the various values from the list of outputs, without actually invoking the constructors inside an apply.

We output a bunch of kubeconfigs with predictable names to get around this. “region-provider-purpose”, and in our consuming stack we have 3 nested loops, for all regions and all providers and all purposes, require output and do the thing.

I figured there had to be something like this for kube considering it's nested nature

Can you point me to an example <@U01BRSYUUDP>?

not anything public but it is nothing more than `export const ekseuropestaging = new Cluster() ` in stack 1, and then

```for (const provider in providers) { 
for (const region in regions) { 
for(const env in envs){ 
const provider = new k8s.Provider(subject.uniqueName, {    kubeconfig: pulumi.unsecret(clusterStack.requireOutput(`${provider}${region}${env}`)),
    suppressDeprecationWarnings: true,
  })
}}}```


nothing built in, just cobbled together on my own

and we moved to different stacks now, since an issue in one of the clusters was interfering with the rest, but we use the same predicable name method but now for stacks

```export function getProvider(subject: ClusterServiceEntity, staging: boolean) {
  // fetch the cluster and kubeconfig
  const clusterStack = new pulumi.StackReference(
    `settlemint/bpaas-clusters/${subject.provider.toLowerCase()}-${subject.region.toLowerCase()}${
      staging ? '-staging' : ''
    }`
  );
  return new k8s.Provider(subject.uniqueName, {
    kubeconfig: pulumi.unsecret(clusterStack.requireOutput(`kubeconfig`)),
    suppressDeprecationWarnings: true,
  });
}```

All of this does seem like a limitation, however it should not be that difficult to work around. For now I'll keep lists out of output to simplify my code.

wha, never bothered me TBH. Maybe the pulumi crew knows better ways

I'll open an issue and see if we can work it out
For now it's not blocking me and I've got bigger fish to fry