Fixed issues in Cloudera AI on premises 1.5.5 SP3

Previously, some Spark Executor records contained null startTime variables, leading to a NullPointerException exception and causing those workloads to be dropped. This stemmed from a logic that rewrote all failed executors to stopped status, even when they had never started due to issues such as OOM errors or image‑pull failures.This issue is now fixed. The logic checks the running_at variables so executors that never started remain failed, while only those that actually ran become stopped. Additional fixes ensure that Kubernetes failure reasons surface correctly, interactive‑session executors inherit the proper session CRN, and sessions failing before pod creation are no longer excluded. These changes improve failure reporting and prevent workload records from being lost.

Previously, when the Enable Public IP Address for Load Balancer option was enabled, model deployment workloads attempted to access internal services, such as the S2i image registry, through external network paths. This forced a Pod > NAT Gateway > Internet > Public Load Balancer routing, violating VPC‑only traffic requirements and causing timeouts when NAT IPs were not on an allowlist.

This issue is now fixed. Automatic internal routing through host‑level DNS redirection is introduced. A new `inject-s2i-host-mapping` init container in the image‑puller DaemonSet maps the external S2i registry domain to the internal Istio ingress IP, ensuring that traffic remains inside the VPC.

Previously,jobs were hard‑deleted from the database, leaving dashboard job‑run records without valid references and causing historical job details to display an empty workload_crn identifier. This behavior was inconsistent with sessions, applications, and models, which already use soft delete.

This issue is now fixed. Jobs support soft delete through a new deleted_at timestamp. Deleting a job sets this timestamp instead of removing the row, and associated cron entries are handled the same way. Read paths exclude soft‑deleted jobs so they are no longer displayed in the UI, while the existing cleanup process still performs hard deletes after the configured retention period. This ensures historical job runs retain a valid workload_crn` identifier even after the job is deleted.

Previously, updating the GPU or other resource settings on a stopped application correctly changed the accelerator_label_id key-value pair in the applications table. However, when the application was restarted, the previous GPU configuration was still used because the restart logic was reading stale values from the dashboards table instead of the updated fields in the applications table. This occurred because of incorrect field names in the _.pick() call, which used snake_case instead of the expected camelCase. The same issue affected the resource_group_id and resource_profile_id key-value pairs.

This issue is now fixed. The field mappings are corrected so that updated GPU and resource settings now apply properly when applications are restarted.

Previously, the Kerberos TGT (Ticket Granting Ticket) lifetime in Cloudera AI was fixed at the default value of 15 minutes and could not be configured. This led to authentication failures (MutualAuthenticationError) during long-running operations such as database queries exceeding the ticket lifetime.

This issue is now fixed and Cloudera AI allows configuring the TGT ticket lifetime. Users can extend the lifetime, for example, to 8 hours, to support long‑running workloads without encountering Kerberos reauthentication failures.

Previously, restarting Cloudera Embedded Container Service nodes created duplicate entries in the node_labels database table for the same GPU type. This resulted in duplicate GPU registrations being displayed in Site Administration > Runtime > Workload Accelerators and similarly, appeared in the Resource Profile > GPU Type drop-down menu when launching a session. Selecting a duplicate GPU entry while launching a session triggered the This accelerator has been removed error.

This issue is now fixed. To prevent duplicate GPU label entries in node_labels a UNIQUE constraint is now added and the application uses an UPSERT so existing entries are updated instead of duplicated.

Previously, workbenches could be created with uppercase characters or names beginning or ending with a hyphen, but their installation failed because Kubernetes resource names must use only lowercase alphanumeric characters, '-', or '.'.

This issue is now fixed by adding validation that rejects invalid workbench names, preventing provisioning attempts with unsupported naming formats.

The Workbench API and the Workbench Details page were displaying different quota values because the describe‑workbench API returned the quota of the service pool rather than the actual workbench quota.

This issue is now fixed, and the describe‑workbench API now correctly returns the workbench‑specific quota.

Previously, no alert was triggered when configuration did not have sufficient quota. This issue is now resolved. When creating a session, job, or application, an alert notifies the user if the configuration does not have sufficient quota.

GPU utilization metrics were not visible in the Cloudera AI Quota Management dashboard. This issue is now fixed.

Previously, users authorized to run model inference were incorrectly denied access due to incomplete permission checks.

This issue is now fixed. Project authorization logic is centralized to ensure consistent validation across services, and affected services are updated to use the new logic.

When Quota Management is enabled, concurrent session creation API requests fail with RemoteDisconnected errors.

Following the introduction of pagination to the Jobs API, the parent job selection dropdown previously only displayed the first 10 entries when scheduling a dependent job in projects with a high volume of workloads.

This issue is now resolved by replacing the legacy dropdown with an optimized, paginated component that fetches jobs in batches of 10 as a user scrolls down the list, significantly reducing backend API load. Additionally, a search filter has been integrated into the new interface, allowing users to quickly locate and select from the full list of available parent jobs.

Following the introduction of pagination to the Jobs API, multiple UI interactions failed to process data beyond the first 10 results. This issue is now resolved, the Project Overview page now correctly supports pagination, and the Unable To Get License Details error triggered by dependent jobs outside the first page has been eliminated.

Previously, when a user logged in for the first time, the authorization token was not included in the request header, causing the API call to fail with an error. This issue is now fixed. The authentication token is now correctly passed on initial login, ensuring seamless project discovery.

Previously, a warning was displayed in the browser console immediately after landing on the home page. This warning did not impact the ability to use the Quick Find feature. This issue is now fixed.

The Last worked on timestamp on the project listing page was previously updated by automated background events like scheduled job executions, making the activity metric unreliable. This issue has been resolved so that the timestamp now exclusively tracks actual user-driven activity, such as creating projects, modifying workloads, manually starting sessions, or performing file operations. Automated system processes and scheduled job runs will no longer trigger an update to this metric.