Resource

The resource app encapsulates the features associated with creating and managing resources. Figure resource_uml shows the UML diagram of the resources app. This app contains five models: ResourceType, Resource, AttributeType, ResourceAttributeType, and ResourceAttribute. The ResourceType model defines the type of resource such as clusters, cloud resources, servers, storage, or software licenses. A new resource type is defined using the name and description field of the ResourceType model.

Resource App UML

The Resource model is the central model in the resource app. It defines the name and description of the resource. It can optionally link to itself using the parent_resource field. This allows ColdFront to model parent-child relationship between resources. This is useful when access control to a child resource is independent of access to its siblings. For instance, a cluster having multiple partitions where each partition has independent access control. The availability of the resource can be controlled using the is_available field. Whether the resource is available to public or is private is controlled using the is_public field. For non-public resources, the allowed_users field allows access control on per-user basis. The allowed_groups field allows access on per-group basis, where multiple users can be associated to a single group. Finally, there are two inter-linked Resource fields called: linked_resources and is_subscribable. These two fields can be used to model the scenario where allocation to one resource also gives allocation to other linked resources. The linked_resources field is used to link resources. The is_subscribable determines if a resource is directly subscribable. For instance, a user can request access to particular cluster, but along with that they get access to scavenger partitions on other clusters. The scavenger partitions would be added as linked resources to the main resource and their is_subscribable option would be set to false so that users cannot directly request allocation to the scavenger partitions.

The AttributeType model along with ResourceAttributeType, ResourceAttribute and Resource models are based on the entity–attribute–value model, where the Resource model is the entity, the ResourceAttribute model is the value, and the ResourceAttributeType model is the attribute. The ResourceAttribute model is used to associate attributes, i.e., metainformation, to resources. The AttributeType model defines the types of attribute values that are allowed, adding another layer of abstraction to the entity–attribute–value model. For instance, if the AttributeType is int, then the backend will validate the ResourceAttribute value entered against type int.

The ResourceAttributeType model is the attribute or parameter in the entity–attribute–value model. The ResourceAttributeType model is linked to the AttributeType model. It defines the name of the attribute. If the attribute is unique per resource, then the is_unique_per_resource field should be set to true. If only the value of the ResourceAttribute is unique per resource, then the is_value_unique field should be set to true.

The ResourceAttribute model is the value in the entity–attribute–value model. It links the ResourceAttributeType and Resource model. Its value field stores the attribute value. The ResourceAttribute model underpins ColdFront’s ability to integrate with any third-party system or tool to modify or extend its core functionality. Example usages of ResourceAttributes will be discussed later when discussing how FreeIPA and Slurm account management are integrated into ColdFront.