Moving to openstack-dev for more visibility and discussion. 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.
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. Steve Baker(original author) would probably know more about it and can give you a better answer:) [1] https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/deployment.py [2] https://github.com/openstack/heat/blob/master/heat/engine/service_software_config.py#L262 On Wed, Nov 30, 2016 at 5:54 PM, Pasquale Lepera <pasquale.lep...@csi.it> wrote: > Hi, > we're trying to use the Heat Software configuration APIs, but we're facing > a problem with the signaling. > 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: > > #os-collect-config --print > inputs:[ > … > { > "type": "String", > "name": "deploy_signal_transport", > "value": "CFN_SIGNAL", > "description": "How the server should signal to heat with the > deployment output values." > }, > { > "type": "String", > "name": "deploy_signal_id", > "value": "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%2B0NJi7Z3q > O%2BmwToqINUiKbvw%3D", > "description": "ID of signal to use for signaling output values" > }, > { > "type": "String", > "name": "deploy_signal_verb", > "value": "POST", > "description": "HTTP verb to use for signaling output values" > } > > 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. > > 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: > > #os-collect-config --print > ... > { > "inputs": [], > "group": null, > "name": "test_key_gen_9aznXZ7DE9", > "outputs": [], > "creation_time": "2016-11-24T15:50:50", > "options": {}, > "config": "#!/bin/bash\ntouch /tmp/test \nhostname > /tmp/test \n", > "id": "d9395163-4238-4e94-902f-1e8abdbfa2bb" > } > > This appens because we pass to the create SW config API no explicit > parameter in the “inputs” key. > Of course, this config causes no signaling back to Heat. > > So the questions are: > > Is it possible to use the cfn signaling with the software > configuration/deployment creation APIs? > > How? > > Is it possible to have a signaling back to the orchestration without > passing manually a deploy_signal_id inside the API's configuration > parameters? > > 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::WaitConditionHandlewaitsignals” > resources, but before using this workaround we want to be sure that is not > possible in other ways. > > Thanks > > Pasquale > > _______________________________________________ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > -- Regards, Rabi Misra
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
