https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# typescript
s
This message was deleted.
a
Like a solution could be to just use the original array, and run "finds" on it every time I need to get a provider, but that feels icks.
s
you can't populate the 
Map
within an 
apply
like that. Your function would have to return a
Copy code
pulumi.Output<{
    [x: string]: aws.Provider;
}>[]
but then the 
Output
would sort of taint your resource types in a similar way that 
Promise
does. There isn't really a way around having to deal with 
Output
as long as you want to get the 
id
from an 
aws.organizations.Account[]
a
Let me step back and ask what the "clever way" to deal with this is?
object per account representation? and a getProvider method? Maybe that method populates this.provider if undefined?
What I'm trying to do is operate on a big ass json blob of accounts and what I want their configurations to be (which roles added, which control tower settings enabled).
or something like that. so it's one codebase to many aws accounts.
s
what about adding the account id/name as part of your json blob configuration so it doesn't need to be looked up during runtime?
a
The account id is only in the account blob if it's an older account.
So if an account doen't exist, it creates it, and adds it to the org.
it's really only the "org" object that has most of the information. I'm assuming using an apply from a getAccount to help has the same issues.
s
you'll run into a similar issue, except the 
getResource
functions return a 
Promise
instead of an 
Output
. Given the requirement that you create some of these accounts dynamically I think you may just have to deal with having `Output<Provider>`s. I don't recommend using 
getOrganization
here because the promise may resolve before the new account is actually created. The official stance is that it's not recommended to create resources within an 
apply
but sometimes I do not see a better way around it.
👍 1
a
I'll see what I can do to work around it. I appreciate your insight.
when I say work around, I mean, adjust my approach.
I think I may go down the path of creating an "account" base class, and then instantiating one per account. I can have it do things like, 
if this.accountId === undefined; this.accountId = createAccount(name, email);
so instead of big ass json blob, big ass directory of account objects.
for some reasons I feel like the problems will be smaller and less systemic doing it that way.
I've done enough stuff like
Copy code
export function getOrCreateZone(zoneName: string): any {
  return aws.route53.getZone({
    name: zoneName
  }).then(zone => {
    let zoneId: any  = zone.zoneId;
    if (zoneId === undefined) {
      const newZone: aws.route53.Zone = new aws.route53.Zone(zoneName, {
        comment: `${config.require("stack")} ${zoneName} service`,
        name: zoneName,
        tags: {
          Name: zoneName,
          Environment: config.require("stack")
        }
      });

      zoneId = newZone.zoneId.apply(zId => {return `${zId}`});
    }
    return zoneId;
  });
}
that I think it would work.
s
unrelated, but I'd highly suggest NOT using 
any
. At the very least, let Typescript infer the type for you instead
Copy code
export function getOrCreateZone(zoneName: string) {
  return aws.route53.getZone({ name: zoneName }).then(
    (zone) =>
      (zone.zoneId as string | undefined) ??
      new aws.route53.Zone(zoneName, {
        comment: `${config.require("stack")} ${zoneName} service`,
        name: zoneName,
        tags: {
          Name: zoneName,
          Environment: config.require("stack"),
        },
      }).zoneId
  )
}
a
Fair point. The step after "getting it to work" really should be cleaning stuff like any's up.
3 Views
Open in Slack
PreviousNext
Powered by