# Contributing to OpenStack Swift

## Who is a Contributor?

Put simply, if you improve Swift, you’re a contributor. The easiest way to improve the project is to tell us where there’s a bug. In other words, filing a bug is a valuable and helpful way to contribute to the project.

Once a bug has been filed, someone will work on writing a patch to fix the bug. Perhaps you’d like to fix a bug. Writing code to fix a bug or add new functionality is tremendously important.

Once code has been written, it is submitted upstream for review. All code, even that written by the most senior members of the community, must pass code review and all tests before it can be included in the project. Reviewing proposed patches is a very helpful way to be a contributor.

Swift is nothing without the community behind it. We’d love to welcome you to our community. Come find us in #openstack-swift on OFTC IRC or on the OpenStack dev mailing list.

For general information on contributing to OpenStack, please check out the contributor guide to get started. It covers all the basics that are common to all OpenStack projects: the accounts you need, the basics of interacting with our Gerrit review system, how we communicate as a community, etc.

For more project information, feel free to check out the Swift documentation.

### Filing a Bug

Filing a bug is the easiest way to contribute. You can find currently-tracked bugs on our Launchpad. Use the Report a bug link to file a new bug.

If you find something in Swift that doesn’t match the documentation or doesn’t meet your expectations with how it should work, please let us know. Of course, if you ever get an error (like a Traceback message in the logs), we definitely want to know about that. We’ll do our best to diagnose any problem and patch it as soon as possible.

A bug report, at minimum, should describe what you were doing that caused the bug. “Swift broke, pls fix” is not helpful. Instead, something like “When I restarted syslog, Swift started logging traceback messages” is very helpful. The goal is that we can reproduce the bug and isolate the issue in order to apply a fix. If you don’t have full details, that’s ok. Anything you can provide is helpful.

You may have noticed that there are many tracked bugs, but not all of them have been confirmed. If you take a look at an old bug report and you can reproduce the issue described, please leave a comment on the bug about that. It lets us all know that the bug is very likely to be valid.

### Reviewing Someone Else’s Code

All code reviews in OpenStack projects are done on our Gerrit instance at review.opendev.org. Reviewing patches is one of the most effective ways you can contribute to the community.

We’ve written a set of Review Guidelines to help you give good reviews.

To find out what reviews are priortiy in the community, you can read Priority Reviews on our wiki.

## What do I work on?

If you’re looking for a way to write and contribute code, but you’re not sure what to work on, check out the “wishlist” bugs in the bug tracker. These are normally smaller items that someone took the time to write down but didn’t have time to implement.

And please join #openstack-swift on OFTC IRC to tell us what you’re working on.

## Getting Started

https://docs.openstack.org/swift/latest/first_contribution_swift.html

Once those steps have been completed, changes to OpenStack should be submitted for review via the Gerrit tool, following our Development Workflow.

Gerrit is the review system used in the OpenStack projects. We’re sorry, but we won’t be able to respond to pull requests submitted through GitHub.

Bugs should be filed on Launchpad, not in GitHub’s issue tracker.

# Swift Design Principles

- The Zen of Python

- Simple Scales

- Minimal dependencies

- Re-use existing tools and libraries when reasonable

- Leverage the economies of scale

- Small, loosely coupled RESTful services

- No single points of failure

- Start with the use case

- … then design from the cluster operator up

- If you haven’t argued about it, you don’t have the right answer yet :)

- If it is your first implementation, you probably aren’t done yet :)

Please don’t feel offended by difference of opinion. Be prepared to advocate for your change and iterate on it based on feedback. Reach out to other people working on the project on IRC or the mailing list - we want to help.

# Recommended workflow

- Set up a Swift All-In-One VM(SAIO).

- Make your changes. Docs and tests for your patch must land before or with your patch.

- Run unit tests, functional tests, probe tests `./.unittests` `./.functests` `./.probetests`

- Run `tox` (no command-line args needed)

- `git review`

# Notes on Testing

Running the tests above against Swift in your development environment (ie your SAIO) will catch most issues. Any patch you propose is expected to be both tested and documented and all tests should pass.

If you want to run just a subset of the tests while you are developing, you can use pytest:

    cd test/unit/common/middleware/ && pytest test_healthcheck.py

To check which parts of your code are being exercised by a test, you can run tox and then point your browser to swift/cover/index.html:

    tox -e py3 -- test.unit.common.middleware.test_healthcheck:TestHealthCheck.test_healthcheck

Swift’s unit tests are designed to test small parts of the code in isolation. The functional tests validate that the entire system is working from an external perspective (they are “black-box” tests). You can even run functional tests against public Swift endpoints. The probetests are designed to test much of Swift’s internal processes. For example, a test may write data, intentionally corrupt it, and then ensure that the correct processes detect and repair it.

When your patch is submitted for code review, it will automatically be tested on the OpenStack CI infrastructure. In addition to many of the tests above, it will also be tested by several other OpenStack test jobs.

Once your patch has been reviewed and approved by core reviewers and has passed all automated tests, it will be merged into the Swift source tree.

# Ideas

https://wiki.openstack.org/wiki/Swift/ideas

If you’re working on something, it’s a very good idea to write down what you’re thinking about. This lets others get up to speed, helps you collaborate, and serves as a great record for future reference. Write down your thoughts somewhere and put a link to it here. It doesn’t matter what form your thoughts are in; use whatever is best for you. Your document should include why your idea is needed and your thoughts on particular design choices and tradeoffs. Please include some contact information (ideally, your IRC nick) so that people can collaborate with you.

# Community

## Communication

IRC

  People working on the Swift project may be found in the `#openstack-swift` channel on OFTC during working hours in their timezone. The channel is logged, so if you ask a question when no one is around, you can check the log to see if it’s been answered.

weekly meeting

  This is a Swift team meeting. The discussion in this meeting is about all things related to the Swift project:

- time: http://eavesdrop.openstack.org/#Swift_Team_Meeting

- agenda: https://wiki.openstack.org/wiki/Meetings/Swift

mailing list

  We use the openstack-discuss@lists.openstack.org mailing list for asynchronous discussions or to communicate with other OpenStack teams. Use the prefix `[swift]` in your subject line (it’s a high-volume list, so most people use email filters).

  You can use our mailing list info page to read the archives and subscribe.

## Contacting the Core Team

The swift-core team is an active group of contributors who are responsible for directing and maintaining the Swift project. As a new contributor, your interaction with this group will be mostly through code reviews, because only members of swift-core can approve a code change to be merged into the code repository. But the swift-core team also spend time on IRC so feel free to drop in to ask questions or just to meet us.

Note

Although your contribution will require reviews by members of swift-core, these aren’t the only people whose reviews matter. Anyone with a gerrit account can post reviews, so you can ask other developers you know to review your code … and you can review theirs. (A good way to learn your way around the codebase is to review other people’s patches.)

If you’re thinking, “I’m new at this, how can I possibly provide a helpful review?”, take a look at How to Review Changes the OpenStack Way.

Or for more specifically in a Swift context read Review Guidelines

You can read about the role of core reviewers in the OpenStack governance documentation, learn more about the swift-core members in our gerrit membership list, and also find the team at our Swift weekly meetings.

## Getting Your Patch Merged

Understanding how reviewers review and what they look for will help getting your code merged. See Swift Review Guidelines for how we review code.

Keep in mind that reviewers are also human; if something feels stalled, then come and poke us on IRC or add it to our meeting agenda.

## Project Team Lead Duties

All common PTL duties are enumerated in the PTL guide.

this page last updated: 2026-04-08 16:47:21

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

found an error? report a bug