Stacker 1.0.0 breaks variable output lookup cf 1.0.0a6

[jonathanunderwood]

Moving to the 1.0.0 release leads to breakage for a stack, part of which looks like this:

  - name: ops-manager
    class_path: opsmgr.AutoscalingGroup
    variables:
        Name: mongodb-om-${GitBranch}
        Role: "MongoDB OpsManager application"
        ImageId: ${ImageId}
        InstanceSize: t2.large
        IamInstanceProfile: XXXXXX
        KeyName: ${KeyName}
        Subnets:
          - subnet-XXXXXXX # data eu-west-1a
          - subnet-XXXXXXX # data eu-west-1b
          - subnet-XXXXXXX # data eu-west-1c
        SecurityGroups:
          - ${security-group-ops-manager::SecurityGroupId}
          - sg-e2f85384 # base linux
          - sg-db6ba9bd # core io
        ElbSubnets:
          - subnet-XXXXXXXX # enterprise eu-west-1a
          - subnet-XXXXXXXX # enterprise eu-west-1b
          - subnet-XXXXXXXX # enterprise eu-west-1c
        ElbSecurityGroups:
          - ${security-group-ops-manager-elb::SecurityGroupId}
        UserDataTemplate: ud-opsmgr.j2
        UserDataVars:
          <<: *opsmgr_ec2_userdata_vars
        <<: *required_tags
  - name: ops-manager-dns
    class_path: route53.RecordSet
    variables:
      HostedZone: hosted.zone.
      DNS: mongodb-om1-${GitBranch}.aws-something.com.
      Type: CNAME
      Destination: ${ops-manager::ElbDns}
      <<: *dns_params

The blueprint route53.RecordSet has and output added for ElbDns. With 1.0.0a6, there's no problem, but with 1.0.0 stacker bails with:

[2017-03-05T08:25:27] Tailing stack: mongodb-opsmgr-master-ops-manager-dns
Traceback (most recent call last):
  File "/var/lib/jenkins/jobs/mongodb-opsmanager/workspace/env/bin/stacker", line 9, in <module>
    args.run(args)
  File "/var/lib/jenkins/jobs/mongodb-opsmanager/workspace/env/lib/python2.7/site-packages/stacker/commands/stacker/build.py", line 52, in run
    dump=options.dump)
  File "/var/lib/jenkins/jobs/mongodb-opsmanager/workspace/env/lib/python2.7/site-packages/stacker/actions/base.py", line 124, in execute
    self.run(*args, **kwargs)
  File "/var/lib/jenkins/jobs/mongodb-opsmanager/workspace/env/lib/python2.7/site-packages/stacker/actions/build.py", line 283, in run
    plan.execute()
  File "/var/lib/jenkins/jobs/mongodb-opsmanager/workspace/env/lib/python2.7/site-packages/stacker/plan.py", line 267, in execute
    if not self._single_run():
  File "/var/lib/jenkins/jobs/mongodb-opsmanager/workspace/env/lib/python2.7/site-packages/stacker/plan.py", line 227, in _single_run
    status = step.run()
  File "/var/lib/jenkins/jobs/mongodb-opsmanager/workspace/env/lib/python2.7/site-packages/stacker/plan.py", line 74, in run
    return self._run_func(self.stack, status=self.status)
  File "/var/lib/jenkins/jobs/mongodb-opsmanager/workspace/env/lib/python2.7/site-packages/stacker/actions/build.py", line 209, in _launch_stack
    stack.resolve(self.context, self.provider)
  File "/var/lib/jenkins/jobs/mongodb-opsmanager/workspace/env/lib/python2.7/site-packages/stacker/stack.py", line 153, in resolve
    resolve_variables(self.variables, context, provider)
  File "/var/lib/jenkins/jobs/mongodb-opsmanager/workspace/env/lib/python2.7/site-packages/stacker/variables.py", line 77, in resolve_variables
    variable.resolve(context, provider)
  File "/var/lib/jenkins/jobs/mongodb-opsmanager/workspace/env/lib/python2.7/site-packages/stacker/variables.py", line 143, in resolve
    raise FailedVariableLookup(self.name, e)
stacker.exceptions.FailedVariableLookup: Couldn't resolve lookups in variable `Destination`. Unknown lookup type: "None"

so it's failing to understand the lookup for ElbDns. In fact its trying to build that stack too early, as it's not resolved the dependency on the "ops-manager" stack. Stacker is using the default AWS provider, as expected.

[jonathanunderwood]

OK, looking through the code, this looks like it might be an undocumented change of syntax, and output lookup no longer requires the ${ .. } syntax. So Destination: ${ops-manager::ElbDns} would be replaced by Destination: ops-manager::ElbDns. Is that correct, and intended behaviour?

If so, the docs need an update, since the docs still detail the ${otherstack::var} style syntax.

[phobologic]

Thanks! I thought I'd caught this reference everywhere, but obviously not. I'll take a look at stacker_blueprints in the morning to make sure the examples match up.

[jonathanunderwood]

Actually, it seems like this still works in 1.0.0: Destination: ${output ops-manager::ElbDns} i.e. explicitly specifying the lookup handler.

Moving forward, can you give a steer on what the preferred, and hopefully not broken in the future, preference is? :)

[jonathanunderwood]

Ah, scratch that, our messages crossed in the ether - I see explcitly stating the output handler is the way forward.

[jonathanunderwood]

Thanks for the rapid response!

[phobologic]

@jonathanunderwood We removed the behavior for output to be the default behavior. You have to be explicit now.

[phobologic]

Haha, more crossed communication! No worries! Also, you should join the slack team - there's quite a bit of talk there :)

[jonathanunderwood]

Ooh! I had no idea there was a slack channel! What's the name?

[phobologic]

@jonathanunderwood https://empire-slack.herokuapp.com/ will let you join the slack team - there's a #stacker channel there.