The swift pipeline is commonly used to plug
capabilities in.
This pipeline should be implemented in a way that
is easier to extend as people desire additional
pipelines.
This commit implements classes that can be used
to configure the following pipelines:
- proxy::cache
- proxy::healthcheck
- proxy::keystone
- proxy::swauth
It also reimplements swift::proxy to utilize those
pipelines for configuration.
This commit performs a refactor of the
swift::storage::config to use fragments.
Updates server templates
- makes workers,user, and mount_checks configurable
- adds a default for concurrency
- makes the pipeline configurable
- remove vm_test_mode flag
Updates swift::storage::server to use fragments for
the config file.
This has been refactored to allow the end user a
greater level of flexibility over how they can
configure custom plugins for swift.
Also adds additional class params: pipeline,
mount_check, user, workers, concurrency.
Update the unit tests for swift::storage:server
Previously, the swift caches were being built on the class
instances themselves.
This could result in stale values when puppet runs multiple times
using the same process (like in the case of puppet agent)
This commit uses prefetch to ensure that the retrieved swift ring
values are updated per puppet run.
I was using older versions of the Ubuntu packages
that shipped with broken upstart scripts.
I am removing these patches now that I am using packages
that work.
Also updates the spec tests to account for the changes.
This commit adds support for fedora.
It introduces a params namespace class
to hold data differences between ubuntu and fedora.
It also moves the xfs packages into their own class (swift::xfs)
I am not so sure that having multiple resource
types in the same file is supported as of 2.7.11
I am refactoring this code so that the upstart define
resides in its own file according to our standards.
So that it can be accessed by the swift proxy
from this address.
Previously, it was binding to eth0 and swift proxy
was trying to access it via localhost.
This commit adds an example of how to sync rings between
nodes.
The ringbuilder role exports resources representing the ring
databases that need to be synced.
The storage node can then just collect these resources
This commit adds puppet code to handle syncing of the ring
databases.
The class swift::ringserver is used to set up an rsync server
that serve out the ring databases.
The define swift::ringsync is used to rsync these ring databases
to the other hosts.
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 updates the spec tests so that they should work.
- the ssh module that they depend on had introduced a dependency on
the operatingsystem fact
- tests had not been updated to reflect using xinetd and not the service
to run the rsync daemon
- update travis-ci to include the xinetd module
Since rsync is now managed by xinetd, it is
necessary to remove the references to the rsync
service.
This was previously causing catalog compilation failures.
Also updates travisci and the unit tests
Previously, using the rsync sevices on Ubuntu
did not actually work.
After reading the init script, I decided that it
is annoyingly different from Redhat's implementation
so I have chosen to use xinetd to make the module more
consistent between the distros.
This commit adds the parameter proxy_local_net_ip to
the swift::proxy class for the all in one example.
This parameter had been changed to be required in a previous commit,
but the example had not been updated.
I changed the tests so that they check individual
lines of the resulting swift proxy file as opposed to
the entire file contents.
This was done so that tests can be associated with
only the parts of the resulting file they are related
to.
It is possible that the memcache server(s) may
reside on different machines than the swift
proxy.
This commit decouples the configurations of the
two services.
Previously, the binding address for all services
was set to localhost.
This is not going to be a commonly used value
for production deployments.
The defaults for address have been removes b/c
there isn't really a sensible default. This is
something that the users should have to set.
Previously, all of the storage server types
(account, container, proxy) were always
configured to be installed on the same node.
It often makes sense to only have the account and
container together, and to put the object server on
a different node. (or its possible that other
configurations make sense)
This commit refactors the swift module so that
each of the types of nodes can be built
independently of each other.
