using user_data to update status back to HEAT during execution.

Registered by Maharajan Nachiappan

We recently faced some issue when we are trying to use HEAT orchestration for Automating deployment solution.
This solution is not related to core but as an optional resource implementation as part of the orchestration. I would welcome any ideas, suggestions.

Problem Faced:
 1. HEAT as an orchestrator in creating VMs (Nova instances) and subsequently using the user_data section to deploy some application in it.
 2. wget the deployment script file as part of user_data and execute it.
 3. All is going good when no issues on executing the script file.
 4. When the deployment script failed to execute or failed in middle of something.
 5. As an Orchestrator HEAT do not get any chance to know about on which state the error happend, and what the error is during run time. Util we see the log files in the VM

Proposing Solution:
 1. Thought of having a Message Queue, where post_installation script or the user_data scripts will make use of this Queue to put messages about the current state
 2. HEAT consider the Message Queue consumer as a resource (optional) in the orchestration work-flow. So that It can listen to the Queue message.
 3. Make decisions to close the resource either create complete or update complete using WaitTime exceeds or ExpectedStatus received, I have mentioned in the below sample template.
 4. OR it will come out failed when any error occur duing attempt to connect MQ server.
 5. The idea is, we can keep on putting the received message as a status of the VM in the HEAT DB until we get the ExpectedStatus.
 6. MQ can be ActiveMQ.

Challenges:
 1. VM should know about the MQ information?
  - As part of the USER_DATA, we need create a config file which has MQ information.
  - USER_DATA section or the Image it self have some MQ client (binary) which enable posting the message to Queue.
  - USER_DATA executes something mentioned below where ever it requires.
  e.g., producer -body="USERDATA-DONE" -exchange="cloud-init" -exchange-type="fanout" -key="cloudinit-key" -reliable=true -uri="amqp://guest:guest@localhost:5672/"
 2. Why a different MQ?
     - This solution is more on Application than Openstack, Application also use this to send messages to HEAT.
     - Application can collect the messages for their metrics.
     - Application will manage this Queue.

"Resources"{
 "MQCloudInitStatus" : {
      "Type" : "OS::CloudInit::MessageQueue",
      "Properties" : {
        "MQHost" : { "Ref" : "MQHost" },
        "MQUser" : { "Ref" : "MQUser" },
        "MQPassword" : { "Ref" : "MQPassword" },
     "MQExchange" : {"Ref": "MQExchange"},
     "MQQueue" : {"Ref": "MQQueue"},
        "WaitTime" : {"Ref": "WaitTime"},
        "MQKey" : {"Ref": "MQKey"},
        "ExpectedStatus" : {"Ref", "ExpectedStatus"}
    }
}

"Parameters": {
        "MQHost": {
            "Description": "MQ server name",
            "Default" : "mqserver.test.com:5672",
            "Type": "String"
        },
        "MQUser": {
            "Description": "MQ server user name",
            "Default" : "user",
            "Type": "String"
        },
        "MQPassword": {
            "Description": "MQ server password",
            "Default" : "NOPASS",
            "Type": "String"
        },
        "MQExchange": {
            "Description": "MQ server Exchange name",
            "Default" : "cloud-init",
            "Type": "String"
        },
        "MQQueue": {
            "Description": "MQ server Queue name",
            "Default" : "cloud-queue",
            "Type": "String"
        },
        "MQKey": {
            "Description": "MQ server Queue Key",
            "Default" : "cloudinit-key",
            "Type": "String"
        },
        "ExpectedStatus": {
            "Description": "Expected Status, HEAT will wait until either it receives this message or mark failed if take more than the 'WaitTime' ",
            "Default" : "USERDATA-DONE",
            "Type": "String"
        },
        "WaitTime": {
            "Description": "Overall time for the resource to complete",
            "Default" : "10",
            "Type": "String"
        }
}

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Thomas Herve

Related branches

Sprints

Whiteboard

(achudnovets) I think this functionality can be acquired using image with heat-cfntools (https://github.com/openstack/heat-cfntools) and AWS::CloudFormation::WaitConditionHandle.
For example you can look for this template:
https://github.com/openstack/heat-templates/blob/master/cfn/F17/WordPress_Single_Instance_With_HA.template

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.