Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
This commit aims to support the creation of the galera cluster via
Pacemaker. With this commit in, three use-cases will be supported.
* Non HA setup / Non Pacemaker setup : The deployment will take place
as it is currently the case in f20puppet-nonha. Nothing changes.
* Non HA setup / Pacemaker setup : Even though it is a non ha setup,
galera cluster via pacemaker will be deployed with a cluster nbr of 1.
* HA setup / Non Pacemaker setup : N/A
* HA setup / Pacemaker setup : It is assumed that HA setup will
always be with pacemaker. So in this situation pacemaker will deploy a
cluster of 3 galera master nodes.
Depends-On: I7aed9acec11486e0f4f67e4d522727476c767d83
Change-Id: If0c37a86fa8b5aa6d452129bccf7341a3a3ba667
|
|
Use some optimized configuration settings for RabbitMQ when
clustered. Data is ported from Astapor.
Change-Id: If54aff5654dbe75e68197588be12cb3995c77ec7
|
|
The puppet-pacemaker module realizes some abstraction for the
different service types in ::service already.
Change-Id: Icd897e18fda01b1bf4722a975c991e26341ac129
Closes-Bug: 1449988
|
|
This patch adds support for using the Heat resource registry
so that end users can enable pacemaker. Using this approach
allows us to isolate all of the pacemaker logic for the
controller in a single template rather than use conditionals
for every service that must support it.
Change-Id: Ibefb80d0d8f98404133e4c31cf078d729b64dac3
|
|
Adds a potential usage of the post-deploy hooks to register a server
with RHN or a satellite.
Note this requires some additional parameters, which can be specified in
environment_rhel_reg.yaml, and this must be passed into the call to heat
via another -e parameter. An alternative may be to have a global
extraconfig_env.yaml at the top level, which the scripts always pass, or
to use the global environment (/etc/heat/environment.d/default.yaml) on
the seed.
Co-Authored-By: James Slagle <jslagle@redhat.com>
Change-Id: Ia6fd270122cbc2e51beb672654e5e1ebd3bd2966
|
|
This patch adds a new abstraction for network creation
within Heat. This (optional) set of templates may be disabled
if you wish to create Neutron networks for the undercloud
via Heat templates... instead of using os-cloud-config
JSON to do so. Creating networks with Heat has the benefit
of being parameter driven so that users can quickly
enable networks using the resource registry and parameters.
There are 5 networks to start with which are roughly modeled
around networks an Overcloud user might want to use to isolate
their traffic. The intent is to make these opt-in and
configurable for end users.
The networks.yaml template can be used to create all of the
networks using parameters in the resource registry.
Change-Id: I5f2b3356378eb263d90d428cc83c7f5b141957e1
|
|
|
|
|
|
We need to stop using "unset" as the password for all databases. Ideally we
would add a "XxxxDSN" parameter (e.g. KeystoneDSN) but to remain consistent
with the overcloud for now we reuse the service passwords
Change-Id: I35c4fa3478eea92f81aa381fd2ab5fac5aae849f
|
|
|
|
This commit allows one to configure MongoDB as a pacemaker resource when
EnablePacemaker is set to true
Change-Id: Iedfba3eb851442d0ca3b8c0a7163a63285ab6071
|
|
|
|
This patch adds support for a new GlanceBackend setting
which can be set to one of swift, rbd, or file to control
which Glance backend is configured for use by default.
Change-Id: Id6a3fbc3477e85e8e2446e3dc13d424f9535d0ff
|
|
Could be used to e.g. make changes to the puppet modules on the fly
without the need to rebuild images. Documented in the template
description.
Change-Id: I6a1fef20d4f4afa4bedac5ea520949697793f0ed
|
|
This reverts commit 7313930c22b9f18d67e630de084ffcc6fad5ebe7.
Seeing errors when trying to create the keystone admin
role with packages. (ImportError: No module named os_client_config)
Change-Id: I78796598ccb8d2ffd6bfca85dce7d18dc0fd768e
Related-bug: #1450786
|
|
We need to stop using "unset" as the password for all databases. Ideally we
would add a "XxxxDSN" parameter (e.g. KeystoneDSN) but this wont work because
we don't know the VirtualIP to pass in.
Until we can come up with a better solution we should at least get rid of
the "unset" passwords.
Change-Id: I31f45912fa9c116ccdee010a2c5d91ea43a25671
Depends-On: I8ffe1eb481f615b0fbe127cd8107f1e70794c839
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ceilometer can use different backends. A recent change moved backend
support for Ceilometer from MySQL to MongoDB. This commit introduce a
greater flexibility, letting the deployer choose wheter MySQL or MongoDB
should be used as a backend for Ceilometer.
Change-Id: I0d5bfb0763cbcee234df7ab13574d866743d5ddf
|
|
|
|
|
|
Change-Id: I43a74c1db324144d33e96a94cb718db30e0fd243
|
|
The overcloud networking is managed by Neutron so we do not want
Nova to append its default domain part to hostnames.
Change-Id: Ic1edda158bf0579ed34455ad27db8ca444d26b85
|
|
Remove references to the .novalocal domain part in the hosts file.
Change-Id: Idf14907adaf2f35440b6f28870fe18434eadd1be
Depends-On: Iadfdf4120c4d1c9b6976321753957fd4eecf301c
|
|
|
|
Change-Id: I6bf5ada5a5298f4079594f3cc8b01ac0ef85876e
|
|
Change-Id: I45511569fda6b00ca35b1e590537a29271e56ce0
Depends-On: I98b9b3dbc48009ce255d964ac580e1a31f279f1e
|
|
Install OpenStack Dashboad (Horizon) on the Overcloud Controller with
Puppet.
Co-Authored-By: Giulio Fidente <gfidente@redhat.com>
Depends-On: If9b12d373e407be8be8428d77145f131eb450e88
Change-Id: I254e895014f58a51dade3dcdc63eabbb5dc458ac
|
|
This change allows a different network config for each family of hosts. For
instance, the controller may have a different network configuration than a
block storage node. This change adds a declaration for each family in the
overcloud-resource-registry.yaml & overcloud-resource-registry-puppet.yaml.
Change-Id: I083df7ebbb535f97d8ddec2ac0e06281c55986cd
|
|
Change-Id: I577dc98cdf3648c9eb77bd084ae18273a52b22f9
|
|
Adds optional hooks which can run operator defined additional config on
nodes after the application deployment has completed.
Change-Id: I3f99e648efad82ce2cd51e2d5168c716f0cee8fe
|
|
Currently all the OS::Nova::Server resource created don't pass any
user-data. It's possible to pass user-data as well as using heat
SoftwareConfig/SoftwareDeployment resources, and this can be useful
when you have simple "first boot" tasks which are possible either via
cloud-init, or via simple run-once scripts.
This enables passing such data by implementing a new provider resource
OS::TripleO::NodeUserData, which defaults to passing an empty mime
archive (thus it's a no-op). An example of non no-op usage is also
provided.
Change-Id: Id0caba69768630e3a10439ba1fc2547a609c0cfe
|
|
|
|
Pacemaker is a new feature and should probably be disabled
by default.
Change-Id: I840d08c9e0563aeb7128eb2b21929612b7a5bf7a
|
|
This patch adds support for configuring Keystone domain for Heat
via heat-keystone-setup-domain script. It should be reverted
as soon as Keystone v3 is fully functional.
Change-Id: I7397f49fac17c30262d02b70021d613aef5c6cad
|
|
Adds a new ControllerEnableSwiftStorage parameter that
can be used to enable/disable use of the contoller node
as a Swift storage node.
Change-Id: Ic54144f4a46a671818c2f12e419cfa619b0dc1f9
|
|
This patch adds a new ControllerEnableCephStorage option
which can be used to install and configure Ceph storage
(OSD) on the controller node.
The default is to have this disabled by default (this is
probably a more production like setting).
The motivation for this change is to help facilitate CI
jobs which actually use Ceph. Right now we have an issue
where once the Heat stack finishes Ceph is configured
and ready, but Cinder volume (required by our CI
devtest_overcloud.sh test) may or may not have had
enough time to recognize the amount of storage
on the remote Ceph storage nodes. Waiting another
periodic cycle for Cinder volume to recognize the
actual amount of storage on the remote OSD nodes
would work but there isn't a good way to do this
ATM. The right solution here is probably to
implement Heat breakpoints in our CI. As we haven't quite
landed that change, another option is to simply
make the controller node also be a Ceph storage node.
Since this runs as "step 2" within the controller
it ensures that the OSD will be available and thus
Cinder volume will register the correct amount of
storage on startup.
Enabling this feature also matches what we do with Swift
storage on the Controller (although we should provide
an option to actually disable this as well).
Change-Id: Ic47d028591edbaab83a52d7f38283d7805b63042
|
|
|
|
|
|
|
|
Depends-On: Ia1bbf53c674e34ba7c70249895b106ec0af3c249
Change-Id: Ifa9f579d26a3cba9f8705226984c7b987ae0ad1c
|
|
These appear in the Tuskar UI and CLI so are worth keeping
consistent with those of the controller/compute nodes
Change-Id: I7cdd3a67d6f190f43e279fad0c4bf5f409d1e161
|
|
Add support for Redis configuration on the overcloud controller role.
Change-Id: I917ff1e7c0abf9d76b9939a97978e858268deac2
Depends-On: I80a6c284af9eceb6b669a03c5d93256261523331
|
|
On Controller node, we also need to include ::glance if we want to have
common Glance bits (packaging included).
This is a Puppet best practice.
Change-Id: I967c06b2c78d8f3aa5fa984b518d34c813426a2e
|