Age | Commit message (Collapse) | Author | Files | Lines |
|
This change modifies the network isolation templates that allow for
fixed IP addresses on the controllers' IPs and VIPs, and makes them
compatible with IPv6 addresses.
The latest version of the patchset creates an from_service_v6.yaml
in order to properly handle service VIPs on IPv6 networks.
Note that since OVS is not currently compatible with IPv6 tunnel
endpoints, this patch does not yet enable IPv6 for the Tenant
network by default.
Change-Id: If881b000c6000ec13b54c0ee39f1c8940f079ae3
Co-Authored-By: Giulio Fidente <gfidente@redhat.com>
|
|
|
|
|
|
This just a revert to see if reverting this gets back to a normal CI run time.
This reverts commit f72aed85594f223b6f888e6d0af3c880ea581a66.
Change-Id: I04a0893f6cf69f547a4db26261005e580e1fc90b
|
|
Use of slaac does not permit stati assignment of IPs to a Neutron
port, so we default to dhcpv6-stateful instead.
Change-Id: Id7f104be60ae05785a3d0a33516d7875a4698ed1
|
|
This change adds Controller NIC configs for the sample NIC config
templates that are compatible with IPv6 on the External network.
These controller-v6.yaml templates include a default route for IPv6
on the External network, and a default route for IPv4 on the Control
Plane. The Heat parameters ExternalNetworkDefaultRoute and
ControlPlaneDefaultRoute are used to set these values.
Change-Id: Ifed8cb359eae1d9d623d3eb2fe40ea8a0d1d889a
|
|
This change adds a new set of network templates with IPv6 subnets
that can be used instead of the existing IPv4 networks. Each network
can use either the IPv4 or IPv6 template, and the Neutron subnet will
be created with the specified IP version.
The default addresses used for the IPv6 networks use the fd00::/8
prefix for the internal isolated networks (this range is reserved
for private use similar to 10.0.0.0/8), and 2001:db8:fd00:1000::/64
is used as an example default for the External network
(2001:db8::/32 are the documentation addresses [RFC3849]), but this
would ordinarily be a globally addressable subnet. These
parameters may be overridden in an environment file.
This change will require updates to the OpenStack Puppet
Modules to support IPv6 addresses in some of the hieradata values.
Many of the OPM modules already have IPv6 support to support IPv6
deployments in Packstack, but some OPM packages that apply only to
Instack/TripleO deployments need to be updated.
IPv6 addresses used in URLs need to be surrounded by brackets in
order to differentiate IP address from port number. This change
adds a new output to the network/ports resources for
ip_address_uri, which is an IP address with brackets in the case
of IPv6, and a raw IP address without brackets for IPv4 ports.
This change also updates some URLs which are constructed in Heat.
This has been tested and problems were found with Puppet not
accepting IPv6 addresses. This is addressed in the latest Puppet.
Additional changes were required to make this work with Ceph.
IPv6 tunnel endpoints with Open vSwitch are not yet supported
(although support is coming soon), so this review leaves the
Tenant network as an isolated IPv4 network for the time being.
Change-Id: Ie7a742bdf1db533edda2998a53d28528f80ef8e2
|
|
Id3d4f12235501ae77200430a2dc022f378dce336 added support for pre-allocated
IPs on the other overlay networks, but because the patch adding the
managment network (I0813a13f60a4f797be04b34258a2cffa9ea7e84f) was
under review around the same time, we missed adding the from_pool
capability to the ManagementNetwork.
Change-Id: If99f37634d5da7e7fb7cfc31232e926bd5ff074a
|
|
|
|
Ceilometer Alarm is deprecated in Liberty by Aodh.
This patch:
* manage Aodh Keystone resources
* deploy Aodh API under WSGI, Notifier, Listener and Evaluator
* manage new parameters to customize Aodh deployment
* uses ceilometer DB for the upgrade path
* pacemaker config
Depends-On: I9e34485285829884d9c954b804e3bdd5d6e31635
Depends-On: I891985da9248a88c6ce2df1dd186881f582605ee
Depends-On: Ied8ba5985f43a5c5b3be5b35a091aef6ed86572f
Co-Authored-By: Pradeep Kilambi <pkilambi@redhat.com>
Change-Id: I58d419173e80d2462accf7324c987c71420fd5f6
|
|
Nova v2.1 allows to use the same API as 2.0 but with microversions
support, which is the recommended way to discover the latest API
version supported in the cloud.
Change-Id: Id011de03d883001fd48dbbcfed53cb821607c7f3
|
|
|
|
Due to an incorrect rebase, d0dcb9401c868786df58f5801a431392b8e89df8
dropped the changes made in dd7602ad82100617126be26d80a6d3f67cb739ac to
add a vncproxy to the endpoint map. This change restores them.
Change-Id: Ifef7f955481405d5fe39ba48c8b1a79aa9c170f2
|
|
A stack is an extremely heavyweight abstraction in Heat. Particularly in
TripleO, every stack includes a copy of all the template and environment
data for all of the stacks in the tree, all of which must be stored anew
in the database.
The EndpointMap abstraction created no fewer than 30 nested stacks, none
of which contained any resources but which existed purely for the
purpose of abstracting out some intrinsic functions used to calculate
the endpoint URLs for the various services. This likely adds several GB
to the memory requirements of the undercloud, and can cause things to
slow to a crawl since all 30 nested stacks need to be queried whenever
we need data from any one of them.
This change eliminates the nested stacks and instead generates the
endpoint map statically. This can be done offline in less than 250ms,
allows the input data to be expressed in an even more human-readable
form, and reduces the runtime overhead of the endpoints map by a factor
of 31, all with no loss of functionality, compatibility or flexibility.
Since we don't run a setup script to generate the tarball, the
endpoint_map.yaml output is checked in to source control. The build
script offers a --check option that can be used to make sure that the
output file is up-to-date with the input data.
Change-Id: I2df8f5569d81c1bde417ff5b12b06b7f1e19c336
|
|
|
|
|
|
Our current nova-neutron configuration does not work with
the latest puppet-nova. In particular, this patch[1].
This commit adds keystone v3 endpoints to the map and gets the
nova::network::neutron configuration to use them.
[1] https://github.com/openstack/puppet-nova/commit/d09868a59c451932d67c66101b725182d7066a14
Change-Id: Ifb8c23c81c665c2732fa5cd757760668b06a449a
|
|
|
|
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
|
|
Right now our vncproxy settings are hard-coded to http and the
non-ssl port. This change adds a vncproxy entry to the endpoint
map and uses those values to configure the proxy correctly on
compute nodes. This is sufficient to get it working in my
environment with ssl enabled.
Change-Id: I9d69b088eef4700959b33c7e0eb44932949d7b71
|
|
|
|
Previously we used an interim workaround which required a 2 digit subnet
but now heat (as of liberty) has str_split, which was implemented for this
purpose.
Change-Id: I29bb5f407b717e26a09c8c661954ee07fff72d71
|
|
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
|