| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
The commit daad3d4224f12d2c23c41a70cdf522e7c55536ba added a bunch of new
endpoints, but failed to use the new input data in calculating the
outputs: the GlanceRegistry ones use the Glance endpoints and the
Horizon one the Heat endpoint. This would cause anything querying these
endpoints from the endpoints map to get the wrong ports.
Change-Id: I8e1780b26e285187142be41b4f3aae3efe7eaaee
|
|
Define environments to create VLANs attached to a single physical nic as
'single-nic-vlans' does, but using linux_bridge instead of ovs_bridge
Change-Id: I8c6fe9ec7028178f783e7d9c0a1cc67a1517eb3d
|
|
|
|
Integration of OpenStack data processing service (sahara) with
TripleO.
- Deploys sahara in distributed mode (separate api and engine
processes on each controller node)
- Load balancing w/haproxy
- RabbitMQ/MySQL supported per current TripleO standard
- Minimal configurability at this time
Change-Id: I77a6a69ed5691e3b1ba34e9ebb4d88c80019642c
Partially-implements: blueprint sahara-integration
Depends-On: I0f0a1dc2eaa57d8226bad8cfb250110296ab9614
Depends-On: Ib84cc59667616ec94e7edce2715cbd7dd944f4ae
Depends-On: I9fe321fd4284f7bfd55bd2e69dcfe623ed6f8a2a
|
|
|
|
|
|
One of the interfaces was not indented at the same level as the
others in some of the templates.
Change-Id: Iabd835724848d754d5522968e1c8e3cf9f78e6c6
|
|
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>
|
|
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
|
|
|
|
|
|
The non-controller nodes in the network/config/multiple-nics
directory do not have a default route configured. This change
adds the default route to the non-controller nodes using the
ControlPlaneDefaultRoute parameter, which was already a part
of these templates.
Change-Id: Idaaeb2a539555ac14cc613b202c428108bc19a30
|
|
Change-Id: Id63c1bcfc34058eb7285698ba9bf86d1cf2025a6
|
|
Changes VipMap into a new NetVipMap resource which defaults to
being the same as the 'old' VipMap. An environment file can be
used to map NetVipMap instead to the net_vip_map_external.yaml
which allows for passing in explicit Virtual IP addresses.
It also ensures that references to the Virtual IPs are gathered
from the VipMap resource and allows for an empty ControlPlaneIP
parameter in the neutron port templates where it can be.
Co-Authored-By: Giulio Fidente <gfidente@redhat.com>
Change-Id: Ifad32e18f12b9997e3f89e4afe3ebc4c30e14a86
|
|
|
|
|
|
|
|
|
|
This change adds to the internal_api, storage, storage_mgmt and
tenant network ports the FixedIPs param and make them consume it
when passed.
Change-Id: Ica2bca9f573b206cc60c9d572224a8cc7b9b8aa4
|
|
|
|
|
|
The default balance-tcp is causing issues with deployments.
Defaulting to active-backup.
After ~ 100 guests (total) connectivity to each guest would become spotty
(simple pings would fail, then become successful.) In /var/log/messages
we saw :
"overcloud-controller-1 kernel: openvswitch: ovs-system: deferred action
limit reached, drop recirc action"
For more details, refer to this link:
http://openvswitch.org/pipermail/discuss/2015-October/019168.html
Change-Id: Ia0f2592a289e13472b98d97057cd516c5048fe59
|
|
We need to pass details of the Glance Registry and public Horizon
endpoints to the load balancers so add them to the EndpointMap
Change-Id: Ia6261223e7701734f47ce48471c86f690ba3dcd5
|
|
We expose all of the other parameters, so expose the IP too for
consistency
Change-Id: I5c31befde51e398318c7b8c744310212288ad892
|
|
CloudName is the DNS name for the public VIP this means we will likely
want it available for use in the endpoint hostnames, rather than people
needing to copy and paste the same hostname
Change-Id: Ic6d708b083244442195eee890de91bbc7e133ec2
|
|
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>
|
|
This change adds a set of network interface configurations for use
with network isolation. The multiple-nics templates includes one
separate NIC per network, and assumes that nic1 is used for the
provisioning network (ctlplane). Also included is an environment
file for including the multiple-nics configuration in a deployment.
This revision changes the ordering of the NICs. By doing that, it
is possible to wire up only a subset of the NICs for the storage
nodes, and it is possilbe to leave the External NIC only configured
on the controllers.
rdo: Updated this commit for static control plane configuration
Co-Authored-By: Rhys Oxenham <roxenham@redhat.com>
Change-Id: Ic878d1ed1a85b5705295d087a743570ca8213504
|
|
This patch adds a new optional DnsServers parameter
which can be used to provide a custom list of DNS
resolvers which will be configured in resolv.conf.
Change-Id: I2bb7259ebc09d786dc56da18694c862f802091b1
Depends-On: I9edecfdd4e1d0f39883b72be554cd92c5685881d
|
|
This patch updates all network configuration templates so that
we configure the ctlplane network interface with a static IP
instead of using DHCP.
The IP address used for the static IP is passed into each
nested stack network configuration template via the ControlPlaneIp
parameter.
Three new nested stack parameters called ControlPlaneSubnetCidr,
ControlPlaneDefaultRoute, and EC2MetadataIp have been added to help
configure the CIDR, default route, and EC2 metadata route on the ctlplane
statically. These parameters can be customized via the
parameter_defaults section in the heat environment.
A single new template called net-config-static-bridge.yaml has
been added to help migrate towards using the static
configuration templates when not using network isolation.
Depends-On: I257e1cba6dee16f73f75512d1284e1e3b9d4c831
Change-Id: Ib267e6dcf2d5ff77f7a82ee20a123965c2d07565
|
|
The latest Heat API is a bit more strict in validating
the datatypes for the OS::Neutron::Net value_specs.
This patch converts the default parameter types for
these from string to json.
Change-Id: Iaad6ee6417d3ae55c52ffe2f4e6ed79124161923
Closes-bug: #1493502
|
|
When using network isolation you might want to selective
move one of the services back to the default ctlplane network
by simply using the ServiceNetMap parameter. This patch
adds ctlplane to the output parameters for both
the net_ip_map and net_ip_list_map nested stacks so that
this is possible.
As part of this patch we also split out the NetIpSubnetMap
into its own unique nested stack so that the Heat input
parameters for this stack are more clearly named.
Change-Id: Iaa2dcaebeac896404e87ec0c635688b2a59a9e0f
|
|
This change removes a hardcoded value for the bond name in the NIC
config for the compute node in the bond-with-vlan NIC config
templates. When this hardcoded value of "br-bond" is used, then the
Neutron bridge mappings must be set to set to datacentre:br-bond in
order for VLAN mode networking to recognize the bridge. By using the
input value for bridge_name we will ensure that the controller and
compute nodes have the same bridge name (defaults to "br-ex"), and
that the defaults will work with VLAN mode.
Change-Id: I28654ab93e3c10a8597c8b877f3f2f6b3eca887c
|
|
This patch adds extra heat environments that can be used
to enable network isolation without using the external
network. Instead of a separate external network the ctlplane
will be used for all of the external/public traffic.
Change-Id: Ia542cee02121771d7d57ac701b62d7608e8d1855
|
|
This change adds a default setting for the OVS bond options to the
bond-with-vlans controller.yaml. This default will attempt to bring
up LACP bonding, but should that fail it will bring up the bond in
active/backup mode. This is a safe configuration if the switch is
not configured for bonding.
Change-Id: I91aad1e061ed1ecf26636e60da7a9a6e9cde50a5
|
|
This change brings PublicVirtualIP in line with the rest of the
VIPs in how it is created. This allows the network where
PublicVirtualIP is instantiated to be on cltplane when network
isolation is not used, and on the external network when network
isolation is used. This change removes the PublicVirtualNetwork
parameter, since it is no longer used. In order to continue to
support the PublicVirtualFixedIPs parameter, which is used to
provide a specific IP for the PublicVirtualIP, the FixedIP
parameter was added to cltplane_vip.yaml, vip.yaml, and
noop.yaml. The value of PublicVirtualIP is passed to FixedIP
in the VIP templates. This change also moves the default
network for keystone public api to the external net (which will
fallback to ctlplane if network isolation isn't used).
Change-Id: I3f5d35cbe55d3a148e95cf49dfbaad4874df960b
|
|
|
|
This change adds a parameter for ExternalInterfaceDefaultRoute
and uses that parameter to set the default route on the controller
nodes. This allows Horizon and the public APIs to be reachable from
routed networks outside the overcloud.
Co-Authored-By: Dan Prince <dprince@redhat.com>
Change-Id: I67a72767342237049f53f5085a6faf891fbf0c30
|
|
The bridge that is built on the bonds in the bond-with-vlans
example has an extraneous bridge on the storage and compute
templates, and an incorrect bridge on the controller template.
There is no reason to do anything on nic1, which is assumed to
be the provisioning interface, because it will be configured by
DHCP. Also, on the controller template we actually want br-ex
to contain the VLAN with the external network, rather than be
configured on the provisioning interface.
Change-Id: Ibe2343d5281f7b63a7b63b17d96d8442d0b96105
|
|
There are two files in network/ports which control the VIP
behavior called ctlplane_vip.yaml and vip.yaml. One of these
files was missing ControlPlaneNetwork, since it wasn't used
inside the template. Unfortunately, tuskar chokes on this,
even though Heat can build the stack just fine. This change
makes the vip.yaml and ctlplane_vip.yaml equivalent by adding
ControlPlaneNetwork to the vip.yaml template.
Change-Id: Ic20281e58a1130afe18d5aec505a3df199841fd5
|
|
|
|
|
|
|
|
The file network/external.yaml has a typo in the last commit. It
should have been a get_param instead of a get_resource. This
change fixes that line in that file.
Change-Id: Ibc0db0510e9b5dae3c4669a620c642357906cbc2
|
|
This patch adds parameters to configure the various
vlan IDs to all of the bond-with-vlans and single-nic-vlans
network config templates.
Change-Id: Ia6196735927777b73879e8086568f8a435597c6c
|
|
|
|
|
|
The redis_vip should come from a Neutron Port as its cidr depends
on the Neutron Network configuration. This change adds 2 new files
and modifies 1 in the network/ports directory:
- noop.yaml - Passes through the ctlplane Controller IP (modified)
- ctlplane_vip.yaml - Creates a new VIP on the control plane
- vip.yaml - Creates a VIP on the named network (for isolated nets)
Also, changes to overcloud-without-mergepy.yaml create the
Redis Virtual IP. The standard resource registry was modified to
use noop.yaml for the new Redis VIP. The Puppet resource registry
was modified to use ctlplane_vip.yaml by default, but can be made
to use vip.yaml when network isolation is used by using an
environment file. vip.yaml will place the VIP according to the
ServiceNetMap, which can also be overridden.
We use this new VIP port definition to assign a VIP to Redis,
but follow-up patches will assign VIPs to the rest of the
services in a similar fashion.
Co-Authored-By: Dan Sneddon <dsneddon@redhat.com>
Change-Id: I2cb44ea7a057c4064d0e1999702623618ee3390c
|
|
This patch adds new '<net name>AllocationPool' parameters
to all of the isolated network nested stacks so that users
can easily control the allocation ranges on these networks.
Change-Id: I44b564831446c62e3489a69d992e0fb1f642b085
|
Jenkins
Zane Bitter
Jaume Devesa
Ethan Gafford
Ben Nemec
Dan Sneddon
Giulio Fidente
Swapnil Kulkarni (coolsvap)
Dan Prince
Joe Talerico
Mark Chappell