Skip to main content

Concepts

AI App Store recognizes three actors:

  • App developer: creates and publishes apps
  • App user: browses and runs apps, can be either user with "full access" or visitor
  • Admin: manages the platform

over five resource types:

  • App: runnable app package
  • App instance: instance of an app
  • App tag: controls categories, badges, and visitor-user access to apps
  • App secret: sensitive information needed to run apps within the platform or dynamically injected configuration
  • App instance alias: a custom URL for a particular app instance

App​

App is a runnable package with the following types of metadata:

  • Identity
    • a system-generated unique id
    • a unique name and version identifier
  • AI App Store display and search
    • a title and description
    • icon and screenshots
    • long description
    • app tags for categories and badges
  • Authorization
    • owner: the person who imported it into AI App Store
    • visibility: PRIVATE or ALL_USERS
    • instance lifecycle: ON_DEMAND, MANAGED
    • app tags for visitor-user authorization
  • Runtime
    • RAM and disk requirements
    • app secrets
    • other runtime settings such as routing mode and OIDC

Each user can start or run multiple instances of each app - subject to Authorization and the instance lifecycle.

Once it has been uploaded into the AI App Store, the app package cannot be changed. However, the owner or admins can update the following types of metadata at any time:

  • categories and badges assigned to the app
  • authorization tags assigned to the app
  • visibility
  • the value of app secrets used by the app

To update the source code, display and search, or runtime information, a developer must upload a new version of the app. This simplifies the app lifecycle and removes the need for developers to address upgrades or downgrades of their app or related app instances.

See the app CLI documentation for instructions on how to create and manage apps.

note

Internally, AI App Store treats every app name and version combination as a separate entity. The UI then uses the app name to link several versions together; however each can have different title, description, owner, instances, etc.

App instance​

App instances are an instance of an app with the following metadata:

  • pointer to the corresponding app
  • owner of the instance
  • visibility: PRIVATE, ALL_USERS, or PUBLIC
note

Public app instances are available to anyone on the internet who has the URL. However, if the app itself requires authentication (with EnableOIDC=True in the configuration file) then users will be asked to log in before they can access the app's UI.

App instances can be stateless or stateful, single or multi-user, and connect to external dependencies like AWS S3 or Driverless AI all depending on the corresponding app.

Under the hood, each instance consists of several K8s resources; specifically, each instance is running in its own Kubernetes pod, internally routed via its own Kubernetes service, and accessible via the AI App Store either by subdomain or path. Apps may optionally utilize other resources, such as PVCs, Configmaps, etc. The AI App Store fully manages the app instance lifecycle on behalf of its users who only have to request to create, visit, or delete the instance.

See the app instance CLI documentation for instructions on how to manage app instances.

App tag​

App tags are means of annotating apps in the platform (similar to GitHub issue labels). Beyond visually categorizing apps, tags also act as a mechanism by which apps are exposed to "visitors" (i.e., users without "full access"); see Authorization for visitors for details.

App tags are a standalone resources with the following metadata:

  • Identity
    • a system-generated unique id
    • a unique name
  • AI App Store display and search
    • title, color, description
    • type: CATEGORY for search and filter, BADGE for displaying additional information and VISITOR for authorization
  • Access
    • admin roles: users that can manage the tag
    • visitor roles: visitors that can view apps with this tag

Each app tag can be assigned to multiple apps, and each app can have multiple tags assigned to it.

See the app tag CLI documentation for instructions on how to manage tags.

App secret​

App secrets are backed by Kubernetes secrets and are meant for storing sensitive information that can be mounted as an environment variable or file. They can also be used to parameterize app instances without having to upload a new version of an app. When an app secret is changed, all newly ran app instances, or paused and resumed app instances, will get access to the new variable. Secrets are standalone resources with the following metadata:

  • name
  • visibility (PRIVATE, ALL_USERS, APP)
  • parent (the parent scope of the secret; name + visibility + parent uniquely identify a secret)
  • owner (the person who created it)

See the app secret CLI documentation for instructions on how to manage secrets.

App instance alias​

Aliases are essentially assignable custom URLs for app instances. By default, running instances of apps have URLs like cloud.h2o.ai/8184-810243981-23. Via an alias, we can expose the same instance under my-awesome-app.cloud.h2o.ai.

An Alias is a standalone resource with lifecycles that are separate from app instances. They include the following metadata:

  • name
  • instance ID
  • whether it is a primary alias or not

Having a separate lifecycle, an alias can be dynamically assigned to an instance or moved from one instance to another. If an instance corresponding to an alias is terminated or paused, the alias will keep on existing but will become inactive, returning HTTP 404 response for all attempts to visit it, until it is assigned to another instance or the instance is resumed.

One instance can have multiple aliases assigned, but each alias can only be assigned to one instance.

The alias marked as primary will serve as the actual URL for accessing the instance. Accessing the instance via other aliases or via its UUID URL will result in a HTTP 302 redirect to the primary alias. If an instance has no primary alias, then the UUID URL is considered to be the primary alias. There can be, at most, one primary alias assigned to an instance.

See the app instance alias CLI documentation for instructions on how to manage aliases.

Visibility​

Visibility is a generic concept for governing some basic authorization rules for resources that do have this attribute, such as app, app instance, and app secret. For concrete rules and more information, see Authorization.

Feedback