| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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>
|
|
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
|
|
|
|
|
|
* 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
|
|
|
|
|
|
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
|
|
|
|
Exposing 'instance_name_template' to be set via
extra config for nuage-metadata-agent to function
Making nova::api::admin_tenant_name
available on the compute node which is
required by nuage-metadata-agent service
Making KeystonePublicApiVirtualIP available
on the compute node, which is used by the
nuage-metadata-agent to build the auth-url
Change-Id: I9736015e18cebf32b07940bf559063b60085f2fb
|
|
For testing purposes it is useful to have an easy way to get the given
IPs for the nodes; since currently one would have to ssh to one of the
ndoes and actually fetch the entries from there.
This will facilitate testing when the keystone endpoints have been
changed for hostnames, as done in this CR:
https://review.openstack.org/#/c/238887
Change-Id: I9b9362192d7e97690ba23d02e74389225913adb9
|
|
Some Nova hooks might require custom properties/metadata set for the
servers deployed in the overcloud, and this would enable us to inject
such information.
For FreeIPA (IdM) integration, there is effectively a Nova hook that
requires such data.
Currently this inserts metadata for all servers, but a subsequent CR
will introduce per-role metadata. However, that was not added to this
because it will require the usage of map_merge. which will block those
changes to be backported. However, this one is not a problem in that
sense.
Change-Id: I98b15406525eda8dff704360d443590260430ff0
|
|
|
|
|
|
|
|
|
|
Introduce configuration of the nodes' domains through a parameter.
Change-Id: Ie012f9f2a402b0333bebecb5b59565c26a654297
|
|
Added ExtraConfig templates and environment files
for Nuage Networks specific parameters.
Modified overcloud_compute.pp to conditionally
include nuage-metadata-agent.
Change-Id: I28106d8e26ad4d0158fe5e3a13f2f7b21e5c0b28
|
|
Added ExtraConfig templates and environment files for Nuage specific parameters.
Modified overcloud_compute.pp and overcloud_controller.pp to conditionally
include Nuage plugin and agents.
Change-Id: I95510c753b0a262c73566481f9e94279970f4a4f
|
|
|
|
* Fixed a comment to avoid ambiguity with concepts in Heat
* Removed default values from necessary parameters in the TLS
environment
* Simplified setting of the cert/key into a file.
Change-Id: I351778150a6fbf7affe1a0fddb1abb9869324dfc
|
|
Following parameters will be user configurable:
1. enable_dhcp_agent
2. enable_metadta_agent
3. enable_l3_agent
4. enable_ovs_agent
This change was made as the Nuage plugin does not require these
services to come up as a part of the installation.
Now, a user can explicitly disable these services using a heat
template.
Change-Id: Ic132ecbb2e81a3746f304da1cecdc66d0342db72
|
|
|
|
|
|
|
|
Provides a simple mechanism to verify the correct certificates
landed.
A quick and simple way to verify SSL certificates were generated for
a given key is by comparing the modulus of the two. By outputing
the key modulus and certificate modulus we offer a way to verify
that the right cert and key have been deployed without compromising
any of the secrets.
Change-Id: I882c9840719a09795ba8057a19b0b3985e036c3c
|
|
This commit enables the injection of a trust anchor or root
certificate into every node in the overcloud. This is in case that the
TLS certificates for the controllers are signed with a self-signed CA
or if the deployer would like to inject a relevant root certificate
for other purposes. In this case the other nodes might need to have
the root certificate in their trust chain in order to do proper
validation
Change-Id: Ia45180fe0bb979cf12d19f039dbfd22e26fb4856
|
|
Adds control over the load balancer deployment via template param.
Change-Id: I5625083ff323a87712a5fd3f9a64dd66d2838468
|
|
|
|
This is a first implementation of adding TLS termination to the load
balancer in the controllers. The implementation was made so that the
appropriate certificate/private key in PEM format is copied to the
appropriate controller(s) via a software deployment resource.
And the path is then referenced on the HAProxy configuration, but this
part was left commented out because we need to be able to configure the
keystone endpoints in order for this to work properly.
Change-Id: I0ba8e38d75a0c628d8132a66dc25a30fc5183c79
|
|
|
Dan Sneddon
Jenkins
Giulio Fidente
Juan Antonio Osorio Robles
Dan Prince
Steven Hardy
Emilien Macchi
Lokesh Jain
John Trowbridge
Rohit Pagedar
vinayrao123
Mark Chappell