Skip to main content

Configure Settings

Settings define integrations and configuration values used by Projects and Compute Pools. For integration types, prerequisites, and examples, refer to Settings and Integrations.

Overview​

You can configure Settings in PaletteAI at two levels:

  • Project-level Settings: Settings that you create in a Project namespace. Each Project can have its own Settings that define integrations specific to that Project.

  • Tenant-level Settings: Settings that you create in the Tenant namespace that multiple Projects can reference. Tenant-level Settings provide a central way to manage common configurations across Projects.

Tenant Defaults and Inheritance​

You can create Tenant-level Settings and configure a default Settings reference for the Tenant. Manage the default reference from the Settings Ref tab on the Tenant Settings page.

Settings Reference​

The settingsRef field on the Tenant resource sets the default Settings resource that Projects can inherit. When you configure it:

  • The reference points to a Settings resource by name and namespace.

  • Projects under the Tenant can inherit this default Settings reference.

  • The Tenant namespace follows the convention tenant-<tenant-name>.

Inheritance Model​

Settings inheritance follows this model:

  • Projects can define their own Settings in their Project namespace.

  • Projects can reference the Tenant-level default Settings if configured.

  • When you configure both Tenant-level and Project-level Settings, PaletteAI merges them at the integration field level. Each integration type (Hugging Face, NVIDIA, and Palette) is merged independently. If the same field exists in both, the Project-level value takes precedence.

  • The Settings controller automatically computes the effective merged Settings and stores them in status.effectiveSettings, which represents the authoritative resolved configuration.

  • Project.spec.settingsRef is a name-only reference. Because it has no namespace field, it always resolves to a Settings resource with that name in the Project namespace. It cannot directly target a Settings resource in another namespace, such as the Tenant namespace.

  • When both Tenant-level and Project-level Settings contribute to the merged configuration, their secrets may reside in different namespaces. Secrets referenced by a Tenant-level Settings resource live in the Tenant namespace (tenant-<tenant-name>), while secrets referenced by a Project-level Settings resource live in the Project namespace. Each Settings resource can reference secrets only from its own namespace.

Manage Tenant Settings​

Use the Settings Ref tab on the Tenant Settings page to:

  • Create new Tenant-level Settings.

  • Set the default Settings reference for the Tenant.

  • View and manage Settings used across Projects.

  • Edit or clone existing Settings.

The Settings Ref tab displays Settings at both the Tenant and Project levels, showing which Settings are in use across your organization.

Integration Secrets​

Each integration in a Settings resource references one or more Kubernetes secrets. PaletteAI enforces strict ownership rules for these secrets to ensure safe lifecycle management.

Secret Namespace​

All integration secrets must reside in the same namespace as their Settings resource. For example, a Settings resource in the project-docs namespace must reference secrets that also exist in project-docs. This applies to all integration types:

  • Palette: spec.integrations.palette.namespace must match the Settings namespace.

  • Hugging Face: The API key secret must be in the Settings namespace.

  • NVIDIA: The NGC API key secret and image pull secret must be in the Settings namespace.

info

When Settings are inherited or merged, secrets referenced by a Tenant-level Settings resource live in the Tenant namespace (tenant-<tenant-name>), while secrets referenced by a Project-level Settings resource live in the Project namespace. Each Settings resource is responsible only for secrets in its own namespace.

Secret Ownership​

Within a namespace, each integration secret can be referenced by only one Settings resource. The admission webhook enforces this rule on create and update. If you attempt to create or update a Settings resource that points to a secret already referenced by another Settings resource, the request is rejected.

This exclusive ownership model allows PaletteAI to safely delete secrets automatically when the owning Settings resource is deleted.

Automatic Secret Deletion​

When you delete a Settings resource, PaletteAI automatically deletes all integration secrets it references. If any secret cannot be removed, the Settings resource is retained and the deletion is blocked.

warning

Deleting a Settings resource permanently deletes its integration secrets. Before deleting, ensure you no longer need the credentials stored in those secrets, or copy them elsewhere.

Deletion Protection​

A Settings resource cannot be deleted while a non-deleting Project or Tenant still references it. If you attempt to delete one, PaletteAI returns a validation error that identifies the referencing Project or Tenant. Remove or update the reference first, then delete the Settings resource.

When to Use Tenant-Level vs. Project-Level Settings​

Consider using Tenant-level Settings when:

  • You have integrations that are common across multiple Projects.

  • You want to standardize configurations for new Projects.

  • You need centralized management of API keys and credentials.

Consider using Project-level Settings when:

  • Projects require unique integration configurations.

  • Projects need isolated credentials for security or compliance reasons.

  • Different teams manage different Projects independently.

Next Steps​

After you configure Settings, refer to the following resources for related Project administration tasks: