Files
tripleo-image-elements/elements/os-refresh-config
Steven Hardy 93e05f569e Signal all o-a-c deployments in 99-refresh-completed
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
2015-01-23 13:00:28 +00:00
..

Install os-refresh-config

os-refresh-config uses dib-run-parts to run scripts in a pre-defined set of directories. Its intended purpose is to quiesce (pre-configure.d), configure (configure.d), migrate (migration.d), and then activate (post-configure.d) a configuration on first boot or in response to Heat Metadata changes.

To cause a script to be run on every os-refresh-config run, install it into one of the following directories:

/opt/stack/os-config-refresh/pre-configure.d
/opt/stack/os-config-refresh/configure.d
/opt/stack/os-config-refresh/migration.d
/opt/stack/os-config-refresh/post-configure.d

If you want to have os-refresh-config run on any updates to a particular Resource in the heat stack, you will need at the minimum the following snippet of json in this instance's Metadata:

{
    "OpenStack::Config": {
        "heat": {
            "access_key_id": {"Ref": "ApiKeyResource"},
            "secret_key": {"Fn::GetAtt": [ "ApiKeyResource", "SecretAccessKey" ]},
            "refresh": [ {"resource": "SomeResource"} ],
            "stack": {Ref: 'AWS::Stack'},
            "region": {Ref: 'AWS::Region'}
        }
    }
}

If you would like to signal a wait condition at the end of post-configure.d, a generic name of 'completion-handle' can be used like so:

{
    "completion-handle": {"Ref": "CompletionHandleName"}
}