Open Stack

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.lepera at 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-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
Regards,
Rabi Misra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20161201/0d9f1f3c/attachment-0001.html>