- Launchpad Entry: SwiftSpec:storage-quota
- Created: 1 Mar 2012
- Contributors: Everett Toews
In some deployment scenarios, such as a private cloud, the provider may want to limit the tenants (accounts)/users to a maximum allowable amount of storage via a quota.
A storage quota prevents accounts/users from using more than their allowed storage.
A storage quota of 0 indicates unlimited storage for an account/user.
This is necessary for providers that cannot simply add disk at will as storage usage grows. There are any number of factors that may prevent a provider from being able to easily add disk.
- User1: <quota> (<derived quota>)
- User2: <quota> (<derived quota>)
1. User Quota Storage
- User1: 0
- User2: 6
When the account has a zero value, the quota is determined strictly by the user value.
2. Evenly Distributed Storage
- User1: 0 (3)
- User2: 0 (3)
When an account has a non-zero value and all users in that account have a zero value, the account storage is evenly distributed amongst the users.
3. Evenly Distributed Remainder Storage
- User1: 0 (2)
- User2: 0 (2)
- User3: 2
When an account has a non-zero value and some (not all) users in that account have a zero value, the remainder of the account storage is evenly distributed amongst the users with a zero value.
4. Sum Total Storage
- User1: 4
- User2: 2
When the sum of all of the user values totals to the account value, the quota is determined strictly by the user value.
5. Under-Sum Total Storage
- User1: 2
- User2: 2
When the sum of all of the user values is less than the account value, the quota is determined strictly by the user value.
6. Over-Sum Total Storage
- User1: 4
- User2: 4
When the sum of all of the user values is greater than the account value, this is a counter example and should not be allowed.
Note: After writing out all of these use cases I could easily be convinced that really only cases 1 and 2 are allowed (at least to begin with).
The quota values is stored per account and per user. All values are in GBs.
The Swift CLI will need to be able to CRUD quotas for accounts and users.
Code changes should include an overview of what needs to change, and in some cases even the specific details.
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.
This need not be added or completed until the specification is nearing beta.
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.