<div dir="ltr"><div><div><div>Moving to openstack-dev for more visibility and discussion. <br><br></div>We currently have signal API for heat resources(not for standalone software config/deployment). However, you can probably use a workaround with swift temp_url like tripleo[1] to achieve your use case.<br><br>We do have rpc api[2] for signalling deployments. It would probably not be that difficult to add REST API support for native/cfn signalling, though I don't know if there are more reasons for it not being added yet.<br></div><br></div><div>Steve Baker(original author) would probably know more about it and can give you a better answer:)<br></div><div><br></div><div><div><div><br>[1] <a href="https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/deployment.py">https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/deployment.py</a><br>[2] <a href="https://github.com/openstack/heat/blob/master/heat/engine/service_software_config.py#L262">https://github.com/openstack/heat/blob/master/heat/engine/service_software_config.py#L262</a><br><div><br>On Wed, Nov 30, 2016 at 5:54 PM, Pasquale Lepera <span dir="ltr"><<a href="mailto:pasquale.lepera@csi.it" target="_blank">pasquale.lepera@csi.it</a>></span> wrote:<br><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div><div>Hi,<br>we're trying to use the Heat Software configuration APIs, but we're facing a problem with the signaling.</div>
<div>We quite well know how to use Software config/deployment inside stack Templates, and in that case what we got on the target VM is something like this:<br><br></div>
<div>#os-collect-config --print<br>inputs:[<br>…<br> {<br> "type": "String", <br> "name": "deploy_signal_transport", <br> "value": "CFN_SIGNAL", <br> "description": "How the server should signal to heat with the deployment output values."<br> }, <br> {<br> "type": "String", <br> "name": "deploy_signal_id", <br> "value": "<a href="http://ctrl-liberty.nuvolacsi.it:8000/v1/signal/arn%3Aopenstack%3Aheat%3A%3Ab570fe9ea2c94cb8ba72fe07fa034b62%3Astacks%2FStack_test_from_view_galera-53040%2F15d0e95a-e422-4994-9f17-bb2f543952f7%2Fresources%2Fdeployment_sw_mariadb2?Timestamp=2016-11-24T16%3A35%3A12Z&SignatureMethod=HmacSHA256&AWSAccessKeyId=72ef8cef2e174926b74252754617f347&SignatureVersion=2&Signature=H5QcAv7yIZgBQzhztb4%2B0NJi7Z3qO%2BmwToqINUiKbvw%3D" target="_blank">http://ctrl-liberty.nuvolacsi<wbr>.it:8000/v1/signal/arn%<wbr>3Aopenstack%3Aheat%3A%3Ab570fe<wbr>9ea2c94cb8ba72fe07fa034b62%<wbr>3Astacks%2FStack_test_from_<wbr>view_galera-53040%2F15d0e95a-<wbr>e422-4994-9f17-bb2f543952f7%<wbr>2Fresources%2Fdeployment_sw_<wbr>mariadb2?Timestamp=2016-11-<wbr>24T16%3A35%3A12Z&<wbr>SignatureMethod=HmacSHA256&<wbr>AWSAccessKeyId=72ef8cef2e17492<wbr>6b74252754617f347&<wbr>SignatureVersion=2&Signature=<wbr>H5QcAv7yIZgBQzhztb4%2B0NJi7Z3q<wbr>O%2BmwToqINUiKbvw%3D</a>", <br> "description": "ID of signal to use for signaling output values"<br> }, <br> {<br> "type": "String", <br> "name": "deploy_signal_verb", <br> "value": "POST", <br> "description": "HTTP verb to use for signaling output values"<br> }</div>
<div><br>This part, we suppose, is generated by heat during the Template processing and is pushed to the target so that, when the deployment is finished, the os-apply-config uses CFN to signal to the orchestrator the SUCCESS/FAILED job.</div>
<div> </div>
<div>The problem is that, when we try to use directly the software config creation API and the deployment one, what we got in the target VM is something like this:</div>
<div> </div>
<div>#os-collect-config --print<br>...<br> {<br> "inputs": [], <br> "group": null, <br> "name": "test_key_gen_9aznXZ7DE9", <br> "outputs": [], <br> "creation_time": "2016-11-24T15:50:50", <br> "options": {}, <br> "config": "#!/bin/bash\ntouch /tmp/test \nhostname > /tmp/test \n", <br> "id": "d9395163-4238-4e94-902f-1e8ab<wbr>dbfa2bb"<br> }</div>
<div><br>This appens because we pass to the create SW config API no explicit parameter in the “inputs” key. <br>Of course, this config causes no signaling back to Heat.<br><br>So the questions are:</div>
<div> </div>
<div>Is it possible to use the cfn signaling with the software configuration/deployment creation APIs? <br><br>How?<br><br>Is it possible to have a signaling back to the orchestration without passing manually a deploy_signal_id inside the API's configuration parameters?<br><br>If not, another way to give a signal back to Orchestrator, could be a workaround creating a self-standing stack containing only “OS::Heat::WaitCondition” and “OS::Heat::WaitConditionHandle<wbr>waitsignals” resources, but before using this workaround we want to be sure that is not possible in other ways.<br><br>Thanks<span class="gmail-m_4116170331787236954HOEnZb"><font color="#888888"><br><br>Pasquale</font></span></div></div>
<br>______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail-m_4116170331787236954gmail_signature"><div dir="ltr"><div>Regards,</div>Rabi Misra<div><br></div></div></div>
</div></div></div></div></div></div></div></div>