|Age||Commit message (Collapse)||Author||Files||Lines|
For the TLS everywhere job, there are some apache vhosts set up that
serve as TLS proxies. These need to be started at the same time as the
rest of the apache vhosts too.
The step is typically set with the hieradata setting an integer value:
However it would be useful for the value to be a string so that
substitutions are possible, for example:
This change ensures the step parameter defaults to an integer by
This change was made by manually removing the undef defaults from
fluentd.pp, uchiwa.pp, and sensu.pp then bulk updating with:
find ./ -type f -print0 |xargs -0 sed -i "s/= hiera('step')/= Integer(hiera('step'))/"
This is now the job of the certmonger_user profile. So these bits are
not needed anymore in the service profiles.
Since the commit this depends on sets it up via hieradata, the
conditionals here are no longer needed.
This uses the tls_proxy resource added in a previous commit  in
front of the neutron server when internal TLS is enabled. Right
now values are passed quite manually, but a subsequent commit will use
t-h-t to pass the appropriate hieradata, and then we'll be able to
clean it up from here.
Note that the proxy is only deployed when internal TLS is enabled.
This class was being included in the same way in two different branches
of the code which could be joined in the initial branch (or if
This is currently calculated in t-h-t but has a hard-coded reference
to the ControllerCount which is incompatible with custom-roles.
So instead calculate the setting based on the number of neutron API
services running (on any role, not just Controller), combined with
whether DVR is enabled (equivalent to current t-h-t logic).
To avoid breaking the NeutronL3HA parameter in t-h-t we maintain an
optional parameter to override the calculated value.
This patch moves the various DB syncs into the MySQL role.
Database creation needs to occur on the MySQL server to
avoid permission issues.
This patch also moves database creation to step 2 so we can
guarantee that all per-service databases exist at this time.
This avoids complex ordering needed during step 3 where
services, on different hosts, can run their own db sync's
in a distributed fashion.
In the Next Generation HA architecture a number of active/active services
will be run via systemd. In order for this to work we need to make sure that
the sync_db operation only takes place on the bootstrap node, just like it is
done today for the pacemaker profiles.
We do this by removing sync_db as a parameter and instead set it to true
or false depending if the hostname matches the bootstrap_node as it is done
today in the pacemaker role.
Note that we call hiera('bootstrap_nodeid', undef) because if a profile
is included on a non controller node that variable will be undefined.
The following testing was done:
- HA puppet-pacemaker.yaml scenario with three computes
- NonHA with one controller
- NonHA with three controllers
Implements: blueprint ha-lightweight-architecture
We perform the Galera setup in step 2 so there is no guarantee that the
database will be available in that same step .
We used to implement a dependency in puppet using the 'galera-ready'
resource (clustercheck) but this is not possible with roles because we
also don't have any guarantee about clustercheck being installed on the
Because of the above all services must create/sync their databases
in a later step. This patch fixes Nova API and Neutron Server, the other
services use step 3 already.
This patch brings the neutron profiles and the
associated steps in line with what already happens in
-we want to create the db $step >= 2 and $sync_db
-we want to make sure plugin.ini exists before the neutron dbsync
-we want to make sure the db sync runs before neutron::server starts
when using pacemaker
-split the neutron server profiles. They are quite different across
pacemaker and base.
These can be controlled via the specific Pacemaker role template.
Implements: blueprint refactor-puppet-manifests
Add neutron profiles for both pacemaker and non-ha.
HA profiles are designed such that they include the base
profiles, disabling features as needed, while the base
profile can be used independently.
Co-Authored-By: Dan Prince <firstname.lastname@example.org>