Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
This patch adds support for configuring Keystone domain for Heat
via heat-keystone-setup-domain script. It should be reverted
as soon as Keystone v3 is fully functional.
This patch won't be fully functional without either python-keystoneclient
fix [1] or workaround [2].
[1] https://bugs.launchpad.net/python-keystoneclient/+bug/1452298
[2] https://review.openstack.org/180563
Change-Id: Ie9cdd518b299c141f0fdbb3441a7761c27321a88
Co-Authored-By: Jiri Stransky <jistr@redhat.com>
Depends-On: Ic541f11978908f9344e5590f3961f0d31c04bb0c
|
|
|
|
|
|
Adds Rabbit environment variable required for IPv6 only support
Change-Id: Iec209ca83a5b0708ac828c4afaf9d2222e597f24
|
|
Previously we used to always set CinderISCSIHelper to lioadm from
the client. With [1] we aim at cleaning up the client from any
default so this change move the actual default into the templates.
1. Iabc94ad1cce6f1744429aca9f866a59a698f5680
Change-Id: I662e4b0e3cf909ec2583d087ca1d246715caf0f7
Related-Bug: 1554564
|
|
Adds an option to toggle whether events are stored in Ceilometer.
The default is false and remains unchanged.
Change-Id: I9accb679b97cf7172c67f3cd5f218bdaee507c94
Related-Bug: rhbz#1312373
|
|
|
|
|
|
|
|
The swift device string is formatted in the outputs of the
controller template and swift-storage templates.
For ipv6 we need to delimit the address with [] as discussed in
https://bugzilla.redhat.com/show_bug.cgi?id=1296701#c0
Change-Id: Ie611d62c3668a65a7be52777a613d265682c6a8b
Co-Authored-By: Jiri Stransky <jistr@redhat.com>
Closes-Bug: 1534135
|
|
This just a revert to see if reverting this gets back to a normal CI run time.
This reverts commit f72aed85594f223b6f888e6d0af3c880ea581a66.
Change-Id: I04a0893f6cf69f547a4db26261005e580e1fc90b
|
|
To enable IPv6 in Corosync, you'll need to set the --ipv6 parameter when
building the cluster.
To do so, we need to specify this parameter in puppet configuration when
running ::pacemaker::corosync class.
So we have now a new parameter: CorosyncIPv6 which is a boolean, False
by default. If set to True, it will pass right options to enable IPv6
when building the Pacemaker cluster.
Change-Id: I485f1399964ddd7a201ed19ec6580b8a136b3acd
|
|
Without this the nova_api and sahara database_connection string won't
add brackets around the IP address, when IPv6, causing db sync to fail.
Change-Id: I262e5de993ae59ad665edb043119aac2e09c6fdc
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Configures all services to send notifications to rabbit. The puppet
modules are not consistent regarding how this is done - some expose
notification config as a top-level param, others you need to set it
through a *_config structure, and cinder provides a separate class
dedicated to enabling ceilometer notifications.
Change-Id: I23e2ddad3c59a06cfbfe5d896a16e6bad2abd943
|
|
Populates /etc/hosts with an entry for each IP address the node
is on, which will be useful to migrate services configuration from
using IPs into using hostnames.
This is how the lines look like on a host which doesn't have all ports:
172.16.2.6 overcloud-novacompute-0.localdomain overcloud-novacompute-0
192.0.2.9 overcloud-novacompute-0-external
172.16.2.6 overcloud-novacompute-0-internalapi
172.16.1.6 overcloud-novacompute-0-storage
192.0.2.9 overcloud-novacompute-0-storagemgmt
172.16.0.4 overcloud-novacompute-0-tenant
192.0.2.9 overcloud-novacompute-0-management
the network against which the default (or primary) name is resolved
can be configured (for computes) via ComputeHostnameResolveNetwork
Change-Id: Id480207c68e5d68967d67e2091cd081c17ab5dd7
|
|
During upgrades, we only run Puppet on the whole deployment to converge
the state, after the upgrade workflow itself has been fully
completed. That is an opportunity to utilize Puppet to make sure Nova
Compute RPC doesn't remain pinned to the older version.
Change-Id: I6ebc813a80dfd9dfbbb213c38724487e044507b8
|
|
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
|
|
This commit ensures we are not using any deprecated parameters for
nova::network::neutron and are using the right variable names.
Change-Id: Ic1b41e2cdbb6b180496822cc363c433e9388aa02
|
|
|
|
|
|
|
|
This change adds the TripleO Heat Parameters and Puppet hieradata
to support setting the MTU for Neutron tenant networks. A new
parameter, NeutronTenantMtu is introduced, and this gets used for
the NeutronDnsmasqOptions and in Puppet hieradata.
NeutronTenantMtu is also used in the Puppet hieradata for both the
compute and control nodes. Two values are set:
nova::compute::network_device_mtu
which sets /etc/nova/nova.conf: network_device_mtu = <NeutronTenantMtu>
neutron::network_device_mtu
which sets in /etc/neutron/neutron.conf:
network_device_mtu = <NeutronTenantMtu>
finally, the NeutronDnsmasqOptions parameter becomes a str_format
that maps the NeutronTenantMtu onto the DHCP options,
so a default of 'dhcp-option-force=26,%MTU%' would be formatted to
'dhcp-option-force=26,1300' if NeutronTenantMtu were 1300.
This will set dnsmasq to serve an MTU via DHCP that matches the
NeutronTenantMtu:
/etc/neutron/dnsmasq-neutron.conf:dhcp-option-force=26,1300
Typically, you would change all three of these settings to use small
or jumbo frames in VMs. When using tunneling, NeutronTenantMtu
should be set at least 50 bytes smaller than the physical network
MTU in order to make room for tunneling overhead.
Note that this change does not support setting the MTU on veth
interfaces if veth patches are used to br-int instead of OVS
patches.
Change-Id: I38840e082ee01dc3b6fc78e1dd97f53fa4e63039
|
|
The ceph::mon resource is a define not a class so the hieradata is
not applied transparently; this change passes it to
ceph::profile::params instead which is a class.
Change-Id: Ia6518b769feb147f862b67915432d1bb7b47a415
Depends-On: I56f969328c68ed83a9b2d54ff4254dbcd6f55de0
|
|
This hieradata key, neutron::agents::ml2::ovs:bridge_mappings was
missing a : before bridge_mappings causing the value to be blank in
/etc/neutron/plugins/ml2/openvswitch_agent.ini even if a value had been
specified.
Change-Id: I377565d3fb821be1bb2dc7d92ec1ad25a4a3b1f1
|
|
|
|
Without this the heat database tables will grow without limit.
Change-Id: I687e733db1a73ebc2047609a03be768093010dd4
DependsOn: Ia2b80e5003450cd794ebb0c9ca72200ec8616e81
|
|
|
|
This enables the creation of the nova_api database that is now
mandatory since https://review.openstack.org/#/c/245828/
Change-Id: Ia8242f23864ebb14ccf858a77ba754059e9c2d4a
Related-Bug: #1539793
|
|
For both HA & non-HA scenarios, switch puppet-keystone configuration to
be run in a WSGI process instead of eventlet.
WSGI is the way to go for scaling Keystone, moreover, eventlet won't be
support in next OpenStack releases.
Co-Authored-By: Dan Prince <dprince@redhat.com>
Depends-On: I22a348c298ff44f616b2e898f4872eddea040239
Change-Id: I862b4a68f43347564ec3c0ddc4ec9e1d1c755cf2
Signed-off-by: Jason Guiditta <jguiditt@redhat.com>
|
|
We get false negatives from Tempest when the Cinder LVM backing
file runs out space. This change increases its default size to 10G,
matching devstack [1]
1. https://github.com/openstack-dev/devstack/blob/master/stackrc#L649
Change-Id: Ia334ea481e17c1d35aa67c33729cac6570f48199
|
|
Some operators desire more granular control of hostnames than is
currently possible via the *HostnameFormat parameters, in particular
mapping nodes to explicit IDs (such as inventory references) is not
easily possible.
So, add a HostnameMap parameter, which is optional and allows
explicit overriding of the default hostnames.
E.g pass an environment like this:
parameter_defaults:
HostnameMap:
overcloud-controller-0: overcloud-controller-prod-123-0
overcloud-controller-1: overcloud-controller-prod-456-0
overcloud-controller-2: overcloud-controller-prod-789-0
Note this is mapping is global (for all roles), because we
expect the keys to be unique given that they include the
role name and index by default.
Note that this depends on a fix for heat bug #1539737
Change-Id: Ib4d3d40e9523903ebccc06c3e14b2d71d924afa3
Depends-On: Ib934f443a8b8e4f75335a9d8b992e7f86791aa45
|
|
|
|
Deploy a TripleO overcloud with OpenContrail Vrouter plugin configured
to interact with an existing OpenContrail Server Manager.
OpenContrail is an Apache 2.0-licensed project that is built using
standards-based protocols and provides all the necessary components for
network virtualization–SDN controller, virtual router, analytics engine,
and published northbound APIs. It has an extensive REST API to configure
and gather operational and analytics data from the system.
Co-Authored-By: Jiri Stransky <jistr@redhat.com>
Change-Id: I699a7c4ea09d024fe4d70c6a507c524f0a7aafd5
|
|
|
|
Currently the value of the CloudName param gets written into the
/etc/hosts file on each controller, but it turns out this is an
invalid configuration. CloudName is supposed to be the DNS name
of the overcloud, and the IP being written is (at least in my case)
the internal API VIP. This breaks in cases such as SSL because
the services are not listening on an SSL port on the internal API
network, so if a service tries to talk to another service using a
CloudName-defined public endpoint it ends up pointed at a
non-existent internal address:port.
Since by definition CloudName is supposed to be resolvable by the
configured DNS server, we should not need an explicit hosts entry
as well. Thus, this patch removes that from the file.
Change-Id: I919b42a219d95296f46852dd3266a54d968cf66b
|
|
|
|
In our neutron.conf we configure both keystone v2 and v3 options,
which confuses the keystoneclient code responsible for deciding
which to use. For whatever reason, having it talk to the
unversioned keystone endpoint and letting the client decide which
version that way makes it happy. Except that we write a wrong
value for project_name, which makes it unhappy again.
This change fixes both of those issues, which allows notifications
to work again.
Change-Id: Ic3a329354d0ed071363183b5e06c0a42d2dd84ad
Closes-Bug: 1519525
|
|
|
|
|