They contained json data, so they need application/json as the
content types. Else, some wsgi implementations will interpret the
contents in an undesired way, such as apache's mod_wsgi setting the
whole POST body as a POST parameter with no value.
Change-Id: Id988e8d286761550da4849c0695f5f5a37116a11
Closes-Bug: #1641589
Currently we send signals for every deployment, even those already
completed, so instead keep a record of already-signalled deployments
similar to how heat-config does, which will remove the annoying
SIGNAL_COMPLETE: Unknown events (and possibly be slightly faster too).
Partial-Bug: #1564627
Change-Id: I0ec7ed4cc4e58a43a91e8323cb9a1bcaaafc9752
Currently signalling via 99-refresh-completed only uses the legacy
curl data payload (e.g that for CFN compatible WaitConditions),
but now we're using it exclusively for signalling SoftwareDeployment
resources, which support a different payload, including deploy_stdout
which is accessible via a resource attribute.
Returning a payload for deploy_stdout containing the derived config ID
is potentially useful as it changes whenever the SoftwareConfig or any
inputs change, thus can be used as a unique identifier for dependent
resources which need to be re-triggered when some config is reapplied,
for example puppet manifests with a dependency on hieradata applied
via a SoftwareDeployment.
get_attr: [ControllerDeployment, deploy_stdout]
Partial-Bug: #1463092
Change-Id: Ic62b6303795f70f3b9ace46731a21d1c0e7fe6c7
Currently we have a TripleO specific template pattern, where all
deployment resources are configured NO_SIGNAL, regardless of what
DefaultSignalTransport is set to, and only one signal for all
deployments is sent via the *AllNodesDeployment resources, by adding
the heat-generated deploy_signal_id to the structured config data
consumed by os-apply-config (as "completion-signal").
This is inconsistent with all signalling done via heat-config (e.g
everything other than o-a-c, which is triggered via a hook via
55-heat-config, this transparently consumes the heat-generated
deploy_signal_id and signals heat after each deployment hook is
run.
To allow per-deployment signalling for os-apply-config configs,
this adds logic which looks in the deployment data processed by
os-apply-config and signals all deployments deploying a config with
group "os-apply-config" (everything else should be handled by 55-heat-config)
Note that if the deployment is configured NO_SIGNAL, no deploy_signal_id
will be set, thus this will do nothing, and currently this won't work with
HEAT_SIGNAL, only CFN_SIGNAL (which is the default for deployments with no
signal_transport specified). In future it would be good to add support for
HEAT_SIGNAL to break the dependency on heat-api-cfn.
This is backwards compatible, but after it's merged we can remove all the
NO_SIGNAL's in the templates, and the completion-signal key from the
allNodesConfig, which should in future allow more flexible control of
the ordering of metadata update for configs applied via o-a-c (as well
as better visibility of progres during deployment).
Co-Authored-By: Dan Prince <dprince@redhat.com>
Change-Id: I72ea524effd07deeb432fb38ee7da5f3dc7990a7
Closes-Bug: #1389178
When we curl to the complete waitcondition url we don't consider heat
returning an error as reason to exit with error. This prevents us from
attempting to re-run the configuration and thus we never signal heat
again.
Change-Id: I915825d76ec889bc09b81ad93f70b34d909262b0
Closes-bug: #1306294
The new software config / deployments resources use signals.
A subtle difference between wait condition handles and signals in Heat
is that signals use POST, but wait conditions use PUT. This has
historical reasons that mostly are due to Amazon compatibility. We need
to continue to support both until we can eliminate all use of wait
conditions.
Change-Id: I69d9103b07100f700fb71a2cbbf267042625e7a7
Most of the time we will find it useful to pass a wait condition in for
os-refresh-config to signal when it has completed successfully.
This supersedes the notcompute element's completion-handle, so we can
remove that element. It should be removed from tripleo-incubator and
tripleo-ci as well.
Change-Id: Iff65da3dd0a1db496cfd33b4a55abb13c68c9558
It is valid to request os-refresh-config without putting any scripts in
the element root. This fixes failing builds of heat-cfntools.
Change-Id: I4f70b33e453399ff5baa48919557995a6eb27520
Ghanshyam Mann