The mechanism to load additional config files for oslo.messaging option
was introduced to ceilometermiddleware. Use this mechanism to inject
oslo.messaging options so that we can customize behavior of the library
like use_ssl.
Depends-on: https://review.opendev.org/904328
Change-Id: I5a82a52ddea610b4dda6658378d78a6cf13e3bb2
(account|container|object)-server.conf requires sections for each
services but these sections sometimes don't require settings when
service defaults are used.
This change allows defining only sections using *_config resources.
Depends-on: https://review.opendev.org/849235
Change-Id: I827c06cc994e13b900a9eeaeaec7849a243732e2
This change ensures the shortened address representations are always
used for ring devices to avoid broken idempotency caused by different
representations (shortened[1] vs canonical[2]).
[1] ::1
[2] 0000:0000:0000:0000:0000:0000:0000:0001
Closes-Bug: #1997313
Change-Id: I762f0780ba25536aa616482a49d59c7db69924d6
This change introduces capability to customize internal-client.conf,
which is used by several daemon processes like container-sharder.
Closes-Bug: #1986599
Related-Bug: #1921319
Change-Id: I200e3a4ff323a07778ec6c4d7dd96824c72a12cf
Regex validation for aliases in swift_storage_policy provider does not
allow single alias value, like for exemple:
swift::storage::policy { '1':
policy_name => '3-Replica-Policy',
policy_aliases => 'green',
This fixes the accepted pattenr to allow single-value for policy_aliases
parameter.
Also, the whole expression is updated to more strictly validate
the pattern, especially when more than 2 aliases are given.
Change-Id: I62c86097c717d2a74c100386cf20e07976571805
This patch is adding the configuration of the number of workers,
and the size of the listen queue in Debian, which uses uwsgi to run
Swift. Therefore, this patch adds new swift_proxy_uwsgi_config,
swift_account_uwsgi_config, and swift_container_uwsgi_config, providers
as well as e new swift::wsgi::uwsgi_proxy, swift::wsgi::uwsgi_container,
and swift::wsgi::uwsgi_account classes.
Change-Id: Ib18f3479bc6a4513a7b3d823cda480c4ace2f2c0
Adding barbican configuration to Swift will
allow enabling data-at-rest encryption in Swift.
Change-Id: I78c6003f5f599a422193dc47422ee607ce05c715
Signed-off-by: Thiago da Silva <thiago@redhat.com>
This commit adds support for the memcache_servers option in
object-expirer and container-reconciler. Without this, both
currently default to 127.0.0.1:11211.
Closes-Bug: #1627927
Change-Id: Ie139f018c4a742b014dd4d682970e154d66a8c6d
This change implements storage policies as defined by swift:
http://docs.openstack.org/developer/swift/overview_policies.html
There are two primary areas of change in this review
- Add storage policy support to the ringbuilder and ring devices, along with
associated spec tests.
- Adding storage policy support and enforcing rules in swift.conf using the
swift_storage_policy type and provider. Also: updated spec tests and an
update to swift acceptance test to use storage policies to configure an
additional 3 replica based ring.
See release notes and the README update for more details/instructions.
Change-Id: I2b8db751790704df3f1027a14f61e231591537f3
Add possibility to configure container_sync middleware. Also
allow to configure swift container-sync-realms, which specifying
the allowable clusters and their information, which is required
for container_sync.
Change-Id: I183841cca3daf72a30db160b88c9e3a9335ad7dc
This commit moves conditionals based on values obtained from Facter
inside code blocks that are only executed on agents and replaces
the use of Facter['osfamily'].value with Facter.value:(:osfamily).
Without this change we are returning values based off the master's
facts, so if a Debian agent checks into a RedHat master then the type
is currently making a decision based off of RedHat and not the actual
OS of the agent running the catalog. Code ran outside blocks is
evaluated on masters and inside a block is evaluated by the agent when
the catalog is executed. We do not notice this because all our
testing uses "puppet apply" and autorequire only matters when they
find a matching resource name in the catalog. The latter results
in no error because the relationship is simply ignored on the Debian
agent if a package resource with the RedHat name is not found.
This issue was found by running facter 3, the C++11 re-implementation
under the jruby and clojure implemented puppetserver. The clojure
jni shim written so that facter can be ran inside of puppetserver does
not implement the [] method for the Facter module but the ruby shim
does. So I noticed that the code had an issue when
Facter['osfamily'].value was executed on the master, which returned a
not method error. Once again, something we didn't notice becuase we
do not test against a master. I decided to migrate to
Facter.value(:osfamily) to simply keep to an API that is consistent
across both puppet and puppetserver but fixing where the code runs
does actually solve the not method found error.
Change-Id: I24b0b20b2839c7bc33a76ac14849783f2285579f
The swift-object-expirer service was not supported by
puppet-swift. Adding support by creating a new class
(swift::objectexpirer), and its associated custom type/provider.
Change-Id: I498ffe525a7316c0091e4c9d8b7d9658234231f6
With the creation of the new openstack_config provider, some processing
that was done in swift_config has been centralized in
openstack_config.
Impacted methods are :
* section
* setting
* separator
Also, this commit adds the fact that, when passing a specific string
(ensure_absent_val) the provider will behave as if ensure => absent was
specified. '<SERVICE DEFAULT>' is the default value for
ensure_absent_val.
The use case is the following :
swift_config { 'DEFAULT/foo' : value => 'bar' } # will work as usual
swift_config { 'DEFAULT/foo' : value => '<SERVICE DEFAULT>' } # will mean absent
That means that all the current :
if $myvar {
swift_config { 'DEFAULT/foo' : value => $myvar }
} else {
swift_config { 'DEFAULT/foo' : ensure => absent }
}
can be removed in favor of :
swift_config { 'DEFAULT/foo' : value => $myvar }
If for any reason '<SERVICE DEFAULT>' turns out to be a valid value for
a specific parameter. One could by pass that doing the following :
swift_config { 'DEFAULT/foo' : value => '<SERVICE DEFAULT>',
ensure_absent_val => 'foo' }
Change-Id: I9281d2cae81f9799327f7f6e04498d6bc723f233
Depends-On: I0eeebde3aac2662cc7e69bfad7f8d2481463a218
Currently we specify the ordering of config resources wherever it is
necessary based on the presence of the file it will write to, or the
presence of the package in charge of providing the file it will write
to.
Those kind of ordering can be specified directly at the resource level
using the autorequire mechanism. With this patch, any config resource
will make sure the package in charge of providing the file will be
installed first.
Change-Id: Icb3464cc0a747d40326d610d38806d059c9a0fc3
One shold never parse uri with split(':') as it was in types
ring_account_device, ring_container_device and ring_object_device.
This is fixed by using uri and just setting variables from that.
Also swift_ring_builder didn't add brackets to ipv6 address before
adding port information to it.
Change-Id: I55b7032143c8446abeed4f6c266c0fff0cb6b3b3
Since Swift 1.8.0, there is the region layer of topology above zones.
swift-ring-builder supports this natively and this commit allows a user to
specify a region when creating devices.
We maintain backwards compatibility by defaulting to region '1'.
The coverage of the ring builder spec tests were also improved as part of
this commit.
Change-Id: I67cbe6b87c84778f71df59cf00f2c5175342bc1b
This change also adds an autorequire in the swift_config
type to ensure the /etc/swift/swift.conf exists.
Change-Id: Ic591a3ceb040c4599339ed7f750a5273d2052ac1
Implements: blueprint puppet-swift-ini-settings
Previous configuration file management method used templates.
This method had limited flexibility and was cumbersome
to use and maintain between upstream versions.
This change introduces new custom types based on ini_setting:
* swift_account_config: /etc/swift/account-server.conf
* swift_bench_config: /etc/swift/swift-bench.conf
* swift_config: /etc/swift/swift.conf
* swift_container_config: /etc/swift/container-server.conf
* swift_dispersion_config: /etc/swift/dispersion.conf
* swift_object_config: /etc/swift/object-server.conf
* swift_proxy_config: /etc/swift/proxy-server.conf
The use of ini_setting offers multiple advantages:
* Ability to individually manage configuration settings without
the need to modify templates. This allows the user to manage or
override settings that aren't handled by the module.
* Use upstream default values if none is provided.
* Remove the need to maintain and synchronize templates
to match upstream versions. Such maintenance could become
problematic and complicated if multiple upstream versions
are supported but have different base configuration files.
Implements: blueprint puppet-swift-ini-settings
Change-Id: Iba7be64581b81b8ab4f33cf7096df37e64ccc4b4
Previously, the Puppet modules only supported a single device per
endpoint.
This commits allows multiple devices per endpoint by making the device
name a part of the namevar for the swift ring devices.
it also updates the relevent configs.
The swift ring db converts integers into floats with 2 decimal
points percisions. This was causing the ring resources to constantly
resync.
This commit munges weight in the type to the proper format.
This commit adds a class, defined resources and
native types that can be used together to manage
the creation, configuration, and rebalancing of
rings.
Creates the following native types:
ring_account_device
ring_container_device
ring_object_device
The implementation of these types is provided
by swift-ring-builder and most of the functionality
is provided by the parent provider (SwiftRingBuilder)
Each of the providers is hard-coded to find the
relevent ring database in /etc/swift. This directory
location can currently not be configured.
Each provider implements self.instances so the
current state can of the ring can be queried from
puppet.
These providers do not handle either the creation
or the rebalancing of the rings, they are intended
to be used in combination with defined resource types
that perform that functionality:
swift::ringbuilder::create
swift::ringbuilder::rebalance
The swift::ringbuilder class is also created as
a part of this commit. This class does the following:
- creates object, account, and container rings
(it uses the same parameters to create these rings)
- creates the rebalance defines
- sets up the following relationships:
for each ring type, create should be applied before
the native types which should refresh the rebalance
