Re: [Openstack-operators] [openstack-dev] Heat: signaling using SW config/deployment API.

[Pasquale Lepera]

Thank you Rami, so, if I got it, looking at the code, the suggested process for a sw deployment in our case is a task series (maybe realized using python-celery) like this: 1) Create a swift temp_url for the signaling dedicated to the deployment 2) Pass this url, and all the necessary parameters, to the software config as inputs 3) Create a deploy with an intitial state IN_PROGRESS 4) Monitor the swift_url state for a signal received (or a timeout occurred) 5) Update the deploy status in SUCCES/FAILED 6) Remove the swift temp_url. Am I right?   Regards, Pasquale Lepera    >  _________________________________________________________________________  >    >   Il 1 dicembre 2016 alle 11.29 Rabi Mishra <ramis...@redhat.com> ha scritto:  >    >   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%2B0NJi7Z3qO%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@lists.openstack.org  >   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators  >    >    >    >  --  >   Regards, Rabi Misra  >

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators