Ceilometer/blueprints/pollster-swift

Use Cases

 * Provider wants to retrieve data about swift usage to bill his customers
 * Customer wants to monitor his usage of swift

Proposed implementation
The following is a first list of meters that needs to be collected in order to allow billing systems to perform their tasks on swift. This list must be expandable over time and each administrator must have the possibility to enable or disable each meter based on his local needs

The counters o1 to o5 must be implemented through polling of Swift.

For polling Swift, there exists 2 way:

1. Go through swift-proxy as an user with ResellerAdmin role on one of this tenant, using this tenant to get a token

2. Use the ring to determine the right swift- -server and request information from it directly. The swift-account-server can provides number and size of objects stored in all containers, and the number of containers, and the list of container. The swift-container-server can provides number number of objects and size of each container.

Option 1 should be simpler and cleaner in a first time, but puts more load on Keystone. Option 2 could be preferred, if implemented, via an option.

The counters o6 to o21 should be implemented via a Swift middleware counting requests and their size and publishing counters regularly.

To distinguish network, it is suggested that we start this implementation by using a configuration file listing internal networks, which by default should list A, B and C private network class (RFC 1918).