ZenML 0.94.4

0.94.4
Added 4
  • Add new Databricks step operator to run individual pipeline steps on Databricks
  • Support nested dynamic pipelines, allowing one dynamic pipeline to be called from within another
  • Add advanced training workload settings to Run:AI step operator including multiple mount types, workload templates, security context settings, port declarations, and parallelism configuration
  • Add parent run information display in the dashboard run details view
Changed 3
  • Improve Kubernetes string handling with separate sanitization for DNS-style names and looser label-value rules for metadata
  • Increase maximum allowed size for ZenML secrets stored in SQL secrets store to 64KB
  • Add optional tag settings to Databricks orchestrator to label jobs and cluster resources for cost tracking, ownership, and governance
Fixed 5
  • Fix signal handler registration during step execution to prevent errors when running many sync steps or interrupting pipelines
  • Fix redundant RBAC permission checks during response model dehydration
  • Allow step functions to use keyword-only arguments without causing failures
  • Fix Kubernetes orchestrator step pod configuration by replacing hardcoded lookups with proper settings calls
  • Improve Kubernetes job failure diagnostics to provide richer diagnostic information when dynamic pipeline jobs fail due to system issues
New Databricks Step Operator

You can now run individual pipeline steps on Databricks using the new Databricks step operator PR #4648. This is useful when you want specific steps to execute in the Databricks runtime while the rest of your pipeline uses a different orchestrator. The Databricks orchestrator also now supports optional tag settings to label jobs and cluster resources for cost tracking, ownership, and governance.

Nested Dynamic Pipelines

Dynamic pipelines can now be nested, allowing you to call one dynamic pipeline from within another PR #4775. This enables more modular and reusable pipeline designs.

Enhanced Run:AI Training Workload Configuration

The Run:AI step operator now supports advanced training workload settings PR #4780, including:

  • Multiple mount types (PVC, ConfigMap, Secret, NFS, S3, HostPath)
  • Workload templates via workload_template_id
  • Security context settings (UID/GID, non-root execution, seccomp, capabilities)
  • Port declarations and external URL exposure
  • Training workload parallelism and completions
Improved Kubernetes Job Failure Diagnostics

When dynamic pipeline jobs fail due to system issues (such as OOM kills), ZenML now provides richer diagnostic information PR #4800. This makes it easier to understand why Kubernetes terminated your pods.

Better Kubernetes Label Handling

Kubernetes string handling has been improved with separate sanitization for DNS-style names/keys and looser label-value rules for metadata like run, pipeline, and step IDs PR #4756. This makes it easier to navigate through runs in Kubernetes.

Increased Secret Size Limit

The maximum allowed size for ZenML secrets stored in the SQL secrets store has been increased to 64KB PR #4769. The limit applies to the combined size of all keys and values in a secret object.

Dashboard: Parent Run Display

The dashboard now displays parent run information in the run details view when available PR #1050.

  • Signal handling during step execution: Signal handlers are now properly unregistered after step execution, preventing strange errors when running many sync steps or interrupting pipelines PR #4784. Dynamic pipeline steps running in isolated environments or step operators are no longer affected by signal handling from the orchestrator.

  • RBAC performance: Fixed redundant RBAC permission checks during response model dehydration PR #4797. Previously, when permissions were already prefetched and denied, additional RBAC requests were sent unnecessarily for each sub-model.

  • Keyword-only arguments in steps: Step functions can now use keyword-only arguments without causing failures PR #4798.

  • Kubernetes orchestrator settings: Fixed step pod configuration by replacing legacy hardcoded orchestrator.kubernetes lookups with proper orchestrator.get_settings(...) calls PR #4803. Step pods now correctly apply orchestrator settings from canonical component keys while maintaining backward compatibility.

What's Changed
New Contributors

Full Changelog: https://github.com/zenml-io/zenml/compare/0.94.3...0.94.4

View original

Upgraded? How did it go?

Discussion