Application Profiles

An ApplicationProfile in the AP (Application & Profile) service defines how a Kit Application version is deployed, including resource allocation, Helm chart values, and other environment-specific configurations. Below are the primary sections within the ApplicationProfile CRD that are relevant for configuring it:

Additional resources:

• Creating an Application Profile - step-by-step deployment instructions

• Samples and Resources - contains a number of example application profiles

---

1. Metadata

metadata.name: Specifies the name of the application profile, which must be unique within the namespace.

Example:

metadata:
   name: production-profile

Purpose: This section uniquely identifies the profile in the cluster and allows you to reference it in other resources.

---

2. Spec Section

The spec section is where the bulk of the configuration happens. Below are the key fields within the spec that are critical for configuring an application profile:

2.1. Name and Description

• spec.name: A user-friendly name for the profile.

• spec.description: A brief description of the profile’s purpose.

Example:

spec:
   name: Production Profile
   description: Profile for production deployment of My Application.

Purpose: Helps provide clarity on the profile’s role and usage, especially in environments with multiple profiles.

—

2.2. Supported Applications

• spec.supportedApplications: Defines which applications and versions this profile applies to.

  • name: The name of the application the profile applies to.

  • versions: A list of supported versions of the application. You can use wildcards like “*” to support multiple versions.

simple

Example: profile for one application and two explicit versions

supportedApplications:
   - name: "my-application"
      versions:
         - "1.0.0"
         - "1.1.0"

version wildcards

Example: profile for one application and a mix of explicit and wildcard versions

supportedApplications:
   - name: "my-application"
      versions:
         - "1.5.0"
         - "1.6.0"
         - "2.*"

multiple applications

Example: profile for one explicit and a wildcard application and a mix of explicit and wildcard versions

supportedApplications:
   - name: "my-application"
      versions:
         - "1.5.0"
         - "1.6.0"
         - "2.*"
   - name: "usd-*"
      versions:
         - "*"

Purpose: This section ties the profile to specific applications and versions. It enables the APS to apply this profile when a corresponding application version is deployed.

—

2.3 Chart Mappings

spec.chartMappings: This section defines mappings between the profile and Helm chart values they should override.

Example: maps streamingKit.image.repository and tag to override the ApplicationVersion container settings.

chartMappings:
   container: streamingKit.image.repository
   container_version: streamingKit.image.tag
chartValues:
   streamingKit:
      image:
         repository: nvcr.io/omniverse/prerel/usd-viewer
         pullPolicy: Always
         tag: '0.2.0'

Purpose: Provides a mapping mechanism between settings defined in spec.chartValues and what they should override in the Helm chart.

—

2.4 Chart Values

spec.chartValues: Values to apply to the helm chart that is installed.

Example: container image values that override those defined in the ApplicationVersion.

chartValues:
   image:
      repository: nvcr.io/my-app-repo/my-application
      tag: 1.0.0
   ingress:
      enabled: true
      host: my-app.example.com

Purpose: The chartValues section specifies values within the application-profile that should override settings in the Helm chart used to start the Kit App. The possible values are based entirely on the extent of the underlying Helm chart. In situations where dynamic NLB or Authorization are required, for example, this can be quite extensive.

---

3. Resource Requests and Limits

Define the resource requests and limits for the application, specifying how much memory, CPU, or GPU the application needs.

Example: 8-16 cores, 32Gi-64Gi memory and 1 gpu

chartMappings:
   resources:
      requests:
         memory: "32Gi"
         cpu: "8"
         gpu: "1"
      limits:
         memory: "64Gi"
         cpu: "16"
         gpu: "1"

Purpose: This ensures that the application has sufficient resources to run efficiently and prevents resource overcommitment on the cluster.

---

4. Environment-Specific Configuration

• Ingress: Set up ingress rules for routing external traffic to the application.

• Storage and Volumes: If the application requires persistent storage, you can define it here (optional).

• Security Settings: Optional configurations for secure deployments, such as SSL/TLS certificates for ingress.

Example:

chartValues:
   ingress:
      enabled: true
      host: app.example.com
      tls: true

Purpose: Allows customization of the deployment based on the environment (production, development, staging) or infrastructure type (cloud, on-prem).

---

5. Logging and Monitoring Configuration

• Logging Settings: Define logging levels and outputs (optional).

• Prometheus Monitoring: Integrate monitoring tools like Prometheus to track application performance.

Example:

chartValues:
   monitoring:
      enabled: true
      prometheusNamespace: "monitoring"

Purpose: Ensures the application’s performance is tracked and that logs are accessible for debugging and monitoring.

---

6. Wildcard Support

Wildcards can be used for both application names and versions, making it easier to manage profiles that apply to many applications or versions without explicit enumeration.

Example:

supportedApplications:
   - name: "usd-viewer"
      versions: ["*"]
   - name: "usd-explorer"
      versions:
         - "1.1.5"
         - "1.2.*"
         - "2.*"
   - name: "omni-*-viewer"
      versions: ["*"]

---

7. Default Application Profile

You can define a default profile by using wildcards for all applications and versions, ensuring that a default configuration is applied when none is specified.

Example:

apiVersion: omniverse.nvidia.com/v1
kind: ApplicationProfile
metadata:
   name: default-profile
spec:
   supportedApplications:
      - name: "*"
      versions: ["*"]

Purpose: The default profile acts as a fallback for any application or version without a specifically assigned profile.

---

8. Defining Environment Variables

Environment variables can be added to the chartValues.env section of the applicationprofile.yaml. These variables are then passed to the application when it is deployed.

sparse

spec:
  chartValues:
    streamingKit:
      env:
        - name: APP_ENV
          value: "production"
        - name: LOG_LEVEL
          value: "info"
        - name: USD_PATH
          value: "/app/data/Forklift_A/Forklift_A01_PR_V_NVD_01.usd"

full

apiVersion: omniverse.nvidia.com/v1
kind: ApplicationProfile
metadata:
  name: default
spec:
  name: Default profile
  description: Updated memory and CPU settings with env_vars
  supportedApplications:
    - name: "usd-viewer"
      versions: 
        - "*"
  chartMappings:
    container: streamingKit.image.repository
    container_version: streamingKit.image.tag
    name: streamingKit.name
  chartValues:
    global:
      imagePullSecrets:
        - name: regcred
    streamingKit:
      resources:
        requests:
          cpu: "8"
          memory: "32Gi"
          nvidia.com/gpu: "1"
        limits:
          cpu: "16"
          memory: "64Gi"
          nvidia.com/gpu: "1"
      env:
        - name: APP_ENV
          value: "production"
        - name: LOG_LEVEL
          value: "info"
        - name: USD_PATH
          value: "/app/data/Forklift_A/Forklift_A01_PR_V_NVD_01.usd"

Purpose: This allows dynamic configuration to be injected into the Kit Application at runtime, making it easier to manage different deployment environments (e.g., production, staging). The logic to respond to the environment variables is the responsibility of the Kit App developer.

Verifying Environment Variables

To confirm that environment variables are correctly set in an application pod, you can use the following commands:

Output all environment variables for the specified POD.

kubectl exec -it <POD_NAME> -- env

Check the value of a specific environment variable on the specified POD

kubectl exec -it <POD_NAME> -- env | grep <ENV_VAR>

---

Conclusion

These primary sections within the ApplicationProfile CRD allow for detailed customization of how Omniverse Kit Apps are deployed within the Omniverse Application Streaming API environment. By carefully defining the supportedApplications, chartMappings, chartValues, and resource requests, you can ensure each application is optimized for its deployment environment, whether cloud, on-premise, production, or development.