Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
This wires in use of a new puppet-tripleo class which
encapsulates the logic to enable/disable package
installation and upgrades.
By using the new class we can remove the global
Package provider declaration at the top of each
module.
Change-Id: I5c6e5fd8600031bd8fb6195649721607c560f9d5
Depends-on: Ie8fbc344149bc8c9977e127de77636903607617a
|
|
It was incorrectly assumed that Puppet variables assigned to a
defined class (as seen in cinder-netapp.yaml) would be applied to
any resources created with that type. This is not how Puppet works.
The full range of configuration parameters to cinder::backend::netapp
have been added back in. They are still pulling from Hiera like they
were intended before, but it needs to be a little more explicit for
Puppet to be happy.
Change-Id: I2e00eae829713b2dbb1e4a5f296b6d08d0c21100
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
By default Cinder will get the publicURL for Nova and Swift, which
is not reachable by the CinderStorage nodes.
Change-Id: I25b7900c9ab261e0f706257ffdf6844533b63b94
|
|
By default Nova will get the publicURL instead, which is not
reachable by the compute nodes.
Change-Id: I57b6a7a7eddb0ffaf6d2d152d932f390c48f908e
|
|
Adds support for global (ExtraConfig) and role-specific
(CephStorageExtraConfig) hiera overrides, similar to those added
for the Controller, NovaCompute, BlockStorage, ObjectStorage roles.
Change-Id: Idbe73b86a772491cd3c55ba69b5a95cc291d2598
|
|
Adds support for global (ExtraConfig) and role-specific
(ObjectStorageExtraConfig) hiera overrides, similar to those added
for the Controller, NovaCompute and BlockStorage roles.
Change-Id: I7dd0d8003017e2738366983cb5d8e08b3f3fa334
|
|
Adds support for global (ExtraConfig) and role-specific
(BlockStorageExtraConfig) hiera overrides, similar to those added
for the Controller and NovaCompute roles.
Change-Id: Iaf9665b53407e6a657f56d6516469f2c88bafbdd
|
|
Adds support for global (ExtraConfig) and role-specific
(NovaComputeExtraConfig) hiera overrides, similar to those added
for the controller.
For example, you can pass an environment file like:
parameters:
NovaComputeExtraConfig:
nova::scheduler::filter::ram_allocation_ratio: 1.8
compute_classes:
- ::nova::scheduler::filter
This passes a hiera value for ram_allocation_ratio and enables
a class via the include added in https://review.openstack.org/#/c/197908/
Note this also requires https://review.openstack.org/#/c/188772/
or 40-hiera-datafiles incorrectly quotes the list and the
compute_classes part won't work.
Change-Id: Ic33eed1b5e9c33c0d2f6075c65c8d9649b82c8b4
|
|
|
|
As a matter of fact it seems that the 1024 connections barrier
can easily be reached with modern hardware, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1240824
Change-Id: I194a0dd725907350ca16ea3c41f3ed4f68a11bcf
|
|
Wires in the ControllerExtraConfig and ExtraConfig parameters so
that they may be used to specify overrides of the default hieradata.
Note if this is used to override values specified via parameters
rather than hard-coded values in puppet/hieradata caution should
be used as the overridden values will always take precendence
regardless of the parameter input, unless the parameter is provided
directly to the Deployment resource applying the manifiest (e.g
not the pattern currently employed in most of t-h-t)
Also note that ControllerExtraConfig takes precedence over the
deployment-wide ExtraConfig.
For example, here's how you would pass a value which disables the
heat-api-cfn service on all controllers. This would be put into an
environment file, then passed to the heat stack-create via an extra
-e option:
parameters:
controllerExtraConfig:
heat::api_cfn::enabled: false
Note the parameter capitalization is different in the top-level
overcloud-without-mergepy template for some reason.
Change-Id: I6d6e3e78460308134d95c01892bb242aba70e9ca
|
|
|
|
|
|
|
|
|
|
Currently we build the overcloud image with selinux-permissive element
in CI. However, even in environments where selinux-permissive element is
not used, it should be ensured that SELinux is set to permissive mode on
nodes with Ceph OSD [1].
We have no nice way to manage SELinux status via Puppet at the moment,
so i'm resorting to execs, but with proper "onlyif" guards.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1241422
Change-Id: I31bd685ad4800261fd317eef759bcfd285f2ba80
|
|
Currently the bootstrap of the neutron server happens with the use of a
start/sleep/stop pattern.
Since Pacemaker doesn't mind if the service is already started let
simply start the neutron server on the $pacemaker_master node and wait
for 5 sec.
Change-Id: I894dc3305f7d6685ebcc6828e690c718a63f32bd
Closes-Bug: #1473410
|
|
Change-Id: Ib945b07dd93f9bdc613f464211745094c4c72836
|
|
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
|
|
By default MongoDB enables a journaling system that prevents loss of
data in case of an unexpected shut-down. When journaling is enabled,
MongoDB will create the journal files before actually starting the
daemon[1].
The journaling feature is useful in production environment, but not
really on a CI-like system, where we only want to make sure MongoDB is
setup correctly and running, hence here we allow a user to
enable/disable MongoDB journaling.
[1] http://docs.mongodb.org/manual/core/journaling/
Change-Id: I0e4e65af9f650c10fdf5155ff709b4eb984cf4e1
Closes-bug: #1468246
|
|
The number of connections created to the database depends on the
number of running processes and this is a factor of both the nodes
count and the cores count. We make it configurable so it can be
increased when needed.
Change-Id: I41d511bde95d0942706bf7c28cd913498ea165fb
|
|
|
|
Currently for both puppet and image-elements based deploys we set
the dhcp_agents_per_network in neutron.conf to 2 and there is no
control over that number (in the hieradata for the former and the
image element for the latter). This change adds the
NeutronDhcpAgentsPerNetwork parameter and also changes the default
to 3 when not explicitly set.
In the puppet case propagate this parameter in the hieradata for
the neutron class and in the non-puppet case expose a new item in
the neutron config to be consumed by the neutron image element
(that change will point here)
Change-Id: Id97c7796db7231b636f2001e28412452cf89562b
|
|
In the overcloud heat, heat.conf instance_user is set to heat-admin.
The consequence of this is that SSHing into heat created guest VMs will require
the user 'heat-admin'. I predict that this will result in user confusion as to
how to SSH into their VMs since they will be attempting default usernames
(centos, cloud-user etc) or the documented heat default user (ec2-user)
This change sets it to an empty string so that default usernames are used.
This change depends on the puppet-heat fix to allow empty string instance_user:
Depends-On: I9e8be0dd50709d271fc81683770c78380724e405
Change-Id: Id14bf3a4ac1b1c95797dae16c674b32a2da230f8
|
|
|
|
The *HostnameResolveNetwork services define the network against
which the hostnames in /etc/hosts should be resolved, defaults
to 'internal_api' for all except CephStorage for which it uses
'storage' as they do not have connectivity to 'internal_api'.
Closes-Bug: 1471179
Change-Id: Ia8971f8a63016966236e7975ac2d97921a314255
|
|
|
|
This value doesn't work, and the default of heat_stack_user is fine.
See https://github.com/openstack/puppet-heat/blob/989ffa65f4339bfd9612cff3b5ddcc4fd301f695/manifests/engine.pp#L22
Resolves: rhbz#1238844
Change-Id: I247121cb91d2b2a34f0f9f769fb411fcbfe6b571
|
|
|
|
Adds support for NFS backend for Cinder, but remains disabled by
default.
Change-Id: I9ebef072ed115efe980fa4904ea80f02384522af
|
|
|
|
|
|
This patch adds a new parameter to configure the
neutron external network bridge. This setting
applies to the bridge used in the Neutron l3_agent.ini file
and can by useful if you wish to set external_network_bridge = ''
in that file.
As part of this fix we also update the environment file for
network isolation so that we automatically set the new
NeutronExternalNetworkBridge to an empty string. This fixes
an issue where overcloud floating IPs did not work correctly
when using the external network interface for floating IP
traffic.
Change-Id: I3bfcda8746780ea0851d88ed6db8557e261cef0d
|
|
We weren't configuring the Heat ec2 auth uri, so it was using the
default pointing at localhost. This won't work in most setups
because Keystone listens on specific addresses not including
localhost, so configure it to use the proper Keystone address.
Change-Id: I979a87c68a8f6f558ccfc04662c158c89fcf1388
|
|
The recently added cinder-netapp extraconfig contains some additional
hieradata which needs to be applied during the initial pre-deployment
phase, e.g in controller-puppet.yaml (before the manifests are applied)
so wire in a new OS::TripleO::ControllerExtraConfigPre provider resource
which allows passing in a nested stack (empty by default) which contains
any required "pre deployment" extraconfig, such as applying this hieradata.
Some changes were required to the cinder-netapp extraconfig and environment
such that now the hieradata is actually applied, and the parameter_defaults
specified will be correctly mapped into the StructuredDeployment.
Change-Id: I8838a71db9447466cc84283b0b257bdb70353ffd
|
|
|
|
|
|
|
|
|
|
Allows inclusion of additional arbitrary puppet classes by the
manifests if defined in the *_classes hieradata.
Example: to specify the Nova RAM allocation ratio there is a
param in nova::scheduler::filter but we do not include it
by default; if needed one can use:
nova::scheduler::filter::ram_allocation_ratio: 1.8
controller_classes:
- nova::scheduler::filter
Change-Id: I61d64d2498bed5c49376dee917d106598392db51
|
|
Without the constraint the VIP could get assigned to a node without
an active haproxy instance, which ultimately means everything stops
working.
kind=Optional allows a VIP to relocate to a healthy haproxy instance
in the event of a failure without tearing down the entire stack in the
process.
Change-Id: I44d44952fb42cf91a2a248250a4063e3034d119e
|
|
As reported in https://bugzilla.redhat.com/show_bug.cgi?id=1238117
and https://bugzilla.redhat.com/show_bug.cgi?id=1236578 the
NeutronScale resource is causing problems during post deploy
configuration of the overcloud (momentary inconsistency in the
host name for the neutron agents, given what NeutronScale does,
discussion in BZ 1238117).
As discussed in the bugs, we may not need NeutronScale, since our
host names should be safe enough for scaling. This change removes
neutron scale completely and links startup of neutron-server
directly to neutron-ovs-cleanup. If we can safely remove
the NeutronScale resource then this change does that.
Change-Id: Ib43a2d60b85fd9bb48eff5919602bb74dc463905
|