did `getOutputSync` get removed in pulumi 2.0.0 ??
# general
get removed in pulumi 2.0.0 ??
Yeah there are some more details in this thread. https://pulumi-community.slack.com/archives/C84L4E3N1/p1587406029417500
ok thanks.. hopefully it works similarly.. I have a situation where I need to get the dynamo table names, doing it in a callback fashion is a major PITA
i'll have a look!
ugh.. this isnt working:
Copy code
var indexes = <Promise<string[]>>this.dynamodb.getOutputValue('index_names');
        for ( let table of Object.keys(indexes) ) {
TypeError: indexes is not iterable
I create tables in one stack, and then spit out an output with the table and index names in a list
in another stack, i read them and just want to iterate through a loop to create alarms
this is a huge bummer if I have to rewrite this large module
okay making sure i'm following, is the code you linked above how you are trying to access the output values in your second stack?
my outputs look like this:
Copy code
root@c8add1fb4b84:/data/pulumi/infra/aws/company/environment/company-dynamo-tables# pulumi stack output | grep names
    index_names          {"order":["status-uid"],"user":["email"]}
    table_names          ["order", "user"]
i create tables in one stack, and some tables have indexes
in another stack, i read them in as a list, and do a simple loop to create alarms
Copy code
/// alarms
        for ( let table of Object.keys(indexes) ) {

            for ( let index of indexes[table]) {

                var alarm_name = `${this.prefix}-dynamodb-read-throttle-${table}-index-${index}`;
                var alarm = new aws.cloudwatch.MetricAlarm(alarm_name, {
                    name: alarm_name,
                    namespace: `AWS/DynamoDB`,
                    comparisonOperator: 'GreaterThanOrEqualToThreshold',
                    threshold: threshold,
                    statistic: 'Sum',
                    period: period,
                    evaluationPeriods: evaluationPeriods,
                    treatMissingData: 'notBreaching',
                    metricName: 'ReadThrottleEvents',
                    alarmActions: alarm_actions,
                    dimensions: {
                        TableName: `${this.env}-${this.company}-${table}`,
                        GlobalSecondaryIndexName: `index-${index}`



this is inside of an Object, so there are internal properties in
when I previously tried to loop through the outputs using an apply() i had scope issues getting the object params into the closure function, it just seemed like this was an ideal/easy use case to simply synchronously get the outputs and iterate on a loop
i feel like we should have the ability to choose if we want to do it this way, what does it hurt
also, iirc correctly the storing of the alarm using
didn't work either due to the order of operations and they hadnt been created yet to output the alarm names for when I wanted to composite alarm them
Copy code
    var dynamodb_composite = alarm.dynamodb_composite_alarm([
    ], [action_critical]);
bit of callback hell... yes, it's probably fancier to do it this way, but i dont wish to overcomplicate a simple thing
i have a python CLI that runs on top of pulumi as well, i'll just add a new CLI command to scrape the outputs in a previous step and then pass them into the pulumi stack via an env var.. much faster to do that than rework all of this
Thanks for the feedback and opening the issue, it's good for us to be able to track these things. I unfortunately don't have specific guidance for the case you are hitting, but here are some resources from the docs that could be helpful: • https://www.pulumi.com/docs/troubleshooting/#use-getoutputhttps://www.pulumi.com/docs/intro/concepts/programming-model/#outputs
cool, thanks for responding and providing help, keep up the good work!
already about got my workaround in place
Copy code
// outputs from python - <https://github.com/pulumi/pulumi/issues/4462>
        if ( typeof(process.env['TABLE_NAMES']) === 'undefined' ) {
            console.log("TABLE_NAMES env var missing! Please specify it with `pulumi up`");
        if ( typeof(process.env['INDEX_NAMES']) === 'undefined' ) {
            console.log("INDEX_NAMES env var missing! Please specify it with `pulumi up`");

        this.table_names = JSON.parse(String(process.env['TABLE_NAMES']));
        this.index_names = JSON.parse(String(process.env['INDEX_NAMES']));
Copy code
# select dynamo stack
    cmd_list = [
    if co.debug:
        print("[DEBUG] - Select Dynamo Stack CMD: {}".format(cmd_list))
    check_output(cmd_list, cwd=full_cwd_dynamo)

    # get dynamo outputs
    cmd_list = [
    if co.debug:
        print("[DEBUG] - Get Dynamo Outputs CMD: {}".format(cmd_list))
    outputs = json.loads(check_output(cmd_list, cwd=full_cwd_dynamo).decode('utf8').strip())

    # Update alarms stack
    cmd = "TABLE_NAMES='{}' INDEX_NAMES='{}' pulumi update --yes".format(
    if co.debug:
        print("[DEBUG] - Update Alarms Stack CMD: {}".format(cmd))
    check_output(cmd, shell=True, cwd=full_cwd)
I just wanted to add that the decision to remove synchronous APIs wasn’t made lightly; it was breaking things for a lot of users depending on their version of NodeJS. There are some more details in @white-balloon-205’s reply here: https://github.com/pulumi/pulumi/issues/4462#issuecomment-617367272 I’ll update the migration doc with more info about the technical reasons.