| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Instead of using the Heat condition directly on the Deployment
resources, use it to set the action list to an empty list when the
server is blacklisted.
This has a couple advantages over the previous approach in that the
actual resources are not deleted and recreated when servers are added
and removed from the blacklist.
Recreating the resources can be problematic, as it would then force the
Deployments to re-run when a server is removed from the blacklist. That
is likely not always desirable, especially in the case of
NetworkDeloyment.
Additionally, you will still see the resources for a blacklisted server
in the stack, just with an empty set of actions. This has the benefit of
preserving the history of the previous time the Deployment was
triggered.
implements blueprint disable-deployments
Change-Id: I3d0263a6319ae4871b1ae11383ae838bd2540d36
|
|
Replace the multiple SoftwareDeployment resources with a common
playbook that runs on all roles, consuming the configuration data
written via the HostPrepAnsible tasks.
This hopefully simplifies things, and will enable re-running the
deploy steps for minor updates (we'll need some way to detect
a container should be replaced, but that will be done via a
follow-up patch).
Change-Id: I674a4d9d2c77d1f6fbdb0996f6c9321848e32662
|
|
Adds the ability to blacklist servers from all SoftwareDeployment
resources. The servers are specified in a new list parameter,
DeploymentServerBlacklist by the Heat assigned name
(overcloud-compute-0, etc).
implements blueprint disable-deployments
Change-Id: I46941e54a476c7cc8645cd1aff391c9c6c5434de
|
|
Master is now the development branch for pike
changing the release alias name.
Change-Id: I938e4a983e361aefcaa0bd9a4226c296c5823127
|
|
|
|
At scale, having the os-collect-config instances all check in at the
same time can cause performance problems. This change enables splay and
sets it to a default maximum random sleep of 30 seconds prior to the
os-collect-config polling.
Change-Id: Iab8b51f4e5fb4727b8aa7e081f5cbfcbf11f7fcb
Depends-On: I88f623c9e8db9ed4a186918206a63faec8f7f673
Closes-Bug: #1677314
|
|
|
|
|
|
Fetch the host public keys from each node, combine them all and write to the
system-wide ssh known hosts. The alternative of disabling host key
verification is vulnerable to a MITM attack.
Change-Id: Ib572b5910720b1991812256e68c975f7fbe2239c
|
|
The server resource type, OS::TripleO::Server can now be mapped per role
instead of globally. This allows users to mix baremetal
(OS::Nova::Server) and deployed-server (OS::Heat::DeployedServer) server
resources in the same deployment.
blueprint pluggable-server-type-per-role
Change-Id: Ib9e9abe2ba5103db221f0b485c46704b1e260dbf
|
|
Adds some missing name properties on deployment resources where they
were lacking. It's convention in TripleO that all the deployment
resources have the name property set.
Change-Id: I6464b099e725f8469163c887676d56d769e2f9b1
|
|
Prior to https://review.openstack.org/#/c/271450/ os-net-config was
applied via os-refresh-config directly, which meant that even though
UpdateDeployment and NetworkDeployment can be created concurrently,
we'd always do the os-net-config step first.
However now that we apply both steps via scripts (which are both handled
via the same heat-config hook) we should add an explicit dependency to
ensure the network is always fully configured before attempting to run
any update. This should avoid the risk of e.g running an update on
initial deployment before the network connectivity to access yum repos
is in place.
Change-Id: Idff7a95afe7b49b6384b1d0c78e76522fb1f8eb7
Related-Bug: #1666227
|
|
This adds the UpgradeInitCommonCommand for newton..ocata common
UpgradeInit commands. This comes before the ansible upgrade steps
so we need to do things like remove the old newton hieradata and
install the ansible-pacemaker module and ansible heat-agent plugin
This defaults to '' and is set in the major-upgrade-composable-steps
and unset in the major-upgrade-converge environment files.
Change-Id: I0c7a32194c0069b63a501a913c17907b47c9cc16
|
|
Found this today when rebasing the undercloud installer.
The puppet/role.role.j2.yaml Yaml has an invalid get_resource reference
that causes a cryptic heat stack failures.
Change-Id: Icfb7d73a1c4d02213b23a427605f2b0d5eaa984f
|
|
|
|
Heat now supports release name aliases, so we can replace
the inconsistent mix of date related versions with one consistent
version that aligns with the supported version of heat for this
t-h-t branch.
This should also help new users who sometimes copy/paste old templates
and discover intrinsic functions in the t-h-t docs don't work because
their template version is too old.
Change-Id: Ib415e7290fea27447460baa280291492df197e54
|
|
|
|
This enables the deployer to dynamically add nova metadata to the
servers based on the output of service profiles that implement the
metadata_settings key in the role_data output for the profiles.
One can set an implementation via the OS::TripleO::ServerMetadataHook
resource, which currently is set as OS::Heat::None. So, because of
the default implementation, if left untouched it actually does
nothing.
Currently, besides the list, which is metadata_settings, this hook also
takes the name of the node that it's setting the metadata for.
This is useful for nova vendordata plugins that can parse said metadata.
Change-Id: I8a937f711f0b90156fbb6c4632760435ef846474
|
|
|
|
Currently when the docker environments are invoked, every node has the
boot script run which replaces os-collect-config with the heat-agents
container. This should only be happening on Compute nodes currently,
and each role will be converted to heat-agents one at a time.
This change implements a role-specific NodeUserData resource and uses
that mechanism to run docker/firstboot/install_docker_agents.yaml only
on Compute nodes.
Change-Id: Id81811dbcaf0e661c3980aa25f3ca80db5ef0954
|
|
We can't run this during the upgrade steps, because there are things
which need to happen before any role configuration happens, e.g
installing the new hiera heat-config hook, which must be done before
e.g "ControllerDeployment" runs or the stack update hangs.
Partially-Implements: blueprint overcloud-upgrades-per-service
Change-Id: I365b57513590662c3f78a33dc625747f457c48c5
|
|
We could already pass metadata to the nova server instances (on
creation) via the ServerMetadata parameter, however, there was no
way of doing this per-role. This introduces that by adding a
{{role}}ServerMetadata parameter for each role. This parameter gets
merged with the ServerMetadata parameter and allows this
functionality.
Note that both default to {}, and so does the result of merging those
parameters with their default values. So nothing changes for the
default settings.
Change-Id: I334edcc51ce7ee82fc13b6cf4c0d74ccb7db099c
|
|
There are some requirements for early configuration that involves
e.g setting kernel parameters then rebooting. Currently this can
be done via cloud-init, e.g firstboot templates, but there's been
discussion around enabling a SoftwareDeployment approach instead.
The main advantage of doing it this way is there's an error path
if something goes wrong with the config (except triggering the
reboot as we have to use NO_SIGNAL for that).
Change-Id: Ia54ee654f755631b8062eb5c209a60c6f9161500
|
|
The inputs on the NetworkDeployment SoftwareDeployment resource were not
the same for generic roles as they were for the default roles
(role.role.js.yaml vs. controller-role.yaml).
This patch synchronizes the input between the 2 so that the interface is
the same for deployers.
Change-Id: Id14cf7ca219aee61f5b9d21171a5c41dea765f98
Implements: blueprint multinode-ci-os-net-config
|
|
There were several instances where the short-names/FQDNs where being
gotten in the same way in the role's templates. So this introduces a
mapping to get these values in order to reduce clutter.
Change-Id: Ie7df360bb69d56655f3e0fcbbf4d297db39b7a26
|
|
|
|
|
|
Currently, one can get the network-based FQDNs via a custom puppet
fact. This is currently unreliable, as it's based on the ::hostname
fact which we assume it's set correctly by nova. However, this is not
necessarily the case (for instance, if you use pre-deployed services
such as we do with the multinode-jobs). In these cases, the
::hostname fact will return something other than what we specified in
nova, and effectively breaks the configurations in we relly too much
on the network-based FQDN facts.
By using hiera instead, we avoid this issue as we set those values to
be exactly what we expect (as we set them in the OS::TripleO::Server
resource.
Change-Id: I6ce31237098f57bdc0adfd3c42feef0073c224fb
|
|
This patch optimizes how we deploy hiera by using a new
heat hook specifically designed to help compose hiera
within heat templates. As part of this change:
- we update all the 'hiera' software configurations to set the group to hiera
instead of os-apply-config.
- The new format uses JSON instead of YAML. The hook actually writes
out the hiera JSON directly so no conversion takes place. Arrays,
Strings, Booleans all stay in their native formats. As such we can avoid
having to do many of the awkward string and list conversions in t-h-t to
support the previous YAML formatting.
- The new hook prefers JSON over YAML so upgrading users will have the
new files prefered. (we will post a cleanup routine for the old files
soon but this isn't a new behavior, JSON is now simply prefered.)
- A lot of services required edits to account for default settings that
worked in YAML that no longer work correctly in the native JSON
format. In almost all these cases I think the resulting codes looks
cleaner and is more explicit with regards to what is getting
configured in hiera on the actual nodes.
Depends-On: I6a383b1ad4ec29458569763bd3f56fd3f2bd726b
Closes-bug: #1596373
Change-Id: Ibe7e2044e200e2c947223286fdf4fd5bcf98c2e1
|
|
This patch adds a local version of our template processing
routine so that developers can more quickly view the templates
that are actually getting generated. I've noticed multiple developers
now do a full deployment with 'overcloud deploy' only to download
the swift container with the generated templates. This simple task
avoids that step by allowing developers to generate it locally.
It also aims to preserve the ability to use t-h-t templates directly
with Heat (instead of going through Mistral) should users wish to do that.
The new undercloud heat installer requires the ability to generate
templates without requiring Mistral and Swift to do so.
Ideally the Mistral API workflow would use this same code
so perhaps in the future we might modify that routine to:
-download swift tarball containing the templates
-run this local routine that lives in t-h-t
-re-upload the tarball of templates to the swift container
Change-Id: Ie664c9c5f455b7320a58a26f35bc403355408d9b
|
|
Not having the default easily accessible is causing issues for the UI,
as it cannot guess at it and can accidentally overwrite the value with
an empty string (the expected default when unset). The default is
already helpfully spelled out in the doc string for each file, this
updates the parameter to match it.
Change-Id: Ic284f9904e8f1d01cc717d59a0759f679d94106d
Closes-Bug: #1643670
|
|
The update configuration is generated into ceph.yaml and into
{rolename}.yaml. We should ensure puppet hiera is looking for
these files.
Change-Id: I261d16bc365b3d19adc502385edcc509a53ffc2a
Closes-Bug: #1638346
Resolves: rhbz#1388977
|
|
This will wire up the per-network hostnames in the generic role.
Needs to land after https://review.openstack.org/#/c/378764
Partial-Bug: #1626976
Change-Id: I595f35cce03d9f416a1768aa5c349a1bb20b0e19
|
|
This submission creates a generic template
file to deploy custom roles.
Also adds a file to specify an exclusion role
list in order to avoid not to generate the
template for those roles.
Partial-Bug: #1626976
Depends-On: I6d7247bbb8702eb0ab9bdf133b5ab1c6e8349d98
Change-Id: I3e11c089023b793a5063d9e1714527a3fe2b7458
|
Jenkins
James Slagle
Steven Hardy
Carlos Camacho
Alex Schultz
Oliver Walsh
marios
Dan Prince
Juan Antonio Osorio Robles
Steve Baker
Julie Pichon
Lukas Bezdicka