Entitlements in bwCloud-OS: Difference between revisions

From bwCloud-OS
Jump to navigation Jump to search
No edit summary
No edit summary
 
(20 intermediate revisions by the same user not shown)
Line 3: Line 3:
|}
|}
{| class="mw-message-box mw-message-box-info"
{| class="mw-message-box mw-message-box-info"
| style="vertical-align:middle;" | This page is about the entitlements for the bwCloud-OS NG. Please visit [[entitlements for bwCloud-SCOPE]] for the legacy information.
| style="vertical-align:middle;" | This page is about the entitlements for the bwCloud-OS (Gen3). Please visit [[entitlements for bwCloud-SCOPE|entitlements for bwCloud-OS (Gen2)]] for the legacy information.
|}
|}


Entitlements in bwCloud-OS define '''who can access the platform''' ([[Entitlements in bwCloud-OS#Access Control|Access Control]]), '''how many resources they may use''' ([[Entitlements in bwCloud-OS#Quota flavors|Quota flavors]]), and '''under what conditions''' ([[Entitlements in bwCloud-OS#Eligibility|Eligibility]]).  
Entitlements in bwCloud-OS define '''who can access the platform''' ([[Entitlements in bwCloud-OS#Access Control|Access Control]]), '''how many resources they may use''' ([[Entitlements in bwCloud-OS#Quota flavors|Quota flavors]]), and '''under what conditions''' ([[Entitlements in bwCloud-OS#Eligibility|Eligibility]]).  


* Every entitlement contains an [[Entitlements in bwCloud-OS#Eligibility|eligibility]].
* Every user owns at least the empty entitlement, even if not directly specified.
* Every user owns at least the empty entitlement, even if not directly specified.
* Every [[Projects and Quota|project]] needs to be linked with an eligibility.


Every member of a higher education institution in Baden-Württemberg has a personal account. If the institution participates in the federated identity management system ('''bwIDM'''), its members can also apply for the external service bwCloud-OS, by providing additional information. This is handled through the assignment of <code>eduPersonEntitlement</code> to the user's account.
Every member of a higher education institution in Baden-Württemberg has a personal account. If the institution participates in the federated identity management system ('''bwIDM'''), its members can also apply for the external service bwCloud-OS, by providing additional information. This is handled through the assignment of <code>eduPersonEntitlement</code> to the user's account.
Line 20: Line 22:


=== Access Control ===
=== Access Control ===
For [[registration]] to the bwCloud-OS [[several criterias]] need to be fulfilled. By rolling out the [[Entitlements in bwCloud-OS#Special Entitlements|access entitlement]] home organization can manage by themselves who is allowed to access the bwCloud-OS.
For [[registration]] to the bwCloud-OS [[Access and Usage|several criterias]] need to be fulfilled. By rolling out the [[Entitlements in bwCloud-OS#Special Entitlements|access entitlement]] home organization can manage by themselves who is allowed to access the bwCloud-OS.


=== Automated registration ===
=== Automated registration ===
[[Registration]] and  is streamlined through entitlements:
Registration is streamlined through entitlements:
* Entitlements are automatically evaluated during registration.
* Entitlements are automatically evaluated during registration.
* Users receive immediate access and resources once their entitlement is confirmed. No manual activation is required.
* Users receive immediate access and resources ([[Projects and Quota|project quota]]) once their entitlement is confirmed. No manual activation is required.
 
=== Charging ===
All consumptions within the bwCloud-OS, within projects, are charged. Hence, for each project, a [[Charging|customer]] is required, which differs from the user or owner.
 
[[Charging]] will be based on the projects [[booking units]] (BEH) and will be addressed to the [[Projects and Quota|project owner]]'s home organization.  


=== Delegating resposibility ===
=== Delegating resposibility ===
Line 31: Line 38:


=== Reimbursement ===
=== Reimbursement ===
Entitlements also help define who is financially responsible for produced [[booking units]] (BEH).
Entitlements also help define who is financially responsible for produced BEH.
* Defining cost centers to separate costs into different cost positions, allowing institutions to reimburse the costs internally.  
* Defining cost centers to separate costs into different cost positions, allowing institutions to reimburse the costs internally.  


Line 45: Line 52:


=== Quota Entitlements ===
=== Quota Entitlements ===
A quota entitlement persists out of two parts, the namespace and the identifier ([[Entitlements in bwCloud-OS#Eligibility|eligibility]]):
A quota entitlement persists out of two parts, the namespace and the identifier (eligibility):
  <nowiki>urn:geant:bwcloud-os.de:group:ELIGIBILITY</nowiki>
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' The namespace is yet not registered and may change.
|}
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:group:ELIGIBILITY</nowiki>
bzw.
bzw.
  <nowiki>urn:geant:bwcloud-os.de:group</nowiki>:<quota_flavor>:<cost_center_id>[:<first_day_of_validation|null>:<last_day_of_validation|null>:<max_booking_units|null>]
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:group</nowiki>:<quota_flavor>:<cost_center_id>[:<first_day_of_validation|null>:<last_day_of_validation|null>:<max_booking_units|null>]
The syntax for valid entitlement identifiers is described in the sections below.
The syntax for valid entitlement identifiers is described in the sections below.


=== Special Entitlements ===
=== Special Entitlements ===
There is also a special entitlement ''bwcloudos_access'', which determines whether a user is allowed to access the bwCloud-OS at all.
There is also a special entitlement ''access'', which determines whether a user is allowed to access the bwCloud-OS at all.
  <nowiki>urn:geant:bwcloud-os.de:bwcloudos_access</nowiki>
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' The namespace is yet not registered and may change.
|}
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:access</nowiki>
{| class="wikitable"
{| class="wikitable"
!permition
!permition
!Note
!Note
|-
|-
|bwcloudos_access
|access
|Allows the registration for the bwCloud-OS via RegApp
|Allows the registration for the bwCloud-OS via RegApp
|}
|}


== Eligibility ==
== Eligibility ==
Every [[Projects and Quota|project]] is associated with an entitlement, making sure the project is chargeable.
Every project is associated with an entitlement, making sure the project is chargeable.


* An eligibility is a unique combination of owner, quota flavor, and cost center.
* An eligibility is a unique combination of owner, quota flavor, and cost center.
* An eligibility can be assigned to a maximum of one project. The eligibility-project association is therefore unique.
* An eligibility can be assigned to a maximum of one project. The eligibility-project association is therefore unique.
* A limit value for BEH and validation dates may be set to restrict the duration of an eligibility.
* A limit value for BEH and validation dates may be set to restrict the duration of an eligibility.
[[File:Example eligibiliy cost center.drawio.png|thumb|322x322px|Example for eligibility cost centers]]
=== Example eligibility usage ===
The example in the image to the left demonstrates how costs can be accumulated based on cost centers. 
=== Structure ===
=== Structure ===
Optionally, the following structure for Eli may be used to provide further information and define conditions for the quota flavor.
Optionally, the following structure for Eli may be used to provide further information and define constraints for the quota flavor:
<quota_flavor>:<cost_center_id>[:CONSTRAINTS]
respectively
  <quota_flavor>:<cost_center_id>[:<first_day_of_validation|null>:<last_day_of_validation|null>:<max_booking_units|null>]
  <quota_flavor>:<cost_center_id>[:<first_day_of_validation|null>:<last_day_of_validation|null>:<max_booking_units|null>]


Line 88: Line 99:
!Note
!Note
|-
|-
|bwcloudos_empty
|empty
|Default case. User can’t generate costs.
|Default case. User can’t generate costs.
|-
|-
|bwcloudos_tiny_1
|tiny_1
|
|
|-
|-
|bwcloudos_xtiny_1
|xtiny_1
|
|
|-
|-
|bwcloudos_medium_1
|medium_1
|
|
|-
|-
|bwcloudos_xmedium_1
|xmedium_1
|
|
|-
|-
|bwcloudos_large_1
|large_1
|
|
|-
|-
|bwcloudos_xlarge_1
|xlarge_1
|
|
|-
|-
|bwcloudos_custom
|custom
|User can choose the quota to be requested.
|User can choose the quota to be requested.
|}
|}
Line 128: Line 139:
!'''floating_ips'''
!'''floating_ips'''
|-
|-
|'''bwcloudos_empty'''
|'''empty'''
|0
|0
|0
|0
Line 141: Line 152:
|0
|0
|-
|-
|'''bwcloudos_tiny_1'''
|'''tiny_1'''
|1
|1
|1
|1
Line 154: Line 165:
|0
|0
|-
|-
|'''bwcloudos_xtiny_1'''
|'''xtiny_1'''
|2
|2
|2
|2
Line 167: Line 178:
|0
|0
|-
|-
|'''bwcloudos_medium_1'''
|'''medium_1'''
|4
|4
|4
|4
Line 180: Line 191:
|1
|1
|-
|-
|'''bwcloudos_xmedium_1'''
|'''xmedium_1'''
|8
|8
|8
|8
Line 193: Line 204:
|1
|1
|-
|-
|'''bwcloudos_large_1'''
|'''large_1'''
|16
|16
|16
|16
Line 206: Line 217:
|2
|2
|-
|-
|'''bwcloudos_xlarge_1'''
|'''xlarge_1'''
|32
|32
|32
|32
Line 219: Line 230:
| valign="top" |2
| valign="top" |2
|-
|-
|'''bwcloudos_custom'''
|'''custom'''
|*
|*
|*
|*
Line 234: Line 245:


=== Cost centers ===
=== Cost centers ===
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' The cost center can be a random string, making only sense to the home organization.
|}
Cost centers are used to allocate BEH generated within projects. This string does not need to be agreed upon with us and does not need to have any meaning outside the institution.
Cost centers are used to allocate BEH generated within projects. This string does not need to be agreed upon with us and does not need to have any meaning outside the institution.


* A cost center can be assigned to multiple eligibilities and users.
* A cost center (id) can be assigned to multiple eligibilities and users.
* BEH are aggregated per cost center across all projects assigned to the cost center.
* BEH are aggregated per cost center across all projects assigned to the cost center.
* The assignment of cost centers enables customers to pass on costs (internally).
* The assignment of cost centers enables customers to pass on costs (internally).
For a cost center, only the symbols <code>[a-zA-Z0-9-_]</code> and a maximal length of 50 characters are allowed.


=== First day of validation  (NOT supported yet) ===
=== First day of validation  (NOT supported yet) ===
Line 247: Line 262:


=== Maximal number of booking units (NOT supported yet) ===
=== Maximal number of booking units (NOT supported yet) ===
Integer (<code>>0</code>), that defines the maximum number of BEH that can be generated by the associated project. If the number is not given or <code>null</code>, the default behavior is: Eligibility is forever valid. '''This feature is currently not supported.'''
Integer, that defines the maximum number of BEH that can be generated by the associated project. If the number is not given or <code>null</code>, the default behavior is: Eligibility is forever valid. The number of booking units must be at least <code>200</code>. '''This feature is currently not supported.'''


== Example Entitlement ==
== Examples ==


==== Example 1 ====
=== Entitlement ===
 
==== Example entitlement 1 ====
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' The namespace is yet not registered and may change.
|}
Granting a user a request quota for a project up to the medium flavor. All generated booking units will be charged under the bill position ''42.''
Granting a user a request quota for a project up to the medium flavor. All generated booking units will be charged under the bill position ''42.''
  <nowiki>urn:geant:bwcloud-os.de:group:bwcloudos_medium_1:42</nowiki>
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:group</nowiki>:'''medium_1:42'''
Interpreted as eligibility:
Interpreted as eligibility:
  quota_flavor = bwcloudos_medium_1
  quota_flavor = medium_1
  cost_center_id = 42
  cost_center_id = 42
  first_day_of_validation = <nowiki>{{today}}</nowiki>
  first_day_of_validation = <nowiki>{{today}}</nowiki>
  last_day_of_validation = inf
  last_day_of_validation = inf
  max_booking_units = inf
  max_booking_units = inf
owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>


==== Example 2 ====
==== Example entitlement 2 ====
Allow a user to request quota for a large project, but this is terminated up to the end of 2026 and can maximally produce <code>5000</code> booking units. The booking units for all projects with the cost center ''student'' will be charged under the same bill position''.''
Allow a user to request quota for a large project, but this is terminated up to the end of 2026 and can maximally produce <code>5000</code> BEH. The booking units for all projects with the cost center ''student'' will be charged under the same bill position''.''
  <nowiki>urn:geant:bwcloud-os.de:group:bwcloudos_large_1:student:null:2026-12-31:5000</nowiki>
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:group</nowiki>:'''large_1:student:null:2026-12-31:5000'''
Interpreted as eligibility:
Interpreted as eligibility:
  quota_flavor = bwcloudos_large_1
  quota_flavor = large_1
  cost_center_id = student
  cost_center_id = student
  first_day_of_validation = <nowiki>{{today}}</nowiki>
  first_day_of_validation = <nowiki>{{today}}</nowiki>
  last_day_of_validation = 31.12.2026
  last_day_of_validation = 31.12.2026
  max_booking_units = 5000
  max_booking_units = 5000
owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>


==== Example 3 ====
==== Example entitlement 3 ====
A xtiny project can be requested. The consumed booking units will aggregate under the position for the informatics faculty and can be used from February 2026 on for one year. Costs are allocated to cost center ''hfu_informatics_faculty''.
A xtiny project can be requested. The consumed booking units will aggregate under the position for the informatics faculty and can be used from February 2026 on for one year. Costs are allocated to cost center ''hfu_netze2''.
  <nowiki>urn:geant:bwcloud-os.de:group:bwcloudos_xtiny_1:hfu_informatics_faculty:2026-02-01:2027-02-01:null</nowiki>
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:group</nowiki>:'''xtiny_1:hfu_netze2:2026-02-01:2027-01-31:null'''
Interpreted as eligibility:
Interpreted as eligibility:
  quota_flavor = bwcloudos_xtiny_1
  quota_flavor = xtiny_1
  cost_center_id = hfu_informatics_faculty
  cost_center_id = hfu_netze2
  first_day_of_validation = 01.02.2026
  first_day_of_validation = 01.02.2026
  last_day_of_validation = 01.02.2027
  last_day_of_validation = 31.01.2027
  max_booking_units = inf
  max_booking_units = inf
owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>


==== Example 4 ====
==== Example entitlement 4 ====
A user with this entitlement will book the costs on the cost center ''hfu_informatics_faculty'' and must stop when the project consumed <code>1000000</code> BEH.
A user with this entitlement will book the costs on the cost center ''ufr_technical_faculty'' and must stop when the project consumes <code>1000000</code> BEH.
  <nowiki>urn:geant:bwcloud-os.de:group:bwcloudos_xmedium_1:hfu_informatics_faculty:null:null:1000000</nowiki>
  <nowiki>urn:geant:dfn.de:bwcloud-os.de:group:xmedium_1</nowiki>:'''ufr_technical_faculty:null:null:1000000'''
Interpreted as eligibility:
Interpreted as eligibility:
  quota_flavor = bwcloudos_large_1
  quota_flavor = large_1
  cost_center_id = hfu_informatics_faculty
  cost_center_id = ufr_technical_faculty
  first_day_of_validation = <nowiki>{{today}}</nowiki>
  first_day_of_validation = <nowiki>{{today}}</nowiki>
  last_day_of_validation = inf
  last_day_of_validation = inf
  max_booking_units = 1000000
  max_booking_units = 1000000
owner = <nowiki>{{user.eppn}}</nowiki>
customer = <nowiki>{{user.home_organization}}</nowiki>
=== Eligibility ===
==== Example eligibility 1 ====
The example in the image to the left demonstrates how costs can be accumulated based on cost centers. 
[[File:Example eligibiliy cost center.drawio.png|thumb|322x322px|Example for eligibility cost centers]]
== FAQ ==
=== What is the difference between flavor, quota, and quota flavors? ===
* [[Instances (VMs)|Flavor]] (or VM flavor) is a defined set of resources (core, RAM, storage) that be chosen as the size of an instance.
* [[Projects and Quota|Quota]] (or project quota) is the amount of resources (core, RAM, storage, network, volume, etc) a project ran consume or bind.
* [[Entitlements in bwCloud-OS#Quota flavors|Quota flavors]] is a defined set of project quotas that can be chosen as the size of a project.
=== How can I change the eligibility of a project? ===
If you currently own the project, you can request this via [https://bw-support.scc.kit.edu/ Ticket].
=== What entitlement do I need to become a member of an existing project? ===
If you can login to the bwCloud-OS, the owner of the project can request your membership via [https://bw-support.scc.kit.edu/ Ticket].
=== Can I use the same entitlement or eligibility for several projects? ===
No. A user with his eligibility can only be assigned to one project, <code>{0,1}:1</code> mapping.
=== I have an entitlement. How can I get a project with quota? ===
Only once, during the registration of a new user, automatically a (start-)project is created from a given eligibility. Afterward, a user needs to [[Projects and Quota|request]] a new project.

Latest revision as of 16:21, 8 January 2026

⚠️ Please Note: This page is currently under development.
This page is about the entitlements for the bwCloud-OS (Gen3). Please visit entitlements for bwCloud-OS (Gen2) for the legacy information.

Entitlements in bwCloud-OS define who can access the platform (Access Control), how many resources they may use (Quota flavors), and under what conditions (Eligibility).

  • Every entitlement contains an eligibility.
  • Every user owns at least the empty entitlement, even if not directly specified.
  • Every project needs to be linked with an eligibility.

Every member of a higher education institution in Baden-Württemberg has a personal account. If the institution participates in the federated identity management system (bwIDM), its members can also apply for the external service bwCloud-OS, by providing additional information. This is handled through the assignment of eduPersonEntitlement to the user's account.

All entitlements are issued and managed by the user’s home institution and play a central role in how the platform is used and funded. These decisions are made exclusively by the user's home institution. The bwCloud-OS team has no authority to grant access or resources without an official entitlement.

In a Nutshell
    An entitlement is given to users by the home organization and corresponds to the eligibility to generate costs.

Motivation

The bwCloud-OS negotiated only contracts with institutions (customers) but not with individual members (users). This is a crucial difference compared to other known cloud providers. Further are severe different types of sponsors (e.g., chairs, research projects) located at the institutes, granting sub-goups of members (users) more resources.

Access Control

For registration to the bwCloud-OS several criterias need to be fulfilled. By rolling out the access entitlement home organization can manage by themselves who is allowed to access the bwCloud-OS.

Automated registration

Registration is streamlined through entitlements:

  • Entitlements are automatically evaluated during registration.
  • Users receive immediate access and resources (project quota) once their entitlement is confirmed. No manual activation is required.

Charging

All consumptions within the bwCloud-OS, within projects, are charged. Hence, for each project, a customer is required, which differs from the user or owner.

Charging will be based on the projects booking units (BEH) and will be addressed to the project owner's home organization.

Delegating resposibility

The user’s home organization can define an interall process, so members can set entitlements in the home IdP.

Reimbursement

Entitlements also help define who is financially responsible for produced BEH.

  • Defining cost centers to separate costs into different cost positions, allowing institutions to reimburse the costs internally.
  • bwCloud-OS will generate aggregated usage reports and invoices per institution—no individual billing.

Budget

Sometimes resources should only be consumed up to a certain level or amount of time.

  • Constraints can be used to manage the valid period for eligibility.
  • After reaching an eligibility constraint, no more costs can be produced within the associated project.

Entitlement URN structure

Quota Entitlements

A quota entitlement persists out of two parts, the namespace and the identifier (eligibility):

⚠️ Please Note: The namespace is yet not registered and may change.
urn:geant:dfn.de:bwcloud-os.de:group:ELIGIBILITY

bzw.

urn:geant:dfn.de:bwcloud-os.de:group:<quota_flavor>:<cost_center_id>[:<first_day_of_validation|null>:<last_day_of_validation|null>:<max_booking_units|null>]

The syntax for valid entitlement identifiers is described in the sections below.

Special Entitlements

There is also a special entitlement access, which determines whether a user is allowed to access the bwCloud-OS at all.

⚠️ Please Note: The namespace is yet not registered and may change.
urn:geant:dfn.de:bwcloud-os.de:access
permition Note
access Allows the registration for the bwCloud-OS via RegApp

Eligibility

Every project is associated with an entitlement, making sure the project is chargeable.

  • An eligibility is a unique combination of owner, quota flavor, and cost center.
  • An eligibility can be assigned to a maximum of one project. The eligibility-project association is therefore unique.
  • A limit value for BEH and validation dates may be set to restrict the duration of an eligibility.

Structure

Optionally, the following structure for Eli may be used to provide further information and define constraints for the quota flavor:

<quota_flavor>:<cost_center_id>[:CONSTRAINTS]

respectively

<quota_flavor>:<cost_center_id>[:<first_day_of_validation|null>:<last_day_of_validation|null>:<max_booking_units|null>]

Quota flavors

A project flavor specifies the maximum resources a project may receive.

  • A quota flavor can be specified several times by using different cost centers. Each additional eligibility can be used for another project.
  • A user can have several quota flavors.

The supported quota packages are described in the table below.

List of supported quota flavors
quota flavor Note
empty Default case. User can’t generate costs.
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.

Resources associated with each quota flavor
Entitlement instances cores ram_gb volumes volumes_gb backups backups_gb networks subnets routers floating_ips
empty 0 0 0 0 0 0 0 0 0 0 0
tiny_1 1 1 1 10 100 30 300 10 10 1 0
xtiny_1 2 2 2 10 100 30 300 10 10 1 0
medium_1 4 4 4 20 200 60 600 10 10 1 1
xmedium_1 8 8 8 20 200 60 600 10 10 1 1
large_1 16 16 16 40 400 120 1200 20 20 2 2
xlarge_1 32 32 32 40 400 120 1200 20 20 2 2
custom * * * * * * * * * * *

Cost centers

⚠️ Please Note: The cost center can be a random string, making only sense to the home organization.

Cost centers are used to allocate BEH generated within projects. This string does not need to be agreed upon with us and does not need to have any meaning outside the institution.

  • A cost center (id) can be assigned to multiple eligibilities and users.
  • BEH are aggregated per cost center across all projects assigned to the cost center.
  • The assignment of cost centers enables customers to pass on costs (internally).

For a cost center, only the symbols [a-zA-Z0-9-_] and a maximal length of 50 characters are allowed.

First day of validation (NOT supported yet)

Specific day in the yyyy-mm-dd format that allows the institute to limit the validation window begin for the eligibility. If the date is not given or null, the following default behavior is: Eligibility is valid from the current day on. This feature is currently not supported.

Last day of validation (NOT supported yet)

Specific day in the yyyy-mm-dd format that allows the institute to limit the validation window end for the eligibility. If the date is not given or null, the following default behavior is: Eligibility is forever valid. This feature is currently not supported.

Maximal number of booking units (NOT supported yet)

Integer, that defines the maximum number of BEH that can be generated by the associated project. If the number is not given or null, the default behavior is: Eligibility is forever valid. The number of booking units must be at least 200. This feature is currently not supported.

Examples

Entitlement

Example entitlement 1

⚠️ Please Note: The namespace is yet not registered and may change.

Granting a user a request quota for a project up to the medium flavor. All generated booking units will be charged under the bill position 42.

urn:geant:dfn.de:bwcloud-os.de:group:medium_1:42

Interpreted as eligibility:

quota_flavor = medium_1
cost_center_id = 42
first_day_of_validation = {{today}}
last_day_of_validation = inf
max_booking_units = inf

owner = {{user.eppn}}
customer = {{user.home_organization}}

Example entitlement 2

Allow a user to request quota for a large project, but this is terminated up to the end of 2026 and can maximally produce 5000 BEH. The booking units for all projects with the cost center student will be charged under the same bill position.

urn:geant:dfn.de:bwcloud-os.de:group:large_1:student:null:2026-12-31:5000

Interpreted as eligibility:

quota_flavor = large_1
cost_center_id = student
first_day_of_validation = {{today}}
last_day_of_validation = 31.12.2026
max_booking_units = 5000

owner = {{user.eppn}}
customer = {{user.home_organization}}

Example entitlement 3

A xtiny project can be requested. The consumed booking units will aggregate under the position for the informatics faculty and can be used from February 2026 on for one year. Costs are allocated to cost center hfu_netze2.

urn:geant:dfn.de:bwcloud-os.de:group:xtiny_1:hfu_netze2:2026-02-01:2027-01-31:null

Interpreted as eligibility:

quota_flavor = xtiny_1
cost_center_id = hfu_netze2
first_day_of_validation = 01.02.2026
last_day_of_validation = 31.01.2027
max_booking_units = inf

owner = {{user.eppn}}
customer = {{user.home_organization}}

Example entitlement 4

A user with this entitlement will book the costs on the cost center ufr_technical_faculty and must stop when the project consumes 1000000 BEH.

urn:geant:dfn.de:bwcloud-os.de:group:xmedium_1:ufr_technical_faculty:null:null:1000000

Interpreted as eligibility:

quota_flavor = large_1
cost_center_id = ufr_technical_faculty
first_day_of_validation = {{today}}
last_day_of_validation = inf
max_booking_units = 1000000

owner = {{user.eppn}}
customer = {{user.home_organization}}

Eligibility

Example eligibility 1

The example in the image to the left demonstrates how costs can be accumulated based on cost centers.

Example for eligibility cost centers

FAQ

What is the difference between flavor, quota, and quota flavors?

  • Flavor (or VM flavor) is a defined set of resources (core, RAM, storage) that be chosen as the size of an instance.
  • Quota (or project quota) is the amount of resources (core, RAM, storage, network, volume, etc) a project ran consume or bind.
  • Quota flavors is a defined set of project quotas that can be chosen as the size of a project.

How can I change the eligibility of a project?

If you currently own the project, you can request this via Ticket.

What entitlement do I need to become a member of an existing project?

If you can login to the bwCloud-OS, the owner of the project can request your membership via Ticket.

Can I use the same entitlement or eligibility for several projects?

No. A user with his eligibility can only be assigned to one project, {0,1}:1 mapping.

I have an entitlement. How can I get a project with quota?

Only once, during the registration of a new user, automatically a (start-)project is created from a given eligibility. Afterward, a user needs to request a new project.