| 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.
Change-Id: I15e67c7c04142cff01704e2590d3b2a6a949cc06
|
|
The step is typically set with the hieradata setting an integer value:
{"step": 1}
However it would be useful for the value to be a string so that
substitutions are possible, for example:
{"step": "%{::step}"}
This change ensures the step parameter defaults to an integer by
calling Integer(hiera('step'))
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'))/"
Change-Id: I8a47ca53a7dea8391103abcb8960a97036a6f5b3
|
|
This is now the job of the certmonger_user profile. So these bits are
not needed anymore in the service profiles.
Change-Id: Iaa3137d7d13d5e707f587d3905a5a32598c08800
Depends-On: Ibf58dfd7d783090e927de6629e487f968f7e05b6
|
|
Since the commit this depends on sets it up via hieradata, the
conditionals here are no longer needed.
bp tls-via-certmonger
Depends-On: I9252512dbf9cf2e3eec50c41bf10629d36070bbd
Change-Id: I37275e42763e103b81878b6af07c750a524c5697
|
|
This uses the tls_proxy resource added in a previous commit [1] 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.
[1] I82243fd3acfe4f23aab373116b78e1daf9d08467
bp tls-via-certmonger
Change-Id: I6dfbf49f45aef9f47e58b5c0dbedd2b4e239979e
|
|
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
statement).
Change-Id: Iee3c1663a2fe929b21a9c089d89b721600af66bd
|
|
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.
Change-Id: I01c50973eec8138ec61304f2982d5026142f267c
Partial-Bug: #1629187
|
|
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.
Change-Id: I05cc0afa9373429a3197c194c3e8f784ae96de5f
Partial-bug: #1620595
|
|
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
Fixes-Bug: 1600149
Co-Author: cmsj@tenshu.net
Change-Id: I04a7b9e3c18627ea512000a34357acb7f27d6e0e
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 [1].
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
same node.
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.
1. https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/README.rst
Change-Id: I22750ffb64afbe40b5560a6a0d0dabc5b8927d32
|
|
This patch brings the neutron profiles and the
associated steps in line with what already happens in
t-h-t. Specifically:
-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.
Change-Id: I52815f45a04bf3e39940b9cb116261730580a3e2
|
|
These can be controlled via the specific Pacemaker role template.
Depends-On: I91a4267f0fc230f63df3333747d28463c7ae55fe
Change-Id: I8ef7bb94e048b998712b3534ceb51a7d10d016e9
|
|
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 <dprince@redhat.com>
Change-Id: Ida781badbcd63bbcb481a2170638aefe262b717b
|
Juan Antonio Osorio Robles
Steve Baker
Steven Hardy
Dan Prince
Michele Baldessari
Giulio Fidente
Michael Chapman