Files
9f1787b6534b6daee82dad52a2957a3b36982194
swift /setup.cfg

130 lines
4.0 KiB
INI
Raw Normal View History

Migrate to pbr for build pbr is the libification of what was openstack.common.setup. If provides the build information in a delcarative form, instead of as executable python code, which works around the chicken and egg problem of needing setup libraries present to run setup, but needing to run setup to tell if you need setup libraries. One of the features that comes along with this is versioning based on git tags. If the current revision is a signed git tag, then that is the version of the package. If it is not, the version is equal to the most recent git tag, plus a commit count, plus a git sha (similar to git describe, but scrubbed for python version rules compliance) pbr updates are also part of the upcoming automation around ensuring global requirements stay in sync. Closes-Bug: #1179007 Change-Id: Ia473960be7e8aa44f09d48cea72ed3c8845f82fa
2013年05月11日 15:35:37 -04:00
[metadata]
name = swift
summary = OpenStack Object Storage
description-file =
README.md
author = OpenStack
author-email = openstack-dev@lists.openstack.org
home-page = http://www.openstack.org/
classifier =
Development Status :: 5 - Production/Stable
Environment :: OpenStack
Intended Audience :: Information Technology
Intended Audience :: System Administrators
License :: OSI Approved :: Apache Software License
Operating System :: POSIX :: Linux
Programming Language :: Python
Programming Language :: Python :: 2
Programming Language :: Python :: 2.7
[pbr]
skip_authors = True
skip_changelog = True
[files]
packages =
swift
scripts =
bin/swift-account-audit
bin/swift-account-auditor
bin/swift-account-info
Migrate to pbr for build pbr is the libification of what was openstack.common.setup. If provides the build information in a delcarative form, instead of as executable python code, which works around the chicken and egg problem of needing setup libraries present to run setup, but needing to run setup to tell if you need setup libraries. One of the features that comes along with this is versioning based on git tags. If the current revision is a signed git tag, then that is the version of the package. If it is not, the version is equal to the most recent git tag, plus a commit count, plus a git sha (similar to git describe, but scrubbed for python version rules compliance) pbr updates are also part of the upcoming automation around ensuring global requirements stay in sync. Closes-Bug: #1179007 Change-Id: Ia473960be7e8aa44f09d48cea72ed3c8845f82fa
2013年05月11日 15:35:37 -04:00
bin/swift-account-reaper
bin/swift-account-replicator
bin/swift-account-server
bin/swift-config
bin/swift-container-auditor
bin/swift-container-info
Migrate to pbr for build pbr is the libification of what was openstack.common.setup. If provides the build information in a delcarative form, instead of as executable python code, which works around the chicken and egg problem of needing setup libraries present to run setup, but needing to run setup to tell if you need setup libraries. One of the features that comes along with this is versioning based on git tags. If the current revision is a signed git tag, then that is the version of the package. If it is not, the version is equal to the most recent git tag, plus a commit count, plus a git sha (similar to git describe, but scrubbed for python version rules compliance) pbr updates are also part of the upcoming automation around ensuring global requirements stay in sync. Closes-Bug: #1179007 Change-Id: Ia473960be7e8aa44f09d48cea72ed3c8845f82fa
2013年05月11日 15:35:37 -04:00
bin/swift-container-replicator
bin/swift-container-server
bin/swift-container-sync
bin/swift-container-updater
bin/swift-container-reconciler
bin/swift-reconciler-enqueue
Migrate to pbr for build pbr is the libification of what was openstack.common.setup. If provides the build information in a delcarative form, instead of as executable python code, which works around the chicken and egg problem of needing setup libraries present to run setup, but needing to run setup to tell if you need setup libraries. One of the features that comes along with this is versioning based on git tags. If the current revision is a signed git tag, then that is the version of the package. If it is not, the version is equal to the most recent git tag, plus a commit count, plus a git sha (similar to git describe, but scrubbed for python version rules compliance) pbr updates are also part of the upcoming automation around ensuring global requirements stay in sync. Closes-Bug: #1179007 Change-Id: Ia473960be7e8aa44f09d48cea72ed3c8845f82fa
2013年05月11日 15:35:37 -04:00
bin/swift-dispersion-populate
bin/swift-dispersion-report
bin/swift-drive-audit
bin/swift-form-signature
bin/swift-get-nodes
bin/swift-init
bin/swift-object-auditor
bin/swift-object-expirer
bin/swift-object-info
bin/swift-object-replicator
Erasure Code Reconstructor This patch adds the erasure code reconstructor. It follows the design of the replicator but: - There is no notion of update() or update_deleted(). - There is a single job processor - Jobs are processed partition by partition. - At the end of processing a rebalanced or handoff partition, the reconstructor will remove successfully reverted objects if any. And various ssync changes such as the addition of reconstruct_fa() function called from ssync_sender which performs the actual reconstruction while sending the object to the receiver Co-Authored-By: Alistair Coles <alistair.coles@hp.com> Co-Authored-By: Thiago da Silva <thiago@redhat.com> Co-Authored-By: John Dickinson <me@not.mn> Co-Authored-By: Clay Gerrard <clay.gerrard@gmail.com> Co-Authored-By: Tushar Gohad <tushar.gohad@intel.com> Co-Authored-By: Samuel Merritt <sam@swiftstack.com> Co-Authored-By: Christian Schwede <christian.schwede@enovance.com> Co-Authored-By: Yuan Zhou <yuan.zhou@intel.com> blueprint ec-reconstructor Change-Id: I7d15620dc66ee646b223bb9fff700796cd6bef51
2014年10月28日 09:51:06 -07:00
bin/swift-object-reconstructor
Migrate to pbr for build pbr is the libification of what was openstack.common.setup. If provides the build information in a delcarative form, instead of as executable python code, which works around the chicken and egg problem of needing setup libraries present to run setup, but needing to run setup to tell if you need setup libraries. One of the features that comes along with this is versioning based on git tags. If the current revision is a signed git tag, then that is the version of the package. If it is not, the version is equal to the most recent git tag, plus a commit count, plus a git sha (similar to git describe, but scrubbed for python version rules compliance) pbr updates are also part of the upcoming automation around ensuring global requirements stay in sync. Closes-Bug: #1179007 Change-Id: Ia473960be7e8aa44f09d48cea72ed3c8845f82fa
2013年05月11日 15:35:37 -04:00
bin/swift-object-server
bin/swift-object-updater
bin/swift-oldies
bin/swift-orphans
bin/swift-proxy-server
bin/swift-recon
Migrate to pbr for build pbr is the libification of what was openstack.common.setup. If provides the build information in a delcarative form, instead of as executable python code, which works around the chicken and egg problem of needing setup libraries present to run setup, but needing to run setup to tell if you need setup libraries. One of the features that comes along with this is versioning based on git tags. If the current revision is a signed git tag, then that is the version of the package. If it is not, the version is equal to the most recent git tag, plus a commit count, plus a git sha (similar to git describe, but scrubbed for python version rules compliance) pbr updates are also part of the upcoming automation around ensuring global requirements stay in sync. Closes-Bug: #1179007 Change-Id: Ia473960be7e8aa44f09d48cea72ed3c8845f82fa
2013年05月11日 15:35:37 -04:00
bin/swift-recon-cron
bin/swift-ring-builder
Add ring-builder analyzer. This is a tool to help developers quantify changes to the ring builder. It takes a scenario (JSON file) describing the builder's basic parameters (part_power, replicas, etc.) and a number of "rounds", where each round is a set of operations to perform on the builder. For each round, the operations are applied, and then the builder is rebalanced until it reaches a steady state. The idea is that a developer observes the ring builder behaving suboptimally, writes a scenario to reproduce the behavior, modifies the ring builder to fix it, and references the scenario with the commit so that others can see that things have improved. I decided to write this after writing my fourth or fifth hacky one-off script to reproduce some bad behavior in the ring builder. Change-Id: I114242748368f142304aab90a6d99c1337bced4c
2015年06月11日 15:40:28 -07:00
bin/swift-ring-builder-analyzer
Migrate to pbr for build pbr is the libification of what was openstack.common.setup. If provides the build information in a delcarative form, instead of as executable python code, which works around the chicken and egg problem of needing setup libraries present to run setup, but needing to run setup to tell if you need setup libraries. One of the features that comes along with this is versioning based on git tags. If the current revision is a signed git tag, then that is the version of the package. If it is not, the version is equal to the most recent git tag, plus a commit count, plus a git sha (similar to git describe, but scrubbed for python version rules compliance) pbr updates are also part of the upcoming automation around ensuring global requirements stay in sync. Closes-Bug: #1179007 Change-Id: Ia473960be7e8aa44f09d48cea72ed3c8845f82fa
2013年05月11日 15:35:37 -04:00
bin/swift-temp-url
[entry_points]
paste.app_factory =
proxy = swift.proxy.server:app_factory
object = swift.obj.server:app_factory
mem_object = swift.obj.mem_server:app_factory
Migrate to pbr for build pbr is the libification of what was openstack.common.setup. If provides the build information in a delcarative form, instead of as executable python code, which works around the chicken and egg problem of needing setup libraries present to run setup, but needing to run setup to tell if you need setup libraries. One of the features that comes along with this is versioning based on git tags. If the current revision is a signed git tag, then that is the version of the package. If it is not, the version is equal to the most recent git tag, plus a commit count, plus a git sha (similar to git describe, but scrubbed for python version rules compliance) pbr updates are also part of the upcoming automation around ensuring global requirements stay in sync. Closes-Bug: #1179007 Change-Id: Ia473960be7e8aa44f09d48cea72ed3c8845f82fa
2013年05月11日 15:35:37 -04:00
container = swift.container.server:app_factory
account = swift.account.server:app_factory
paste.filter_factory =
healthcheck = swift.common.middleware.healthcheck:filter_factory
crossdomain = swift.common.middleware.crossdomain:filter_factory
memcache = swift.common.middleware.memcache:filter_factory
ratelimit = swift.common.middleware.ratelimit:filter_factory
cname_lookup = swift.common.middleware.cname_lookup:filter_factory
catch_errors = swift.common.middleware.catch_errors:filter_factory
domain_remap = swift.common.middleware.domain_remap:filter_factory
staticweb = swift.common.middleware.staticweb:filter_factory
tempauth = swift.common.middleware.tempauth:filter_factory
keystoneauth = swift.common.middleware.keystoneauth:filter_factory
recon = swift.common.middleware.recon:filter_factory
tempurl = swift.common.middleware.tempurl:filter_factory
formpost = swift.common.middleware.formpost:filter_factory
name_check = swift.common.middleware.name_check:filter_factory
bulk = swift.common.middleware.bulk:filter_factory
container_quotas = swift.common.middleware.container_quotas:filter_factory
account_quotas = swift.common.middleware.account_quotas:filter_factory
proxy_logging = swift.common.middleware.proxy_logging:filter_factory
Move all DLO functionality to middleware This is for the same reason that SLO got pulled into middleware, which includes stuff like automatic retry of GETs on broken connection and the multi-ring storage policy stuff. The proxy will automatically insert the dlo middleware at an appropriate place in the pipeline the same way it does with the gatekeeper middleware. Clusters will still support DLOs after upgrade even with an old config file that doesn't mention dlo at all. Includes support for reading config values from the proxy server's config section so that upgraded clusters continue to work as before. Bonus fix: resolve 'after' vs. 'after_fn' in proxy's required filters list. Having two was confusing, so I kept the more-general one. DocImpact blueprint multi-ring-large-objects Change-Id: Ib3b3830c246816dd549fc74be98b4bc651e7bace
2013年11月21日 17:31:16 -08:00
dlo = swift.common.middleware.dlo:filter_factory
Migrate to pbr for build pbr is the libification of what was openstack.common.setup. If provides the build information in a delcarative form, instead of as executable python code, which works around the chicken and egg problem of needing setup libraries present to run setup, but needing to run setup to tell if you need setup libraries. One of the features that comes along with this is versioning based on git tags. If the current revision is a signed git tag, then that is the version of the package. If it is not, the version is equal to the most recent git tag, plus a commit count, plus a git sha (similar to git describe, but scrubbed for python version rules compliance) pbr updates are also part of the upcoming automation around ensuring global requirements stay in sync. Closes-Bug: #1179007 Change-Id: Ia473960be7e8aa44f09d48cea72ed3c8845f82fa
2013年05月11日 15:35:37 -04:00
slo = swift.common.middleware.slo:filter_factory
list_endpoints = swift.common.middleware.list_endpoints:filter_factory
Generic means for persisting system metadata. Middleware or core features may need to store metadata against accounts or containers. This patch adds a generic mechanism for system metadata to be persisted in backend databases, without polluting the user metadata namespace, by using the reserved header namespace x-<server_type>-sysmeta-*. Modifications are firstly that backend servers persist system metadata headers alongside user metadata and other system state. For accounts and containers, system metadata in PUT and POST requests is treated in a similar way to user metadata. System metadata is not yet supported for object requests. Secondly, changes in the proxy controllers ensure that headers in the system metadata namespace will pass through in requests to backend servers. Thirdly, system metadata returned from backend servers in GET or HEAD responses is added to the cached info dict, which middleware can access. Finally, a gatekeeper middleware module is provided which filters all system metadata headers from requests and responses by removing headers with names starting x-account-sysmeta-, x-container-sysmeta-. The gatekeeper also removes headers starting x-object-sysmeta- in anticipation of future support for system metadata being set for objects. This prevents clients from writing or reading system metadata. The required_filters list in swift/proxy/server.py is modified to include the gatekeeper middleware so that if the gatekeeper has not been configured in the pipeline then it will be automatically inserted close to the start of the pipeline. blueprint cluster-federation Change-Id: I80b8b14243cc59505f8c584920f8f527646b5f45
2013年12月03日 22:02:39 +00:00
gatekeeper = swift.common.middleware.gatekeeper:filter_factory
New container sync configuration option Summary of the new configuration option: The cluster operators add the container_sync middleware to their proxy pipeline and create a container-sync-realms.conf for their cluster and copy this out to all their proxy and container servers. This file specifies the available container sync "realms". A container sync realm is a group of clusters with a shared key that have agreed to provide container syncing to one another. The end user can then set the X-Container-Sync-To value on a container to //realm/cluster/account/container instead of the previously required URL. The allowed hosts list is not used with this configuration and instead every container sync request sent is signed using the realm key and user key. This offers better security as source hosts can be faked much more easily than faking per request signatures. Replaying signed requests, assuming it could easily be done, shouldn't be an issue as the X-Timestamp is part of the signature and so would just short-circuit as already current or as superceded. This also makes configuration easier for the end user, especially with difficult networking situations where a different host might need to be used for the container sync daemon since it's connecting from within a cluster. With this new configuration option, the end user just specifies the realm and cluster names and that is resolved to the proper endpoint configured by the operator. If the operator changes their configuration (key or endpoint), the end user does not need to change theirs. DocImpact Change-Id: Ie1704990b66d0434e4991e26ed1da8b08cb05a37
2013年12月08日 09:13:59 +00:00
container_sync = swift.common.middleware.container_sync:filter_factory
xprofile = swift.common.middleware.xprofile:filter_factory
Migrate to pbr for build pbr is the libification of what was openstack.common.setup. If provides the build information in a delcarative form, instead of as executable python code, which works around the chicken and egg problem of needing setup libraries present to run setup, but needing to run setup to tell if you need setup libraries. One of the features that comes along with this is versioning based on git tags. If the current revision is a signed git tag, then that is the version of the package. If it is not, the version is equal to the most recent git tag, plus a commit count, plus a git sha (similar to git describe, but scrubbed for python version rules compliance) pbr updates are also part of the upcoming automation around ensuring global requirements stay in sync. Closes-Bug: #1179007 Change-Id: Ia473960be7e8aa44f09d48cea72ed3c8845f82fa
2013年05月11日 15:35:37 -04:00
2010年07月14日 09:46:14 -05:00
[build_sphinx]
2010年07月19日 11:22:40 -05:00
all_files = 1
build-dir = doc/build
2010年07月14日 09:46:14 -05:00
source-dir = doc/source
2010年07月19日 11:22:40 -05:00
[egg_info]
tag_build =
2010年07月19日 11:22:40 -05:00
tag_date = 0
tag_svn_revision = 0
2011年01月27日 00:01:24 +00:00
[compile_catalog]
directory = swift/locale
2011年01月27日 00:01:24 +00:00
domain = swift
[update_catalog]
domain = swift
output_dir = swift/locale
input_file = swift/locale/swift.pot
2011年01月27日 00:01:24 +00:00
[extract_messages]
keywords = _ l_ lazy_gettext
mapping_file = babel.cfg
output_file = swift/locale/swift.pot
Add support for venv-based test run with tox. * Adds tox config - based on the config from python-quantumclient and updated for test, pep8 and coverage execution as per nova's run_tests.sh. * Adds nosetests defaults in setup.cfg * Adds runtime dependencies in tools/pip-requires - dependencies were gathered by referencing the packages used in creation of a Swift All In One. Versions were determined by checking the swift-core/trunk ppa or, failing that, the version available in lucid. * Adds test dependencies in tools/test-requires * Updates swift/common/middleware/formpost.py for pep8 compliance * Adds instructions for executing the tests with Tox to the developer_guidelines * Adds instructions for installing openstack.nose_plugin to developer_saio * Fixes bug 909177 Change-Id: I5407924d2181e9ab335aaf76bf30c8d40deccbb4
2012年01月31日 15:27:29 -08:00
[nosetests]
exe = 1
verbosity = 2
detailed-errors = 1
cover-package = swift
cover-html = true
cover-erase = true