Guide: Project and Quota: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
➡️ '''Back to the FAQ for [[Projects and Quota]].''' | ➡️ '''Back to the FAQ for [[Projects and Quota]].''' | ||
Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage | |||
== Project and eligibility == | == Project and eligibility == | ||
Before a quota can be set for a project, in advance an [[Guide: Entitlement & Eligibility|entitlement/ eligibility]] needs to be granted to the project owner. | |||
* Each project is associated with an eligibility hold by the owner of the project. | * Each project is associated with an eligibility hold by the owner of the project. | ||
Revision as of 16:17, 2 February 2026
➡️ Back to the FAQ for Projects and Quota.
Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage
Project and eligibility
Before a quota can be set for a project, in advance an entitlement/ eligibility needs to be granted to the project owner.
- Each project is associated with an eligibility hold by the owner of the project.
- The maximal quota a user can request is restricted by the quota flavor of his/her eligibility.
List of quota flavors
The supported quota packages are described in the table below.
| quota flavor | Note |
|---|---|
| empty | Default case. User can’t generate costs. See empty eligibility. |
| tiny_1 | |
| xtiny_1 | |
| medium_1 | |
| xmedium_1 | |
| large_1 | |
| xlarge_1 | |
| custom | User can choose the quota to be requested. |
Each quota flavor is associated with resources granted to projects.
| quota flavor | instances | cores | ram_gb | volumes | volumes_gb | backups | backups_gb | networks | subnets | routers | floating_ips | security_groups | snapshots |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| empty | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 20 | 0 |
| tiny_1 | 1 | 1 | 1 | 10 | 100 | 30 | 300 | 10 | 10 | 1 | 0 | 20 | 10 |
| xtiny_1 | 2 | 2 | 2 | 10 | 100 | 30 | 300 | 10 | 10 | 1 | 0 | 20 | 10 |
| medium_1 | 4 | 4 | 4 | 20 | 200 | 60 | 600 | 10 | 10 | 1 | 1 | 20 | 20 |
| xmedium_1 | 8 | 8 | 8 | 20 | 200 | 60 | 600 | 10 | 10 | 1 | 1 | 20 | 20 |
| large_1 | 16 | 16 | 16 | 40 | 400 | 120 | 1200 | 20 | 20 | 2 | 2 | 20 | 40 |
| xlarge_1 | 32 | 32 | 32 | 40 | 400 | 120 | 1200 | 20 | 20 | 2 | 2 | 20 | 40 |
| custom | * | * | * | * | * | * | * | * | * | * | * | * |
Examples
Project and eligibility examples
Example project and eligibility 1
In the illustration is a life cycle for a project presented.
- First, User I registers for the bwCloud-OS. At this moment, he/she is holding one Eligibility A. Automatic is a start project with a quota created. Only User I is member of this project.
- Later on, the user holds an additional and larger Eligibility B, granted by his/her home organization. After a request for quota change more quota is granted, and the link for the associated eligibility is updated.
- User II holds no eligibility; hence, he/she can login to the bwCloud-OS, but can't use compute resources. User I wants to share the resources of start project I with User II. After the request for a new project member, User II is also able use compute resources.
