Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
This patch bumps the HOT version for the overcloud
to Kilo 2015-04-30. We should have already done this
since we are making use of OS::stack_id (a kilo feature)
in some of the nested stacks. Also, this will give us access to
the new repeat function as well.
Change-Id: Ic534e5aeb03bd53296dc4d98c2ac5971464d7fe4
|
|
The exec timeout/attempts is configured so that it is
left running for up to 30mins if the command runs but is
unsuccessfull and up to 2h if the command times out.
Change-Id: I4b6b77e878017bf92d7c59c868d393e74405a355
|
|
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
|
|
|
|
|
|
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
|
|
|
|
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
|
|
Remove references to the .novalocal domain part in the hosts file.
Change-Id: Idf14907adaf2f35440b6f28870fe18434eadd1be
Depends-On: Iadfdf4120c4d1c9b6976321753957fd4eecf301c
|
|
|
|
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
|
|
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
|
|
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
|
|
Change-Id: Ia2e4eae619ca95c0f417f713676732eb4f01304b
Depends-On: I9563eec0a2266deb2ebef2e3d76ae89d39b2be29
|
|
Despite passing bind-address for MariaDB in overcloud_controller.pp
correctly, it was always trying to bind on 0.0.0.0. The problem is
caused by Galera's config file (we install Galera into the image even
though we don't use it yet). Galera's default config file contains
override of the bind-address value to 0.0.0.0, and the setting from
galera.cnf took precendence over what was in server.cnf.
The mariadb-galera-server package assumes that the main config happens
in galera.cnf and it ships an almost empty server.cnf. We now have an
EnableGalera param, when it's set to true the mysql module will manage
galera.cnf instead of server.cnf, overriding the default values from
galera.cnf and fixing the issue.
Change-Id: I7c2fd41d41dcf5eb4ee8b1dbd74d60cc2cabeed9
Closes-Bug: #1442256
|
|
It's very confusing for them to be different, especially in the case of
comparing Tuskar vs non-Tuskar deployments where the parameters are read
from different files.
Note: NeutronPhysicalBridge is named differently in the overcloud
template (HypervisorNeutronPhysicalBridge). This is the only parameter
checked that isn't named exactly the same, hopefully there aren't any
others.
(Checked controller, compute, ceph, cinder, and swift for both puppet
and non-puppet templates)
Change-Id: I48ce1eb40d2d080c589ce619c50eddff17efe882
|
|
This commit aims to add support for Ceph as a cinder and a nova backend.
* Allows creation of Ceph pools from heat (Default: volumes, vms)
* Creates the proper ceph user and inject the keys
* Applies the proper configuration in cinder.conf and nova.conf
* Enable the backend out of the box
Co-Authored-By: Giulio Fidente <gfidente@redhat.com>
Change-Id: Ic17d7a665de81a8bab5e34035abe90eda4bc889f
|
|
|
|
Currently we have a hard-coded default for auth_encryption_key,
which isn't ideal as it's used as a salt for the DB encryption.
Instead, reference an OS::Heat::RandomString resource so we create
a random key for each deployment.
Change-Id: Ic76b89db17603c114d98d28c01f75cc287fb2e90
|
|
Currently Cinder iscsi backend is configured within the DEFAULT section.
Since we aim to support multibackend, this commit puts the iscsi backend
in its own section and enable it by default configuring it properly.
Also adds a parameter which can be used to disable the default backend.
Co-Authored-By: Giulio Fidente <gfidente@redhat.com>
Change-Id: I05fb44b59829c0afa8a6588956a48320f2f65159
|
|
Our existing default (replicas == 1) means that no data
(or copies) is being replicated in a multi-node Swift
environment. This seems like a bad production default
setting and could easily slip by if not set.
Setting it to 3 shouldn't hurt anything and seems to follow
suit with what several production installers (based around Puppet)
actually use. If using an installation with less than 3 swift
nodes I believe swift will do its best, and still work fine.
FWIW I noticed this when testing a multi-node Puppet swift
installation and was surprised when I didn't see any *data
files getting replicated across the storage cluster.
Change-Id: I44bdfff7aae6bdf845b79ca1f8f450c22113caed
|
|
In I228216a0b55ff2d384b281d9ad2a61b93d58dab9 we split
out just the Controller software config in an effort
to provide hooks for alternate implementations (puppet).
This sort of worked but caused quirky ordering issues
with signal handling. It also causes problems for Tuskar
which would prefer to think of these nested stacks and
not have us split out just the software configs like this.
This patch moves all the controller related stuff for
our two implementations:
controller.yaml: is used by os-apply-config (uses the
tripleo-image-elements)
controller-puppet.yaml: uses stackforge puppet-* modules for
configuration
By duplicating the entire controller in this manner we make
it much easier to create dependencies and implement proper
signal handling. The only (temporary) downside is the duplication
of parameters most of which will eventually go away when we move towards
using the global parameters via Heat environment files instead.
Change-Id: Iaf3c889d7c8815f862308cd8e15ce1010059f5c6
|
|
|
|
This change will allow for the enablement of Neutron routers HA
via the new NeutronL3HA parameter.
Change-Id: Ia5f7c0b4e89159456482e840c50d166ec5f25d4c
Implements: blueprint tripleo-icehouse-ha-production-configuration
|
|
This was added in I36fece56bafa9fe9c4883b572687b3fc819eeae1
and is missing from overcloud-without-mergepy.
Change-Id: I5c2566cc77247574f8d687eaab8094de481a8c67
|
|
This was added in Icc5e431a7e2884b3ca3a255b6fd901619bc98460
and is missing from overcloud-without-mergepy.
Change-Id: I1273b646c04783712fd3f8baccafead11817689c
|
|
|
|
|
|
This example extends the controller software configuration
so that heat metadata is used to model the os-net-config
YAML (ultimately JSON) directly. The existing
os-net-config element already supports this format.
Configuring the physical network layer in this manner
would supplant the ever growing list of Heat parameters
that we have and is something that could be automatically
generated via tuskar.
The default is to use net-config-noop.yaml which
will pass no config metadata into the os-net-config
element which will essentially disable it in favor
of using parameters w/ init-neutron-ovs.
Change-Id: Ifba60454ee11222173a9762882e767a836a4545c
|
|
This is a step towards supporting pluggable software configurations
in the heat templates. By moving controller-config out of controller.yaml
we make it possible to define alternate implementations by
changing the OS::TripleO::ControllerConfig value in the
overcloud-resource-registry.yaml heat environment file.
Change-Id: I228216a0b55ff2d384b281d9ad2a61b93d58dab9
|
|
Trying to use overcloud-without-mergepy currently fails with
a validation error around MysqlClusterUniquePart. This
works around the issue by temporarily dropping the validation.
Change-Id: If93945a2c3396b07b592d08efb1f66e11d6194dd
Partial-bug: #1405446
|
|
|
|
|
|
|
|
This patch adds the missing HAProxy novncproxy parameters to
controller.yaml
These parameters were adding to overcloud-source.yaml
in I0c6a3d6a8fd10da71abbf568633b28bdb5e56aa2.
Change-Id: Icff2f17a301e5e95fa43549ec1566c0c0d5b5353
|
|
This patch adds the missing parameters to controller.yaml
These parameters were adding to overcloud-source.yaml
in I1581c091b996422fb1374ea4c024d0a88453e10b.
Change-Id: I3e4e0e1feb521dded2679fed508fa97e8dd27661
|
|
This patch adds the missing parameters to
overcloud-without-mergepy.yaml.
These parameters were adding to overcloud-source.yaml
in I422c65e7d941593083d52ad7fdf0dfd1d2fb3155. Due to
the concurrent review window they never made it
into the new overcloud-without-mergepy.yaml
implementation.
Change-Id: If54dc111aec852f906c9e7ac1bf56f9dcaf678ea
|
|
This patch adds the missing KeystoneSSLCertificate and
KeystoneSSLCertificateKey to overcloud-without-mergepy.yaml.
These parameters were adding to overcloud-source.yaml
in Icf46132230512a31b6dec3c07164c95b13dd8f73. Due to
the concurrent review window they never made it
into the new overcloud-without-mergepy.yaml
implementation.
Change-Id: I8b1155ca0a28392e5d5ade57d53bf810d8b5f053
|
|
This patch adds the missing RabbitClientUseSSL and
RabbitClientPort to overcloud-without-mergepy.yaml.
These parameters were adding to overcloud-source.yaml
in I7b7613cb60b9095ba5665c335c496fea4514391a. Due to
the concurrent review window they never made it
into the new overcloud-without-mergepy.yaml
implementation.
Change-Id: I182671b84d0a21d7018eb136003968f101384716
|
|
Now that we are using os-net-config we can make use of
the nic naming abstraction layer where the actual physical
nic name is mapped automatically.
This change removes all the eth0 references and replaces
them with nic1 which should make it more likely
that these default values would actually work on
some distributions.
It also removes the single instance of eth2 in the
undercloud-bm-nova-deploy.yaml template and replaces
it with nic1 as well. Underclouds aren't a special case
in this regard (I run my bare metal undercloud on em1)
so there is no good reason to default to the second nic.
Change-Id: I3ea92a502bc4b8789f74913f232ac8bc6b843008
|
|
the default maxconn is only 150, which maybe good for api services
but not enough for the rabbitmq session in a cluster as small as 15
nodes. so bump up the number to 1500 for rabbitmq to allow for 100
nodes. this number should be calculated based on the scale numbers
in the long run.
Closes-bug: #1386406
Change-Id: Ieb707b31022a6fc9ade32ed2a332b67bf4dc0311
|
|
With the push to using the new setup-flavors provided by
os-cloud-config, the default flavor will no longer be called
'baremetal', and Heat will always validate the default even if it
is overridden. To that end, remove the default flavor from every
flavor definition. Just to be certain, also add a custom_constraint
to every flavor definition that was missing it.
Change-Id: I24251e73be4e86738857f73b89499f592c4908de
|
|
|
|
If you don't have (or provide) the wrong image, KeyName,
or flavor, we fail at some later point (not always early,
depending on what's wrong).
Since Icehouse, Heat has had a "custom constraints" method
of dynamically validating parameter values, by comparing the
value provided with a list from the underlying service.
Despite the name, there's nothing "custom" about the constraints,
these ones are included in Heat by default (though they are pluggable,
which is where the name comes from..)
See the docs for more info:
http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#custom-constraint
Note, I've not considered network validation here, this could
possibly be added in a subsequent patch.
These constraints are evaluated via any of the following:
- heat template-validate -f <template>
- heat stack-preview <arguments given to create>
- heat stack-create <arguments, fails fast before creating anything>
- heat stack-update <arguments, fails fast before updating anything>
Change-Id: I3a6374ce5421575cdde893c62aa97c750a07acd8
|