Title: Creating an Application — UCS Tools Documentation

URL Source: https://docs.nvidia.com/ucf/2.10.0/text/UCS_AppDevelopment.html

Published Time: Thu, 30 Oct 2025 07:23:03 GMT

Markdown Content: Creating an Application#

Using Textual Representation and CLI Tools#

Set the NGC Personal key to sync microservices from NGC:

First, make sure you have followed the prerequisites for generating your NGC Personal Key.

$ ucf_app_builder_cli registry repo set-api-key -a <API-KEY> Checking which NGC UCS teams you have access to Adding NGC Catalog team ace Repository 'catalog-ace' added Adding NGC Catalog team ucs-ms

The command prints the repositories accessible using your API key. Repository names that begin with “catalog-” exist in the NGC Unified Catalog rather than the NGC Private Registry. The NGC Unified Catalog contains artifacts that are either fully public or require product enablement (subscription) such as ace-ea or nvaie to access certain artifacts.

If you get an error when setting the key that reads something like:

2024-11-05 04:18:30,844 - Registry - ERROR - Failed to download service metadata for ucstools_ms_list 2024-11-05 04:18:30,844 - AppBuilder - ERROR - Unable to fetch catalog services list from NGC

Then ensure that you added the NGC Catalog scope when you created your NGC Personal key as documented in NGC Personal Key.

List Available Microservices#

Run this command to get the list of available microservices:

$ ucf_app_builder_cli service list List of available services in local repository:

ucf.svc.myservice

List of available services in UCF repository:

ucf.svc.botmaker.dialog-manager ucf.svc.botmaker.speech-controller ucf.svc.botmaker.speech-web-app ucf.svc.botmaker.text-web-app ucf.svc.riva.speech-skills

This command lists microservices built locally and in the NGC repository.

View Information of Microservices#

Run this command to view information about microservices:

$ ucf_app_builder_cli service info -n ucf.svc.botmaker.speech-web-app name: ucf.svc.botmaker.speech-web-app specVersion: 2.5.0 chart: https://helm.ngc.nvidia.com/eevaigoeixww/ucf-11-ea-release/charts/botmaker-speech-web-app-2.0.0.tgz description: BotMaker Speech Web App type: msapplication tags: [] keywords: [] publish: false ciTrigger: false egress:

• name: speech-controller description: Speech Controller gRCPC endpoint protocol: TCP scheme: grpc mandatory: true data-flow: in-out ingress:
• name: webapp-ui description: Web App UI Endpoint scheme: http data-flow: in-out service: botmaker-speech-web-app-deployment-service port: 5001 protocol: TCP metadata: {} version: 2.0.0 displayName: BotMaker Speech Web App category: functional: Speech AI industry: General secrets: [] buildToolVersion: 1.1.1

Parameters:

debug: (boolean), Start bot in debug mode [Mandatory:False] feedback: (boolean), Enables feedback buttons in web mode [Mandatory:False] gunicornWorkers: (string ), Number of Gunicorn Workers for FM Server [Mandatory:False] gunicornTimeout: (string ), Gunicorn Timeout for FM Server [Mandatory:False]

Compliance Info:

Report Generated on 2022-11-22 18:24:51 (UTC) using MSBuilder v1.1.1 Development compliance (Mandatory) 100.0% Development compliance (Optional) 66.66%

Use this information to choose microservices and configure them in your applications. You can set parameters and connect endpoints based on this output.

Add --show-docs to the command to print detailed documentation for the microservice.

$ ucf_app_builder_cli service info -n ucf.svc.botmaker.speech-web-app --show-docs ... Documentation:

╔═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗ ║ ucf.svc.botmaker.speech-web-app ║ ╚═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝

Description

BotMaker Speech Web App

Sample web application that communicates with Speech Controller and can be used to interact with speech based bot using web browser.

Usage Params:

┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ botmaker-webapp: │ │ debug: false │ │ # Show debug info for bot in Web App │ │ feedback: true │ │ # Enables feedback buttons in web mode │ │ gunicornWorkers: "1" │ │ # Number of Gunicorn Workers for Web App │ │ gunicornTimeout: "120" │ │ # Gunicorn Timeout for Web App │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Connections:

┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ connections: │ │ botmaker-webapp/speech-controller: speech-controller/grpc-api │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Performance

NA

Supported Platforms

x86 dGPU

Deployment requirements

1 Make sure k8s foundational services are running

License

NVIDIA Proprietary License

Known Issues / Limitations

NA

References

NA

Create Application Boilerplate#

After choosing your required microservices, you can start creating the application.

First, create a boilerplate. Then update it to match the reference application Update the Reference Application.

Run this command to generate an application boilerplate:

$ ucf_app_builder_cli app create my-application UCF Application graph boilerplate generated at my-application.yaml (Doc: README.md)

This generates a new file my-application.yaml along with README.md for application documentation.

The file contains this template:

specVersion: 2.5.0

version: 0.0.1

doc: README.md

name: my-application

description: Description for my-application

dependencies:

• ucf.svc.microserviceA:0.0.1
• ucf.svc.microserviceB:0.0.1

components:

• name: microserviceA type: ucf.service.microserviceA parameters: paramA1: 100 paramA2:
  • name: test secrets: some-secret-name: some-secret
• name: microserviceB type: ucf.service.microserviceB parameters: paramB1: false paramB2:
  • name: test

connections: microserviceA/http: microserviceB/http

vaultAgent: auth: path: auth/jwt/authMountPath type: jwt jwt: audience: https://vault-service:443 role: auth-role role: auth-role namespace: vault-namespace service: https://vault-service/

certificates:

devCerts:

file: certificates.yaml

addToHelmChart: false

secrets: some-secret: vaultAgent: path: secret/mount/path template: type: kv key: KEY_IN_SECRET

some-secret:

k8sSecret:

secretName: <k8sSecretName>

key: <keyInK8sSecret>

some-secret:

secretsStoreCsi:

providerClassName: <providerClassName>

objectName: <objectName>

some-secret:

certificate:

certName: <certificateName>

type: <certificate/privateKey/issuingCA>

Note

App name shouldn’t contain spaces

Update App Information#

Update the basic information for your application. Change the name, short description, and other fields. See Basic Information for more information on the fields.

After updating, the section should look like this:

specVersion: 2.5.0

version: 1.13.1

doc: README.md

name: ucf-bot-app

description: UCF application for a bot

Update Dependencies#

Add the microservices you want to use in your application to the dependencies section. This information is required to fetch the desired version of microservices when building the application.

Add a list of microservices and their desired versions to this section. Use the format <microservice-type>:<microservice-version>. Get the microservice version from the service info command output described above.

Run this command to view all available versions of a microservice:

$ ucf_app_builder_cli service versions -n ucf.svc.botmaker.speech-web-app List of versions for service in UCF repository:

2.0.0

The <microservice-version> can be a fixed version or use NPM version range spec format from npm/node-semver.

After updating, the section should look like this:

dependencies:

• ucf.svc.riva.speech-skills:2.0.0
• ucf.svc.botmaker.speech-web-app:>=2.0.0 && < 3.0.0
• ucf.svc.botmaker.speech-controller:2.0.x
• ucf.svc.botmaker.dialog-manager:2.0.0

In this example, when you build the application, the tools will fetch the highest version that matches the version specification for each microservice.

• For ucf.svc.riva.speech-skills and ucf.svc.botmaker.dialog-manager, version 2.0.0 will be picked

• For ucf.svc.botmaker.speech-web-app, if available versions are 1.0.0, 2.0.0, and 3.0.0, version 2.0.0 will be picked (highest within range)

• For ucf.svc.botmaker.speech-controller, if available versions are 1.0.0, 2.0.0 and 2.1.0, version 2.0.0 will be picked

This allows the latest compatible versions of microservices to be picked when building applications without updating the application graph file.

UCS Microservices follow Semantic Versioning - <MAJOR>.<MINOR>.<PATCH>. Pre-release versions are also supported (such as 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, etc). Keep these important concepts in mind when using Semantic Versioning:

• Changes in the <MAJOR> part indicate major changes with possible breakage in backward compatibility.

• Changes in the <MINOR> part indicate enhancements with backward compatibility preserved.

• Changes in the <PATCH> part indicate minor changes like bug fixes with backward compatibility preserved.

Add and Configure Microservices#

Next, add microservices to your application and configure them. Set their parameters and secrets by adding microservices to the components section.

For example, add ucf.svc.botmaker.speech-web-app to your application like this:

• name: botmaker-webapp type: ucf.svc.botmaker.speech-web-app parameters: debug: false gunicornTimeout: "60" imagePullSecrets:
  • name: ngc-docker-reg-secret

Set the parameters according to the parameter schema for the microservice. Get this from the service info command output.

For example, for ucf.svc.botmaker.speech-web-app:

$ ucf_app_builder_cli service info -n ucf.svc.botmaker.speech-web-app ... Parameters:

speech: (boolean), Speech Web App or Text Web App [Mandatory:False] debug: (boolean), Start bot in debug mode [Mandatory:False] feedback: (boolean), Disables feedback buttons in web mode [Mandatory:False] gunicornWorkers: (string ), Number of Gunicorn Workers for FM Server [Mandatory:False] gunicornTimeout: (string ), Gunicorn Timeout for FM Server [Mandatory:False]

...

Here, debug is a boolean parameter and gunicornTimeout is a string parameter. You must specify parameters marked as mandatory. Some microservices have nested parameters as shown in the example below.

UCS Application build tools will validate these parameters. During application build, the build tools will throw an error if mandatory parameters are not set or they do not match the parameter schema. For example, if you set debug to "123":

Validating application ... debug:'123' is not of type 'boolean' Warning!!! parameter validation failed for microservice instance botmaker-webapp Application validation failed

For microservices whose Helm charts are built using UCS MS Builder Tool, some parameters are implicitly added. These parameters are not shown in the service info output. For example, imagePullSecrets is an implicit parameter. See the next section for details on implicitly added parameters.

Implicitly Added Parameters#

As mentioned in the previous section, microservices whose Helm charts are generated using the UCS MS Builder Tool have some parameters added implicitly.

Here’s an example of how to set these parameters along with their details:

• name: <svc-name> type: <svc-ucf-type> parameters: imagePullSecrets: # List of K8S secrets to be used for pulling images required by the MS (Since 1.0 EA)

  • name: ngc-docker-reg-secret

  ucfVisibleGpus: [1, 2] # List of GPUs that should be made visible to the containers in the MS. Internally sets NVIDIA_VISIBLE_GPUS env var (Since 1.0 EA)

  resources: # Resource requests and limits to set on the containers in the MS. (Since 1.0 EA) requests: # Refer to - https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#resourcerequirements-v1-core cpu: 1 limits: nvidia.com/gpu: 1

  podAnnotations: # Annotations to set on the pods belonging to the MS (Since 1.1 EA) annotation-name: annotation-value

  podLabels: # Labels to set on the pods belonging to the MS (Since 1.1 EA) label-name: label-value

  extraPodVolumes: # List of extra volumes to add to all the pods belonging to the MS (Since 1.1 EA)

  • name: extra-vol1 # Refer to https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#volume-v1-core emptyDir: {}

  extraPodVolumeMounts: # List of extra volume mounts to add to all the containers of all the pods belonging to the MS (Since 1.1 EA)

  • name: extra-vol1: mountPath: /tmp/extra-vol-dir

  svcAnnotations: # Annotations to set on the services belonging to the MS (Since 1.1 EA) annotation-name: annotation-value

  svcLabels: # Labels to set on the services belonging to the MS (Since 1.1 EA) label-name: label-value

  global: ucfGlobalEnv: # List of environment variables to set in all containers of all the pods belonging to the MS (Since 1.1 EA) - name: SOME_ENV_VAR_NAME value: someEnvVarValue

Configuring Secrets#

You must specify all mandatory secrets for each microservice. View the secrets requirement using the service info command.

See Secrets Management for more information on how secrets work in UCS Tools and how to configure them.

Connect Microservice Endpoints#

Next, connect microservices together. Microservices with mandatory Egress endpoints must connect to another meaningful microservice that has corresponding and compatible Ingress endpoints. These endpoints must provide the necessary functionality.

Get the endpoints of a microservice from the service info command output.

Specify connections as an object with top-level key connections in the application YAML. Use this format:

connections: <egress-endpoint-component-name1>/<egress-endpoint-name1>: <ingress-endpoint-component-name1>/<ingress-endpoint-name1> <egress-endpoint-component-name2>/<egress-endpoint-name2>: <ingress-endpoint-component-name2>/<ingress-endpoint-name2>

If the egress endpoint supports multiple connections (multi: true), you can connect multiple ingress endpoints to it using array style format:

connections: <egress-endpoint-component-name>/<egress-endpoint-name>: [ <ingress-endpoint-component-name1>/<ingress-endpoint-name1>, <ingress-endpoint-component-name2>/<ingress-endpoint-name2> ]

UCS Application build tools will validate the endpoints and connections. If a mandatory Egress endpoint is not connected or if there’s an invalid connection, the tools will throw an error.

Add Detailed Documentation#

Add any detailed documentation required for building the application and deploying the built Helm chart to the README file accompanying the application graph file.

Value Spec File for Deployment#

Application developers can choose a value spec file as an optional input while building an application. This file specifies how values for deployment are overridden. The file is in multi-doc YAML format. Each doc defines a value specification applied to certain microservice instances in the application.

Here’s a simple example of a value spec file:

spec: namespace: my-application

spec: serviceAccount: name: my-sa create: True usedBy: ["dialog-manager", "speech-controller"]

“usedBy” is optional for a value specification. When “usedBy” is absent, all service instances in the application are applicable to it.

The following table lists all the values supported in a value spec.

Using UCS Studio#

See Create a Reference Application for an example of creating an application using UCS Studio.

Building an Application#

You can build UCS Applications using either the UCS Application Builder CLI tool or the UCS Studio GUI.

Using CLI Tools#

Build existing application graph files using this command:

$ ucf_app_builder_cli app build app.yaml 2022-12-05 14:44:52,464 - AppBuilder - INFO - Syncing any missing service versions to cache... 2022-12-05 14:44:52,507 - AppBuilder - INFO - Validating application ... 2022-12-05 14:44:52,517 - AppBuilder - INFO - Building application ucf-bot-app-1.13.1 ... 2022-12-05 14:45:00,122 - AppBuilder - INFO - Application Information written to ucf-bot-app-1.13.1/app_info.yaml 2022-12-05 14:45:00,122 - AppBuilder - INFO - Application compliance report generated at ucf-bot-app-1.13.1/compliance_report.json 2022-12-05 14:45:00,123 - AppBuilder - INFO - Application Helm Chart generated in ucf-bot-app-1.13.1 2022-12-05 14:45:00,123 - AppBuilder - INFO - App built

Application build performs several validations including syntax errors, incorrect parameters, and invalid connections. It fails if there are any issues:

$ ucf_app_builder_cli app build app.yaml 2022-12-05 14:46:16,846 - AppBuilder - INFO - Syncing any missing service versions to cache... 2022-12-05 14:46:16,888 - AppBuilder - INFO - Validating application ... 2022-12-05 14:46:16,891 - AppBuilder - ERROR - Mandatory endpoint 'speech-controller' not set for microservice instance speech-web-app 2022-12-05 14:46:16,899 - AppBuilder - ERROR - Application validation failed

Parameter Files#

Instead of specifying parameters in the application YAML, you can provide some or all parameters for a given app component via parameter files. For example, given the app example in the section named Create Application Boilerplate, instead of supplying the parameters inside the app YAML, you could put them in a params.yaml file like this:

microserviceA: paramA1: 100 paramA2:

• name: test microserviceB: paramB1: false paramB2:
• name: test

Apply parameter files using this command:

$ ucf_app_builder_cli app build app.yaml params1.yaml params2.yaml

You can also mix and match. The app YAML can contain some parameters defined while others are provided in a parameter file. If a parameter is defined in both places, the one in the parameter file takes precedence. Furthermore, you can specify multiple parameter files to provide a cascading means for overriding parameters. The parameter defined in the rightmost location takes precedence.

For example, if you build an app with this command:

ucf_app_builder_cli app build app.yaml params1.yaml params2.yaml

And some parameter P for some app component C is specified in the app.yaml and both params1.yaml and params2.yaml, the value for P from params2.yaml will be used.

Since version 2.10.0, the built-in “files” parameter in an app component’s parameters block is also supported in a parameter file.

Value Spec File#

Specify a value spec file using ‘-v’:

$ ucf_app_builder_cli app build app.yaml params1.yaml params2.yaml -v value_spec.yaml

Using UCS Studio#

See Create a Reference Application for an example of building an application using UCS Studio.

Build Output#

Building an application generates the following:

• A deployable Helm chart at the location mentioned by the command output (e.g., ucf-bot-app-1.13.1)

• Application information file with useful information for deploying the application (e.g., ucf-bot-app-1.13.1/app_info.yaml). Currently this includes:

• List of secrets used in the application and their details. Use this to setup all the secrets before deploying the application.

  • List of metrics and their details exposed by microservices used in the application. Use this to create any Prometheus rules, alerts, or HPA configurations.

  • Sample for this file:

metrics:

• name: nv_inference_count description: No. of inference requests executed by the server labels: [ model, version ] microservice: ucf.svc.riva.speech-skills v2.0.0

secrets:

• name: my-ngc-api-key description: Secret for NGC API key type: Kubernetes Secret secretName: ngc-api-key-secret secretKey: NGC_API_KEY usedBy:
• ucf.svc.riva.speech-skills v2.0.0
• ucf.svc.botmaker.speech-controller v2.0.0
• ucf.svc.botmaker.dialog-manager v2.0.0

• A value override YAML file which carries a subset of values applicable to the application Helm charts and can be used to override the values during installation

• Combined compliance report of all the microservices added to the application (e.g., ucf-bot-app-1.13.1/compliance_report.json). Sample for this file:

{ "name": "ucf-bot-app", "version": "1.13.1", "time-utc": "2023-03-13 13:21:33", "appbuilder-version": "2.0.0", "compliance-development-mandatory-overall": 100.0, "compliance-development-optional-overall": 49.99, "compliance-ms": [ { "name": "ucf.svc.riva.speech-skills", "version": "2.0.0", "compliance-development-mandatory": 100.0, "compliance-development-optional": 66.66 }, { "name": "ucf.svc.botmaker.speech-web-app", "version": "2.0.0", "compliance-development-mandatory": 100.0, "compliance-development-optional": 66.66 }, { "name": "ucf.svc.botmaker.speech-controller", "version": "2.0.0", "compliance-development-mandatory": 100.0, "compliance-development-optional": 33.33 }, { "name": "ucf.svc.botmaker.dialog-manager", "version": "2.0.0", "compliance-development-mandatory": 100.0, "compliance-development-optional": 33.33 } ] }

Deploy an Application with Helm#

Building a UCS Application generates a deployable Helm chart. Deploy it using the helm install command:

$ helm install <release-name> <app-output-helm-chart>

Some microservices expose their functionality to external users using the NodePort service type. Exposing NodePort services may not be possible or may be tricky in Kubernetes provided by some cloud service providers. In this case, use the global.useLoadBalancerInsteadOfNodePort parameter to override the NodePort service type to LoadBalancer. This is only possible for microservices built using UCS 1.5 or later. Example:

$ helm install <release-name> <app-output-helm-chart> --set=global.useLoadBalancerInsteadOfNodePort=true

Users may also have their own methods of deploying the application charts.

The application README which gets copied to the output Helm chart may have additional prerequisites/steps required to deploy the application.

Some applications depend on core services like Vault Agent Injector and Secrets Store CSI Driver. Users must deploy these services before deploying the application. The application information generated during app build might be helpful here.

Deploy an Application to NVCF#

UCS Tools allows you to build an app and deploy directly on NVCF as a cloud function. The following example demonstrates deploying an existing UCS Microservice ucf.svc.nvcf.image-segmentation:1.3.0 to NVCF.

Create the App Manifest#

Save the following to a file named app.yaml:

specVersion: '2.5.0' version: 0.0.2 doc: README.md name: image-segmentation-app description: Performs segmentation of a given image and is based on Deepstream 6.2 triton docker dependencies:

• ucf.svc.nvcf.image-segmentation:1.3.0 components:
• name: image-segmentation type: ucf.svc.nvcf.image-segmentation parameters: imagePullSecrets:
  • name: ngc-docker-reg-secret

Create the NVCF Configuration file for UCS Tools#

Save the following to a file named nvcf.yaml and set the “Password” field within “DockerRegSecrets” to your NGC API KEY:

FunctionName: "image-segmentation-service" # NVCF function name InferenceUrl: "/grpc" # NVCF function interface URL. Use '/grpc' for gRPC functions InferencePort: "50000" # NVCF function port HelmChartServiceName: "image-seg-nvcf-segmentation-deployment-segmentation-service" # K8s service name exposed as function GpuType: "A10G" # Type of GPU Backend: "GFN" # Backend type MaxInstance: "1" # Maximum number of instances MinInstance: "1" # Minimum number of instances InstanceType: "ga10g_1.br20_2xlarge" # Type of instance DockerRegSecrets:

• Name: "ngc-docker-reg-secret" Username: "NGC_CLI_API_KEY" Password: "<KEY>" #AdditionalSecrets:

- Name: ""

Key: ""

Value: ""

#StorageProvisioner:

- Name: ""

Namespace: ""

Deploy the UCS App to NVCF#

First, build the app:

ucf_app_builder_cli app build app.yaml

Then run the nvcf-deploy subcommand. This will upload your app Helm chart to nv-ucf/staging, unless it already exists with the version you are building. Then, it will create the NVCF function and deploy it:

ucf_app_builder_cli app nvcf-deploy app.yaml nvcf.yaml {'version': False, 'version_all': False, 'parser_name': 'app', 'help': 'Create a microservice from the application', 'app': 'app.yaml', 'nvcf': 'nvcf.yaml', 'subparser_name': 'nvcf-deploy'} 2024-03-27 14:52:01,668 - AppBuilder - INFO - Syncing any missing service versions to cache... 2024-03-27 14:52:01,674 - AppBuilder - INFO - Deploying application image-segmentation-app-0.0.2 on NVCF 2024-03-27 14:52:01,675 - AppBuilder - INFO - nvcf metadata: {'FunctionName': 'image-segmentation-service', 'InferenceUrl': '/grpc', 'InferencePort': '50000', 'HelmChartServiceName': 'image-seg-nvcf-segmentation-deployment-segmentation-service', 'GpuType': 'A10G', 'Backend': 'GFN', 'MaxInstance': '1', 'MinInstance': '1', 'InstanceType': 'ga10g_1.br20_2xlarge', 'DockerRegSecrets': [ {'Name': 'ngc-docker-reg-secret', 'Username': 'NGC_CLI_API_KEY', 'Password': '<KEY>'} ]} 2024-03-27 14:52:04,687 - MsBuilder - INFO - App started deploying on NVCF

Also check out the UCS A2F demo.

UCS App Helm Chart NVCF Compatibility#

The UCS App Helm chart is compatible with NVCF. You can also directly deploy the app Helm chart to NVCF using NVCF REST APIs or using the API Catalog workflow.

NVCF Image Pull Secret Schema Support#

The Helm chart templates support both standard and NVCF image pull secret formats:

Accepted values.yaml formats to reflect its templates:

1. standard format, in each single chart values.yaml, either each sub-chart or the top level itself.

usage: non NVCF

who create the secret: users

imagePullSecrets:

• name: secret1

2. standard format, in top level values.yaml visible for all sub-charts

usage: non NVCF

who create the secret: users

global: imagePullSecrets:

• name: global-secret1

3. NVCF format, in top level values.yaml visible for all sub-charts

usage: NVCF

who creates the secret: NVCF

global: ngcImagePullSecretName: ""

It’s okay to have both formats in the same Helm chart, which can result in the following rendering:

Kubernetes Rendering:

imagePullSecrets:

• name: secret1
• name: global-secret1
• name: nvcf-secret

Kubernetes will check each image pull secret until it finds the right one. But for most cases, only one secret is needed.

Note

• NVCF first creates the image pull secret with a name <actual-secret-name>

• During Helm chart installation, NVCF overwrites values with --set global.ngcImagePullSecretName=<actual-secret-name>

• The empty default value in root values.yaml is intentionally omitted as it’s an optional value set during deployment

Shared Image Registry Support#

Adds capability to override container image registry and path globally.

Accepted values.yaml format to reflect its templates:

global: ngcImageRegistry: "nvcr.io" ngcImageRegistryPath: "team/project"

When both values are present, all container images will be reconstructed as: {ngcImageRegistry}/{ngcImageRegistryPath}/{original-image-name}:{original-tag}

Constraints:

• Original image names must not contain slashes

• Both global values must be present to enable override

• Falls back to original image paths if global values are missing

Example:

• Original: old-registry.io/old-path-ok-with-slashes/my-image:v1.0

• Override: new-registry.io/new-path-ok-with-slashes/my-image:v1.0

Original deployment:

$ microk8s helm3 install test hello-world-app-0.0.1/ --dry-run

Renders to:

containers:

• name: hello-world-service-a-container image: nvcr.io/nvidia/pytorch:22.04-py3

With override:

$ microk8s helm3 install test hello-world-app-0.0.1/
--set global.ngcImageRegistry=nvcr.io
--set global.ngcImageRegistryPath=goirlvsxnepa/yourteam_nim
--dry-run

Renders to:

containers:

• name: hello-world-service-a-container image: nvcr.io/goirlvsxnepa/yourteam_nim/pytorch:22.04-py3

Note

• The global.ngcImageRegistry and global.ngcImageRegistryPath are intentionally omitted in values.yaml as they are optional values set during deployment

Links/Buttons:

• #
• NGC Personal Key
• Update the Reference Application
• Basic Information
• npm/node-semver
• Secrets Management
• https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling
• Create a Reference Application
• Create Application Boilerplate
• application information
• NVCF
• UCS A2F demo
• NVCF REST APIs
• API Catalog workflow

Related Articles

• UCS Application Builder CLI — UCS Tools Documentation
• Creating a Microservice — UCS Tools Documentation
• Unified Cloud Services Tools (UCS Tools) — UCS Tools Documentation