All UAIs can have the following attributes associated with them:
This topic explains each of these attributes.
The container image for a UAI (UAI image) defines and provides the basic environment available to the user. This environment includes, among other things:
A site can customize UAI images and add those images to UAS, allowing them to be used for UAI creation. Any number of UAI images can be configured in UAS, though only one will be used by any given UAI.
UAS provides two UAI images by default. These images enable HPE Cray EX administrators to set up UAIs and run many common tasks. The first image is a standard End-User UAI image that has the software necessary to support a basic Linux login experience. This is primarily intended to give administrators a way to get started with UAIs and experiment with their configuration. The second image is a Broker UAI image. Broker UAIs present a single SSH endpoint that every user of a given class of UAIs logs into. The Broker UAI then locates or creates a suitable End-User UAI and redirects the SSH session to that End-User UAI.
The volumes defined for a UAI provide external access to data provided by the host node. Anything that can be defined as a volume in a Kubernetes pod specification can be configured in UAS as a volume and used within a UAI. Examples include:
When UAIs are created they mount a list of volumes inside their containers to give them access to various data provided either by Kubernetes resources or through Kubernetes by the host node where the UAI runs. Which volumes are in that list depends on how the UAI is created:
The following are some example use cases for UAI volumes:
Every UAS volume includes the following values in its registration information:
mount_path: Specifies where in the UAI the volume will be mounted.volume_description: A dictionary with one entry, whose key identifies the kind of Kubernetes volume is described (for example, host_path, configmap, secret).
The value associated with that key is another dictionary containing the Kubernetes volume description itself.volumename: A required string chosen by the creator of the volume. This may describe or name the volume. It is used inside the UAI pod specification to identify the volume that is mounted in a given location in a container.
A volumename is unique within any given UAI, but not necessarily within UAS. These are useful when searching for a volume if they are unique across the UAS configuration.volume_id: Used to identify the UAS volume when examining, updating, or deleting a volume and when linking a volume to a UAI class. The volume_id is generated by and unique within UAS.Refer to Kubernetes Documentation describing Volumes for more information about Kubernetes volumes.
A resource request tells Kubernetes the minimum amount of a given host node resource to give to each UAI. A resource limit sets the maximum amount of a given host node resource that Kubernetes can give to any UAI. Kubernetes uses resource limits and requests to manage the system resources available to pods. Because UAIs run as pods under Kubernetes, UAS takes advantage of Kubernetes to manage the system resources available to UAIs. In UAS, resource specifications contain that configuration. A UAI that is assigned a resource specification will use the resource requests and limits found there instead of the default resource limits or requests on the Kubernetes namespace containing the UAI. This way, resource specifications can be used to fine-tune resources assigned to UAIs of different classes.
UAI resource specifications have three configurable parameters:
Resource specifications also contain a resource-id that is used for examining, updating, or deleting the resource specification as well as linking the resource specification into a UAI class. Resource-ids are generated by UAS and unique to each resource specification.
Resource specifications configured in UAS contain resource requests, limits, or both, that can be associated with a UAI. Any resource request or limit that can be set up on a Kubernetes pod can be set up as a resource specification under UAS.
There are also smaller configuration items that control things such as:
These items are configured in UAI Classes so only UAIs created from UAI Classes can have these settings.
All of the above described UAI configuration and more can be encapsulated into a UAI Class, which can then be used to create UAIs with greater precision and efficiency. UAI Classes are especially important when using Broker UAIs because Broker UAIs use a UAI Creation Class configured into the Broker UAI’s class to determine what kind of End-User UAI to create when a user logs into the Broker.