How to get WaitCondition Data in instance

Asked by JunJie Nan on 2013-06-20

In UserData, I use cfn-singal in MySql instance as below:
"/opt/aws/bin/cfn-signal --id 00001 -e 0 -r done --data 'done' '",{ "Ref" : "MySqlWaitHandle" }, "'\n",

My question is, how do I get { id:00001, data:done} from other instance? Say WordProc, thanks!

I tried heat resource-metadata stack WaiHandle, which can get the signal data. But the question is how to get it in instance.

Question information

English Edit question
OpenStack Heat Edit question
No assignee Edit question
Solved by:
JunJie Nan
Last query:
Last reply:
Revision history for this message
Launchpad Janitor (janitor) said :

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

Revision history for this message
JunJie Nan (nanjj) said :

(Now I know the answer)

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

Revision history for this message
Zane Bitter (zaneb) said :

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.

Revision history for this message
Liang Chen (cbjchen) said :

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

Revision history for this message
JunJie Nan (nanjj) said :

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.

Revision history for this message
Zane Bitter (zaneb) said :

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.

Revision history for this message
JunJie Nan (nanjj) said :

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.

Revision history for this message
Clint Byrum (clint-fewbar) said :

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.

Revision history for this message
JunJie Nan (nanjj) said :

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.

Revision history for this message
Zane Bitter (zaneb) said :

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.