| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
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 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
|
|
|
|
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
|
|
The parameters have nothing to do with EC2 keypairs, they are used to
specify Nova SSH key pairs.
Change-Id: Ia8d37cb5c443812d02133747cb54fcaf0110d091
|
|
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
|
|
|
|
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
|
|
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 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
|
|
We don't necessarily want the network configuration to be reapplied
with every template update so we add a param to configure on which
action the NetworkDeployment resource should be executed.
Change-Id: I0e86318eb5521e540cc567ce9d77e1060086d48b
Co-Authored-By: Dan Sneddon <dsneddon@redhat.com>
Co-Authored-By: James Slagle <jslagle@redhat.com>
Co-Authored-By: Jiri Stransky <jstransk@redhat.com>
Co-Authored-By: Steven Hardy <shardy@redhat.com>
|
|
Consume puppet-tripleo to create/manage IPtables from Heat templates.
This review put in place the logic to enable and setup firewall rules.
A known set of rules are applied. More to come.
Change-Id: Ib79c23fb27fe3fc03bf223e6922d896cb33dad22
Co-Authored-By: Yanis Guenane <yguenane@redhat.com>
Depends-On: I144c60db2a568a94dce5b51257f1d10980173325
|
|
|
|
* Add NovaApiVirtualIP string parameter.
* Compute nova_url and nova_admin_auth_url parameters.
* Configure in Hiera neutron::server::notifications::* parameters.
* non-ha: include ::neutron::server::notifications
* ha: include ::neutron::server::notifications and create orchestration
* Set vif_plugging_is_fatal to True so we actually fail if Neutron is not
able to create the VIF during Nova server creation workflow.
Depends-On: I21dc10396e92906eab4651c318aa2ee62a8e03c7
Change-Id: I02e41f87404e0030d488476680af2f6d45af94ff
|
|
* Use the parameter in Puppet configuration (Hiera) to configure neutron
BZ-1273303
Change-Id: Ic5a7a1f13fd2bc800cadc3a78b1daadbc0394787
Signed-off-by: Cyril Lopez <cylopez@redhat.com>
|
|
|
|
This change adds support for enabling/disabling L2 population in
Neutron agents. It currently defaults to false.
Change-Id: I3dd19feb4acb1046bc560b35e5a7a111364ea0d7
|
|
|
|
|
|
|
|
Because many of the service endpoints URLs use the same patterns for
generating the URLs it makes sense to use the same templates to reduce
the copy and paste.
In the process also adds support for explicitly specifying hostnames
for use in the endpoints. Note: DNS must be pre-configured. The
Heat templates do not directly configure DNS.
Change-Id: Ie3270909beca3d63f2d7e4bcb04c559380ddc54d
Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
|
|
Currently rabbit username and password are defaulted and attempting
to use anything else would result in a failure during deployment.
Change-Id: I8a2e240a19f915309eee45ea3c3368d131af6c1b
Related: rhbz#1261303
|
|
This reverts commit 86d6c1ddc76bad423194e789ffb5474e4e12960e.
This likely has an impact on upgrades, and since we don't
have an upgrade CI job yet I'm concerned that we may have
just broken ourselves. I would prefer to wait to merge this
until the CI job is in place.
Change-Id: Ib2366cb4b40471a28122f6e9955da9bdb31a53fb
|
Jenkins
Jaume Devesa
Dan Sneddon
Giulio Fidente
Steve Baker
Steven Hardy
Emilien Macchi
Juan Antonio Osorio Robles
Rohit Pagedar
Lokesh Jain
vinayrao123
Mark Chappell
Cyril Lopez
Brent Eagles
Mike Burns
Ben Nemec