Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Adds new puppet specific services for Mistral
API and Mistral Engine.
This submission enables the mistral service by default in the
overcloud, a following submission will disable it and make it
optional by enabling it on demand based in an environment file.
Depends-On: Iae42ffa37c4c9b1e070b7c3753e04c45bb97703f
Depends-On: I942d419be951651e305d01460f394870c30a9878
Depends-On: I6cb2cbf4a2abf494668d24b8c36b0d525643f0af
Implements: blueprint composable-services-within-roles
Co-Authored-By: Carlos Camacho <ccamacho@redhat.com>
Change-Id: Id5ff9cb498b5a47af38413d211ff0ed6ccd0015b
|
|
Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
Depends-On: If2804b469eb3ee08f3f194c7dd3290d23a245a7a
Depends-On: I091ecfbcb2e38fe77203244ac7a597aedcb558fb
Change-Id: Iacc504fc4fa2d06893917024ce2340d3fb80b626
|
|
This makes sure that the Host settings for all deployments are finished
before starting the AllNodesDeployments which execute puppet.
Change-Id: Ibe604472255ce905ca2c1dca2a9b07a6f8f40e47
Related-bug: #1633565
|
|
This patch moves the hosts configuration into its own deployment.
It will continue to use os-apply-config as something that is
required early on in the bootstrapping (it needs to be
configured before puppet runs for example).
The motivation here is so we can refactor all-nodes-config.yaml to use a
new hiera hook that that avoids os-apply-config entirely.
Change-Id: Ib3e4380f205358b27d22a1102b663cf300b1ed86
Partial-bug: #1596373
|
|
|
|
Closes-Bug: #1631277
Change-Id: I126b3ed2afdf03ffabb7e57f8792b9f7ecc06a09
|
|
Otherwise there may be a race between updating the hiera
and running the UpdateWorkflow
Change-Id: I22cd893e0db3df6d39504fbd61d7d9024cebb1c5
Related-Bug: 1631297
|
|
|
|
in the great rebase following the JINJA ALL THE THINGS changes we lost
critical functionality in the fluentd client service. This review
restores the missing features.
Change-Id: I7c23f16f81e75f3da6a24587b2eb8385b3e920a4
Closes-bug: 1630692
|
|
Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
Depends-On: Ic6fec1057439ed9122d44ef294be890d3ff8a8ee
Change-Id: I754c4a41d8a294a4c7c18bd282ae014efd4b9b16
Closes-Bug: #1628521
|
|
These hard-coded references to the Controller role mean that
things won't work if the keystone service is moved to any other
role, so we need to generate the lists dynamically based on the
enabled services for each role.
Change-Id: I5f1250a8a1a38cb3909feeb7d4c1000fd0fabd14
Closes-Bug: #1629096
|
|
As noted in the bug, predictable placement is broken right now
because the %index% in the scheduler hint isn't being interpolated.
This is because the parameter was moved from overcloud.yaml to the
service-specific files, which doesn't provide the index value.
Because the Compute role's parameter is named NovaCompute... we also
have to include some backwards compatibility logic to handle the
mismatch.
Change-Id: Ibee2949fe4c6c707203d7250e2ce169c769b1dcd
Closes-Bug: 1627858
|
|
|
|
This patch moves the keystone::auth settings for all
services into the new service_config_settings section. This
is important because we execute the keystone commands via
puppet only on the role containing the keystone service
and without these settings it will fail.
Note that yaql merging/filtering is used here to ensure that
service_config_settings is optional in service templates,
and also that we'll only deploy hieradata for a given
service on a node running the service (the key in
the service_config_settings map must match the service_name
in the service template for this to work).
e.g the following will result in only deploying keystone: 123
in hiera on the role running the "keystone" service,
regardless of which service template defines it.
service_config_settings:
keystone:
keystone: 123
Co-Authored-By: Steven Hardy <shardy@redhat.com>
Change-Id: I0c2fce037a1a38772f998d582a816b4b703f8265
Closes-bug: 1620829
|
|
This was missed during custom-roles work, and will mean deployments
break if any of the existing roles are removed from roles_data.yaml
Change-Id: Ia737b48a0dd272f8d706b7458764201fa47cb0bb
Closes-Bug: #1625755
|
|
The previous logic left out the default Count completely when it was
zero, which breaks nested validation and it's likely similar problems
would exist with the other optional defaults, so rework it so the
defaulting happens in the jinja2 logic, and document the interfaces
better in roles_data.yaml
Change-Id: I7f2eb4a3a0b43c5d2cd0d001ed3c73f783c95c74
Closes-Bug: #1625760
|
|
|
|
This implements support for installing fluentd agents as a composable
service on the overcloud.
Depends-On: I2e1abe4d8c8359e56ff626255ee50c9cacca1940
Implements: tripleo-opstools-centralized-logging
Change-Id: I23b0e23881b742158fcfb6b8c145a3211d45086e
|
|
This adjusts the interface to OS::TripleO::AllNodesExtraConfig so
it supports custom/composable/optional roles.
Note this does break backwards compatibility, and I can't see any way
to avoid that. I've converted the in-tree templates, and we'll have
to document carefully and or provide a script (or automated conversion
via mistral perhaps?) to allow folks to easily adjust any out of tree
templates to the new format.
Basically you just have to:
1. Remove all the *_servers parameters, replace with one "servers"
json parameter
2. Replace references to e.g "controller_servers" with "servers, Controller"
which does a path-based lookup into the json map provided by overcloud.yaml
Change-Id: I5eebf853646b2f6300d6b542fcd4f43e82d3b413
Partially-Implements: blueprint custom-roles
|
|
We need to remove the hard-coded roles from overcloud.j2.yaml
as now it's valid to e.g remove BlockStorage completely.
The previous behavior for the per-role upgrade scripts is maintained
but we'll need to rework this for newton->ocata upgrades where we
can no longer be sure the servers mapping will contain all roles.
Change-Id: I25e6c84757e3c00fba2aae834cd8206c62e44acf
Partially-Implements: blueprint custom-roles
|
|
Refactor so the post-deploy steps recently moved into
puppet/post.yaml are generated by jinja2 instead of hard-coded
Change-Id: I488e46aaa449c95571bd3d1de9513c3d0730baf3
Partially-Implements: blueprint custom-roles
|
|
|
|
|
|
To support custom roles we need to generate these lists of role
specific data.
Change-Id: Ide97cd57d1c07f7f7ff260ff7a6bbe2b71753bd0
Partially-Implements: blueprint custom-roles
|
|
This moves the now nearly identical group resources inside the loop
there's a FIXME related to some deprecated compute parameters we'll
need to work around.
Change-Id: Iddd63c42754867125e65e7721ab9d9f46f4d6afb
Partially-Implements: blueprint custom-roles
|
|
Change-Id: I8fc855833e8c602e94d0e8b330a713de1c98f901
|
|
This patch add support for deploying Ceph RGW.
Co-Authored-By: Giulio Fidente <gfidente@redhat.com>
Change-Id: I88c8659a36c2435834e8646c75880b0adc52e964
|
|
These are identical for all roles, so move them into the per-role
loop
Partially-Implements: blueprint custom-roles
Change-Id: Id85b830a0e225912a3ea8c8b17a11fc424f68bb0
|
|
These are identical for all roles, so move them into the per-role
loop
Partially-Implements: blueprint custom-roles
Change-Id: I0a9918d5a2e9a73fe3ac68a96bdee02e95799bc1
|
|
The first step of generating the Service chain resources via j2,
we'll then incrementally convert other resources to be created
in a similar way.
Partially-Implements: blueprint custom-roles
Depends-On: I81239991f36ed5f6453184bf9cffe930832cb68b
Change-Id: Iafa9b2afddf18a5a9833ec472a552fb256338b38
|