Age | Commit message (Collapse) | Author | Files | Lines |
|
Enables support for configuring Cinder with a Dell
Storage Center iscsi storage backend.
This change adds all relevant parameters for:
- Dell Storage Center SC Series (iSCSI)
Change-Id: I3b1a4346f494139ab123c7dc1a62f81d03c9e728
|
|
|
|
|
|
Creates cron job running every 24 hours
for "cinder-manage db purge"
Partial-bug: rhbz#1249106
Change-Id: I9156e0bf1401eda49a7c9a2921dc3a8723af026d
Depends-On: I677f2ef3d9ca81fff0f672c8e34b6e4278674a96
|
|
|
|
- keeping enabled based on ceph node count being greater than 0
- adding enabled if ControllerEnableCephStorage is true
Intention here is to be able to run ceph without having dedicated
nodes for. Enabling Ceph alternativly from the ControllerEnableCeph
parameter allows ceph to be colocated on the controllers without
having to run any dedicated ceph nodes.
Change-Id: I71062d37226c679156380c0f4e194b51cb586bcf
Signed-off-by: Dan Radez <dradez@redhat.com>
|
|
The ExtraConfig resource was missing from the cinder
storage role. Adding it for consistency.
Change-Id: I05ad33c113af6f67ded7699976103508c47a3f1a
|
|
Based on observed timeouts during updates bump the stop and start
timeouts for pacemaker service resources (via op_params) to 200.
This is based on the reasoning that the full timeout may be as
long as two elapsed timeout intervals. After an initial timeout,
the sigterm that follows is then allowed another
DefaultTimeoutStopSec seconds. The 200s is produced by allowing
this 2xDefaultTimeoutStopSec (@90s for systemd) and some
scheduling delta. Many thanks to Michele Baldessari.
Closes-Bug: 1531204
Change-Id: If6b43982c958f63bc78ad997400bf1279c23df7e
|
|
Adds a TimeZone parameter for node types and the top level
stack. Defaults to UTC.
Change-Id: I98123d894ce429c34744233fe3e631cbdd7c12b5
Depends-On: Icf7c681f359e3e48b653ea4648db6a73b532d45e
|
|
Creates cron job running every twelve hours
for "nova-manage db archive_deleted_rows"
Partial-bug: rhbz#1249106
Depends-On: Ic674f4d39bc88f89abfeb0ce99a571c2534e57e4
Change-Id: I4740cc02aa9714f48798521fe9918ac3487db031
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deploy a TripleO overcloud with networking midonet. MidoNet is a
monolithic plugin and quite changes on the puppet manifest must be done.
Depends-On: I72f21036fda795b54312a7d39f04c30bbf16c41b
Depends-On: I6f1ac659297b8cf6671e11ad23284f8f543568b0
Depends-On: Icea9bd96e4c80a26b9e813d383f84099c736d7bf
Change-Id: I9692e2ef566ea37e0235a6059b1ae1ceeb9725ba
|
|
This change allows every overcloud node to optionally participate in
any of the isolated networks. The optional networks are not enabled
by default, but allow additional flexibility. Since the new networks
are not enabled by default, the standared deployment is unchanged.
This change was originally requested for OpenDaylight support.
There are several use cases for using non-standard networks.
For instance, one example might be adding the Internal API network
to the Ceph nodes, in order to use that network for administrative
functions. Another example would be adding the Storage Management
network to the compute nodes, in order to use it for backup. Without
this change, any deviation from the standard set of roles that use a
network is a custom change to the Heat templates, which makes
upgrades much more difficult.
Change-Id: Ia386c964aa0ef79e457821d8d96ebb8ac2847231
|
|
This change adds a system management network to all overcloud
nodes. The purpose of this network is for system administration,
for access to infrastructure services like DNS or NTP, or for
monitoring. This allows the management network to be placed on a
bond for redundancy, or for the system management network to be
an out-of-band network with no routing in or out. The management
network might also be configured as a default route instead of the
provisioning 'ctlplane' network.
This change does not enable the management network by default. An
environment file named network-management.yaml may be included to
enable the network and ports for each role. The included NIC config
templates have been updated with a block that may be uncommented
when the management network is enabled.
This change also contains some minor cleanup to the NIC templates,
particularly the multiple nic templates.
Change-Id: I0813a13f60a4f797be04b34258a2cffa9ea7e84f
|
|
This aligns the parameter default values from python-tripleoclient
with tripleo-heat-templates. This is in preparation for removing
all the defaults from the client, and maintaining them only in the
templates.
Change-Id: I7b635a250f1ecc170e18d8e434f0118c6fcbb942
Co-Authored-By: James Slagle <jslagle@redhat.com>
|
|
|
|
|
|
|
|
|
|
Without modification we cannot scale to more than 1000 networks.
Neutron will send this message to the user:
"Unable to create the network. No tenant network is available for
allocation."
Change-Id: I5ecbc66a0b6aaa5edbe2669eed9caadfb0691511
|
|
|
|
|
|
Wires the following as arrays to the neutron module:
- mechanism_drivers
- flat_networks
- tenant_network_types
- tunnel_types
- bridge_mappings
Also updates the template version to use a Liberty feature which
allows serialization of comma_delimited_list into JSON.
Tidies up the manifests by removing the class declarations since
config is passed by the puppet/controller+compute hiera mapped_data.
Change-Id: Ie9f85fb827099f897ef750e267bc3ed3a864fe59
Co-Authored-By: Steven Hardy <shardy@redhat.com>
|
|
This change adds a new *_from_pool.yaml meant to return an IP from
a list instead of allocating a Neutron port, useful to pick an IP
from a pre-defined list and making it possible to configure, for
example an external balancer in advance (or dns), with the future
IPs of the controller nodes.
The list of IPs is provided via parameter_defaults (in the
ControllerIPs struct) using ControllerIPs param.
Also some additional VipPort types are created for the *VirtualIP
resources. The VIPs were previously created using the same port
resource used by the nodes, but when deploying with an external
balancer we want the VIP resource to be nooped instead.
Change-Id: Id3d4f12235501ae77200430a2dc022f378dce336
|
|
|
|
|
|
Change-Id: I72a79d8200adee8258033e8da370051bbfd1986b
|
|
|
|
Per Swift upstream commit: 7035639dfd239b52d4ed46aae50f78d16ec8cbfe
Swift's ringbuilder now validates that the number of devices is greater
than or equal to the replicas.
Change-Id: I56eaa9ddda138e87f7615d3bde797b568fa5e302
Related-bug: #1525356
|
|
|
|
This enables pacemaker maintenantce mode when running Puppet on stack
update. Puppet can try to restart some overcloud services, which
pacemaker tries to prevent, and this can result in a failed Puppet run.
At the end of the puppet run, certain pacemaker resources are restarted
in an additional SoftwareDeployment to make sure that any config changes
have been fully applied. This is only done on stack updates (when
UpdateIdentifier is set to something), because the assumption is that on
stack create services already come up with the correct config.
(Change I9556085424fa3008d7f596578b58e7c33a336f75 has been squashed into
this one.)
Change-Id: I4d40358c511fc1f95b78a859e943082aaea17899
Co-Authored-By: Jiri Stransky <jistr@redhat.com>
Co-Authored-By: James Slagle <jslagle@redhat.com>
|
|
This change adds a SoftwareConfigTransport parameter to role templates
so that the transport can be changed via a parameter_defaults entry.
This change will have no effect on an existing overcloud as the current
default POLL_SERVER_CFN is now explicit in the parameter default.
Change-Id: I5c2a2d2170714093c5757282cba12ac65f8738a4
|
|
neutron-server-start-wait-stop is a dangerous Exec that is exposed to
race conditions, because it does not have "onlyif" or "unless"
statements.
That means during a deployment, this exec can be run in the wrong order
during Step 5 and/or 6, while it was supposed to be run at Step 4 only.
If that happens, the exec will fail because puppet tries to start
neutron-server while Pacemaker already started the resource. So in that
case, systemd would returns 1 to Puppet which would return 6 to the
overcloud deployment and the deployment would fail to finish correctly.
This patch aims to prevent from this scenario by making sure we run the
exec only during the step 4.
Also, in order to secure it a bit more, we add 'unless' statement to
this exec, so we would make sure the Puppet run would be idempotent and
the Exec would run one successful time only.
https://bugzilla.redhat.com/show_bug.cgi?id=1290582
Change-Id: I42813c5cff6c525c15c9c24baad4e355f88af672
|
|
The parameters have nothing to do with EC2 keypairs, they are used to
specify Nova SSH key pairs.
Change-Id: Ia8d37cb5c443812d02133747cb54fcaf0110d091
|
|
There are two reasons the name property should always be set for deployment
resources:
- The name often shows up in logs, files and API calls, the default
derived name is long and unhelpful
- Sorting by name determines the merge order of os-apply-config, and the
execution order of puppet/shell scripts (note this is different to
resource dependency order) so leaving the default name results in an
undetermined order which could lead to unpredictable deployment of
configs
This change simply sets the name to the resource name, but a future change
should prepend each name with a run-parts style 2 digit prefix so that the
order is explicitly stated. Documentation for extraconfig needs to clearly
state what prefix is needed to override which merge/execution order.
For existing overcloud stacks, heat currently replaces deployment resources
when the name changes, so this change
Depends-On: I95037191915ccd32b2efb72203b146897a4edbc9
Change-Id: Ic4bcd56aa65b981275c3d4214588bfc4de63b3b0
|
|
All of our sensitive parameters are defaulted to easily predictable
values, which is very bad from a security perspective because we don't
force clients to make sane choices thus risk deploying with the
predictable default values. tripleoclient supports generating random
values for all of these, so remove the defaults, for non-tripleoclient
usage we can create a developer-only environment with defaults.
Related-Bug: #1516027
Change-Id: Ia0cf3b7e2de1aa42cf179cba195fb7770a1fc21c
Depends-On: Ifb34b43fdedc55ad220df358c3ccc31e3c2e7c14
|
|
|
|
|
|
* For each OpenStack service, create a new parameter to change worker
number (default to 0 to keep default behavior)
* Use the parameter in Puppet configuration (Hiera) to configure the
services with the number of workers defined by the parameter.
Change-Id: Ic147bc9225aab48e94243a94a2189467829b8d55
|
|
This adds a parameter for each role, where optional scheduler hints
may be passed to nova. One potential use-case for this is using
the ComputeCapabilities to pin deployment to a specific node (not
just a specific role/profile mapping to a pool of nodes like we
have currently documented in the ahc-match docs).
This could work as follows:
1. Tag a specific node as "node:controller-0" in Ironic:
ironic node-update <id> replace properties/capabilities='node:controller-0,boot_option:local'
2. Create a heat environment file which uses %index%
parameters:
ControllerSchedulerHints:
'capabilities:node': 'controller-%index%'
Change-Id: I79251dde719b4bb5c3b0cce90d0c9d1581ae66f2
|
|
If there is a value for the certificate path (which should only happen
if the environment for enabling TLS is used) then the loadbalancer will
detect it and configure it's front ends correctly. On the other hand
a proper override for the example environment was given, since this
will be needed because we want to pass the hosts and protocols
correctly so the tripleoclient will catch it and pass it to
os-cloud-config
Change-Id: Ifba51495f0c99398291cfd29d10c04ec33b8fc34
Depends-On: Ie2428093b270ab8bc19fcb2130bb16a41ca0ce09
|
|
|
|
|
|
Added a parameter to Nuage ExtraConfig template for setting
use_forwarded_for value required by Nuage metadata agent
Change-Id: I02c15311272126c5e530f118fbfb4a8f6e11a620
|
|
The Ceilometer alarm service is no longer available
in Mitaka. It is replaced by Aodh.
Aodh support is added in a follow-up to this patch.
Partial-Bug: 1521922
Change-Id: I5babaab7029eaaccf3cc6f194b6c062fd62372cf
Backport: none
|