| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch modifies the interface for the -post stacks so
that we pass RoleData instead of just the StepConfig
into each -post.yaml template.
This will facilitate creating other types of -post.yaml scripts
that require more data that just 'step_config'. Things like
containers, etc. will require this.
Change-Id: I2527fc0098192f092f5e9046033a04bc71be2cae
|
|
Similar to the https://review.openstack.org/#/c/259568 which added support
for the composable services StepConfig and ServiceConfigSettings parameters
so that the Controller role supports composable services, this adds those
interfaces for the ObjectStorage role.
Note that at this time the ObjectStorage post config only supports steps
2, 3 and 4, not all those in services/README.rst
Partially-Implements: blueprint composable-services-within-roles
Change-Id: I22ffaa68a6ccd4be29d51674871268179bcddcbc
|
|
Currently when deploying swift on the Controller nodes, we do the
ringbuilder config during step3 and the swift-storage config during
step 4, but this order is reversed on the ObjectStorage nodes.
Also, we include the base swift class inconsistently during step2
on controller nodes, and via the overcloud-object manifest on
ObjectStorage nodes.
So fix this inconsistency as a precursor to conversion to composable
services interfaces for the ObjectStorage role, we rework the post
config so we apply the ObjectStorage config in steps 2, 3 and 4,
which should hopefully get us much closer to the process used
on the controller role, thus be easier to decompose in a compatible
way.
Partially-Implements: blueprint composable-services-within-roles
Change-Id: Ic9d0ed8584a12d681a8f4d4742d39b96c15e531a
|
|
https://review.openstack.org/#/c/236243 added a new conditional
for the controller steps, but we don't pass any step for the
ObjectStorage nodes, so the deployment fails. This passes a
step that enables the ringbuilder again, although it does end
up inconsistent with the deployment Step name.
Change-Id: I506961f4a22dba9960d819d7376a39e7ccbcdece
Closes-Bug: #1583225
|
|
Adds a new nested stack deployment which allows operators to
opt-in to deploy tarball's and RPM packages by setting
DeployArtifactURLs as a parameter_default in a Heat
environment.
The intent is to use this setting to allow t-h-t to
transparently deploy things like tarballs of puppet modules
via a Swift Temp URL.
Change-Id: I1bad4a4a79cf297f5b6e439e0657269738b5f326
Implements: blueprint puppet-modules-deployment-via-swift
|
|
There are two reasons the name property should always be set for deployment
resources:
- The name often shows up in logs, files and API calls, the default
derived name is long and unhelpful
- Sorting by name determines the merge order of os-apply-config, and the
execution order of puppet/shell scripts (note this is different to
resource dependency order) so leaving the default name results in an
undetermined order which could lead to unpredictable deployment of
configs
This change simply sets the name to the resource name, but a future change
should prepend each name with a run-parts style 2 digit prefix so that the
order is explicitly stated. Documentation for extraconfig needs to clearly
state what prefix is needed to override which merge/execution order.
For existing overcloud stacks, heat currently replaces deployment resources
when the name changes, so this change
Depends-On: I95037191915ccd32b2efb72203b146897a4edbc9
Change-Id: Ic4bcd56aa65b981275c3d4214588bfc4de63b3b0
|
|
Also adds an environment file which can be passed to heat stack-create
to enable debugging.
Change-Id: I9758e2ca3de6a0bed6d20c37ea19e48f47220721
Depends-On: Ie92d1714a8d7e59d347474039be999bd3a2b542f
|
|
When you do a stack-update which affects, e.g ControllerDeployment
such that some value in hieradata is updated (for example changing
the "Debug" parameter to True), we only write the hieradata file and
don't reapply the manifests.
So we introduce a dependency on the deploy_stdout values from all
hieradata applying configs, such that the manifests will be re-applied
on update if the data is changed.
This requires https://review.openstack.org/#/c/190282/ so that
99-refresh-completed will return the derived config ID as part of the
deploy_stdout payload.
Closes-Bug: #1463092
Change-Id: I1175248c3236d0c42e37d062afce550efce8aadc
|
|
This patch bumps the HOT version for the overcloud
to Kilo 2015-04-30. We should have already done this
since we are making use of OS::stack_id (a kilo feature)
in some of the nested stacks. Also, this will give us access to
the new repeat function as well.
Change-Id: Ic534e5aeb03bd53296dc4d98c2ac5971464d7fe4
|
|
Adds optional hooks which can run operator defined additional config on
nodes after the application deployment has completed.
Change-Id: I3f99e648efad82ce2cd51e2d5168c716f0cee8fe
|
|
These appear in the Tuskar UI and CLI so are worth keeping
consistent with those of the controller/compute nodes
Change-Id: I7cdd3a67d6f190f43e279fad0c4bf5f409d1e161
|
|
The upcoming heat hook/breakpoint features will enable stepped deployments
via setting stop points via the resource_registry.
For this to work, we need hard dependencies between each step of the
puppet deployments, because the current "soft" dependencies caused by the
name property only influences the hook script application ordering, not
the graph traversed by heat during deployment.
Since removing the name: puppet_n completely removes some useful self-
documenting context, move this to a resource naming convention, which
should also be useful for heat hooks/breakpoints, as they are expected
to support globbed specification of each step.
Related heat patch (not yet landed, but this is not dependent on it):
https://review.openstack.org/#/c/146123/
Change-Id: I05b02a46d4e80c08a308d033c33d4901c8f6c94e
|
|
This patch adds a new ObjectStoreNodesPostDeployment resource
which can be used along with the environment file to
specify a nested stack which is guaranteed to execute
after all the ObjectStore config deployments have executed.
This is really useful for Puppet in that Heat actually
controls where puppet executes in the deployment
process and we want to ensure puppet runs after
all hiera configuration data has be deployed to
the nodes. With the previous approach some of the
data would be there, but allNodes data would not be
guaranteed to be there in time.
As os-apply-config (tripleo-image-elements) have their
ordering controlled within the elements themselves an empty stubbed
in nested stack has been added so that we don't break that
implementation.
Change-Id: I778b87a17d5e6824233fdf9957c76549c36b3f78
|
Dan Prince
Steven Hardy
Steve Baker
Jiri Stransky
Giulio Fidente