| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This change adds puppet hieradata settings which disable IPv6
autoconfiguration and accept_ra by default on all interfaces.
When IPv6 is used, the interfaces are individually enabled and
configured with static IP addresses.
The networking on the compute host needs to be completely
separate from the tenant networking, in order to safeguard the
compute host and isolate tenant traffic. This change disables
IPv6 autoconfiguration and acceptance of RAs by default on
interfaces unless specifically enabled.
Without these settings, IPv6 is enabled on all interfaces, as well
as autoconfiguration and accept_ra, so when the compute host
creates a bridge interface for the router (qbr-<ID>), the
compute node will automatically assign an IPv6 address and will
install a default IPv6 route on the bridge interface when it
receives the RAs from the Neutron router.
The change to turn off autoconfiguration means that interfaces
will not self-assign an IPv6 address, and the change to not accept
RAs is a security hardening feature. This requires that a
static gateway address be declared in the network environment
in the parameter ExternalNetworkDefaultRoute. Alternately, sysctl
can be modified to change the accept_ra behavior for specific
interfaces.
Change-Id: I8a8d311a14b41baf6e7e1b8ce26a63abc2eaabef
Closes-bug: 1544296
|
|
During high load, the default limit of the kernel connection tracking
table (65536) is often too low, resuling in error messages such as:
kernel: nf_conntrack: table full, dropping packet
This patch increases the limit to 500,000.
Since the nf_conntrack kernel module is not always loaded by default, it also
adds a mechanism to load kernel modules via hieradata using the kmod puppet
module. In order to express the needed dependency in puppet that kernel modules
are loaded before sysctl settings are applied, the Exec resources tagged with
'kmod::load' are specified in a resource collector to express that that Exec
resources with the tag should run before Sysctl resources.
Depends-On: I59cc2280ebae315af38fb5008e6ee0073195ae51
Change-Id: Iffa0a77852729786b69945c1e72bc90ad57ce3bb
|
|
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
|
|
* 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
|
|
In nova.conf, set cinder/catalog_info to 'volumev2:cinderv2:internalURL'
instead of 'volumev2:cinderv2:publicURL'.
So Nova will use internal Cinder endpoint to reach volume API by
using internal network.
Depends-On: Id9e579ca31364d5207d0c1b892d0f7aa7f20f7a8
Change-Id: Ia34f0fe59f662c3ad29ca0178c01ef1570759d57
|
|
Make core_plugin, type_drivers and service_plugins parameter in
neutron configurable through heat.
Also changing the type_drivers order to "vxlan,vlan,flat,gre"
Change-Id: Iba895ed5897bdaf7bb772ffc063c424abb6e1638
|
|
This change enables Keystone notifications and adds two parameters
to control the notification driver and format.
Change-Id: I23ac3c46ee9eb49523d3b8dab027ef21fc6e42df
|
|
|
|
Updates the default settings for Nova, Neutron, Cinder,
Ceilometer, and Heat services so we set the default rabbitmq
threshold to 60 seconds.
Change-Id: If537ae16968eb6b264b2ab071144f1eecab18b64
|
|
Change-Id: I7703013b62bd67869c268fb8689389ec0eeb5aad
|
|
This adds the NeutronTunnelIdRanges and NeutronVniRanges parameters
which govern the GRE or VXLAN tunnel IDs (respectively) that are to
be made available for overcloud tenant networks.
These both default to "1:1000," to retain the current behaviour.
They are propagated to the hiera data for puppet deploys and there
is a separate change to support passing these into the config via
the neutron tripleo-image-element at
https://review.openstack.org/#/c/199592/
Change-Id: I967a8cae218a31e888abc438e9de5756ae627adb
Related-Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1240631
|
|
The list of drivers loaded by the ML2 plugin does not have to
match the list of tenant_network_types, this will make ML2 load
the flat, gre, vxlan and vlan drivers so that the provider
networks can be of flat (default) and vlan type as well.
Change-Id: I0b74f86acf5c1ff644deb46c0a1d14129c1882d4
|
|
Change-Id: I16d259055fe4cd22541cd7abd7a26c71bbbaf292
|
|
This will configure the sysctl settings via puppet instead of
sysctl image element.
Change-Id: Ieb129d4cbe4b6d4184172631499ecd638073564f
|
|
The overcloud networking is managed by Neutron so we do not want
Nova to append its default domain part to hostnames.
Change-Id: Ic1edda158bf0579ed34455ad27db8ca444d26b85
|
|
Remove references to the .novalocal domain part in the hosts file.
Change-Id: Idf14907adaf2f35440b6f28870fe18434eadd1be
Depends-On: Iadfdf4120c4d1c9b6976321753957fd4eecf301c
|
|
We're already configuring Neutron in Overcloud, but the controller
is still configured to use the default Nova neutron_api_class for
default configuration for networking, which means it used Nova Network
and not Neutron. This causes some of the Nova API is_neutron
checks to behave incorrectly.
This patch updates the controller to use nova::network::neutron (like
we already do on the overcloud_compute.pp role). As part of the change
several of the compute specific hiera settings for the
nova::network::neutron class have been moved to common.yaml.
Change-Id: Id2d5a5a0aa1ca087de714880ef1ea98484b06849
|
|
This patch adds support for the Ceilometer controller
role including the Ceilometer:
-API
-central agent
-alarm notifier
-alarm evaluator
-collector
-expirer
In order to enable swift metering the swift::proxy ceilometer middleware
was added in.
Also, a minor adjustment to the existing ceilometer HA proxy setting
was made to accommodate ceilometer auth settings. (not exactly sure
why but this seems to be required)
Like upstream TripleO Ceilometer is currently using a MySQL database
backend. A follow on patch can support configuring MongoDB for use
with Ceilometer.
Change-Id: I4e171274bd7679d386d93492d13dfa7c5d37f6a8
|
|
This patch adds support for a Swift proxy and storage
node on the controller.
The implementation is fairly straightforward with the
exception of building the ring. I've followed an
upstream TripleO model here where we build the
actual ring on each node (rather than build once
and rsync). This works because Heat will always
know all the devices ahead of time. In the future
when we have Heat breakpoints it might be possible
to consider optimizing this by generating the ring
once and then rsyncing to all the nodes.
The ringbuilder logic is executed as a seperate
Heat software deployment. On the controller the ring
is executed in between the base service (mysql/rabbit)
and OpenStack service steps. This is to ensure the
ring exists before the Swift proxy is started.
Having the ringbuilder.pp logic as a separate software
config should allow us to reuse it for the Storage
node role.
It should also be noted that swift.zones support is
added here but we are missing an upstream Heat
template change in order for it to be wired
in properly. See: I0e0f5189da1575f2e1ed7fba4bbbe13a8fbf6221
Likewise we need to properly wire in SwiftRingBuild as well.
See: I01311ec3ca265b151f8740bf7dc57cdf0cf0df6f
The underlying puppet ringbuilder code is already wired
to support this change when it lands.
As is this works today and will provide a working Overcloud
Swift-proxy/storage node config. Will follow this up with
a related Swift storage node patch which should allow
puppet to be used for configuration on the storage nodes
as well...
Change-Id: Id1272f796e2507a7357309e8cd6a51ad9e0160af
|
|
This patch provides an alternate implementation of
the OS::TripleO::Compute::SoftwareConfig which uses Puppet
to drive the configuration. Using this it is possible
to create a fully functional overcloud compute instance
which has the compute node configured via Puppet
stackforge modules. This includes all the Nova, Neutron,
and Ceilometer configuration required to make things work.
In order to test this you'll want to build your images
with these elements:
os-net-config
heat-config-puppet
puppet-modules
hiera
None of the OpenStack specific TripleO elements
should be used with this approach (the nova/neutron/ceilometer
elements were NOT used to build the compute image).
Also, rather than use neutron-openvswitch-agent to configure
low level networking it is recommended that os-net-config
by configured directly via heat modeling rather than
parameter passing to init-neutron-ovs. This allows us to
configure the physical network while avoiding the coupling to
the neutron-openvswitch-element that our standard
parameter driven networking currently uses. (We still need
to move init-neutron-ovs so that it isn't coupled and/or deprecate
its use entirely because the heat drive stuff is more flexible.)
Packages may optionally be pre-installed via DIB using the
-p option (-p openstack-neutron,openstack-nova).
Change-Id: Ic36be25d70f0a94ca07ffda6e0005669b81c1ac7
|
Dan Sneddon
James Slagle
Rohit Pagedar
Emilien Macchi
Shiva Prasad Rao
Giulio Fidente
Jenkins
Dan Prince
Jiri Stransky
marios