How to get WaitCondition Data in instance

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

(Now I know the answer)

we can get signals in instance via cfn-get-metadata -s stack_name -r handle_name

The recommended way is to use:

  {"Fn::GetAtt": ["MySqlWaitCondition", "Data"]}

in the template in the UserData or Metadata sections of the other server. This sets up the dependency automatically, and enlists the engine to insert the correct data into the server for you.

I saw some recent comments addressing this post, so I took the liberty opening it up again.

The problem is signals may be changed, for example, before cfn-signal invoked, signals is empty, after cfn-signal invoked, there will be some data in it. So I prefer cfn-get-metadata -s stack_name -r handle_name to retrieve latest signals data.

Right, you don't want to read it until after cfn-signal is called. That's why "Fn::GetAtt" adds a dependency, so any instance referencing the WaitCondition's Data won't be created until after the WaitCondition is complete (i.e. cfn-signal has been called). So the method I mentioned above is guaranteed to work by design - in fact, that's the entire point of orchestration.

The cfn-get-metadata method, on the other hand, is not portable (won't work on CloudFormation) and is extremely likely to stop working on Heat in the future, possibly the very near future. It's making use of a hack (WaitCondition data is stored in the metadata of the handle) in Heat that we are already taking steps to eliminate.

seemly we should expose an api to do the job of the hack.

what's Fn::GetAtt blocked is the whole resource, while, there may be several configurations in a single resource. Not same.

I don't want a direct API for it actually. I just want it in the Metadata, and I want any Metadata that references it to be updated when the signal happens. The reason is that as a template author, this gives me an enormous amount of visibility and control over which credentials can access the data from a waitcondition. If there is an API, that is less discoverable, and more work for us as Heat developers.

It sounds OK, if we can remove the creation dependency, say in resource A metadata ref "Fn::GetAtt": ["WaitCondition", "Data"], resource A can still be created before WaitCondition complete.

In AWS the WaitConditionHandle is actually a pre-signed URL to an S3 bucket. I don't think it's readable by instances though, for security reasons.