Skip to content

v1.2.0

Latest
Latest

Choose a tag to compare

View all tags
@github-actions github-actions released this 24 Jul 12:45
v1.2.0
24db292

Highlights

  • Project Release Lifecycle — Manage shared, project-scoped infrastructure (cell namespaces, NetworkPolicies, ResourceQuotas, RBAC, etc.) as versioned, immutable snapshots that can be promoted across environments.
  • Portal Assistant Enhancements — Get automated suggestions to troubleshoot build and runtime issues during deployments.
  • Shell Access for Components — Open an interactive shell to running component instances directly from the Backstage portal.
  • Improved Release & Deployment Experience — Browse and compare releases, review configuration differences, manually trigger CronJob releases, and manage deployments through a redesigned workflow.
  • Advanced Observability — View Kubernetes events and Cilium Hubble wire logs through the Observer API and Backstage portal.
  • Enhanced Security — Internal communication between components and the Cluster Gateway is now secured with mutual TLS (mTLS), and ABAC policies now support authorization conditions based on resource type, component type, and workflow.
  • Platform Improvements — Configure workload scheduling using Helm affinity and topology spread constraints, and automatically scale workloads to zero using KEDA for improved resource efficiency.
  • Developer Experience — Try out OpenAPI and GraphQL APIs directly from the Backstage portal, along with numerous bug fixes and stability improvements across the platform.

Breaking Changes

v1.2.0 introduces the project release lifecycle (ProjectType, ClusterProjectType, ProjectRelease, ProjectReleaseBinding) and makes Project.spec.type a required, immutable field. Upgrading from v1.1.x is not just a plain helm upgrade, it requires a short, staged migration.

Read the v1.1 → v1.2 upgrade guide (https://openchoreo.dev/docs/platform-engineer-guide/upgrades/v1.1-to-v1.2/) before upgrading. Installing the v1.2.0 CRDs before backfilling Project.spec.type will halt control-plane reconciliation for every existing project. Running workloads on data planes are not affected; only control-plane reconciliation pauses during the upgrade window, and the migration is reversible (see the guide's Rollback section).

Here are the changes:

  1. Project.spec.type is now required and immutable

Every Project must reference a (Cluster)ProjectType:

spec:
  type:                       # NEW — required, immutable
    kind: ClusterProjectType  # defaults to ProjectType if omitted
    name: default
  • Who's affected: every install with Project resources created on v1.1.x (they have no spec.type).
  • Impact: once the strict v1.2.0 CRD is installed, any write to a Project without spec.type is rejected with spec.type: Required value. Because the v1.1.x controller writes Project status on every reconcile, installing the strict CRD before backfilling breaks reconciliation for all existing projects. The field is immutable once set.
  • Action required: follow the upgrade guide: pause control-plane writers, install the relaxed Project CRD, backfill spec.type (name: default for existing projects), then install the strict CRD set and upgrade. A default ClusterProjectType that provisions only the namespace ships with the release.
  1. Projects must be deployed to an environment before their components

In v1.1.x the RenderedRelease controller implicitly created a project's cell namespace (dp-{orgNamespace}-{project}-{env}-{hash}). v1.2.0 removes that. The namespace is now part of the project's released manifests, applied through the Project release lifecycle.

The controller does not automatically create ProjectReleaseBindings, so the Projects will not be automatically deployed. But in clients (Backstage UI, occ), you have the option to offer a one-shot "deploy to all environments".

  • Who's affected: anyone creating new projects after the upgrade, and any automation that assumed a component could deploy to an environment before the project was deployed there.
  • Impact:
    • Migrated projects (from previous version): no disruption. The binding's RenderedRelease server-side-applies a Namespace with the exact name your workloads already use; the existing namespace is adopted, not recreated.
    • New projects: a component deploys to an environment only after its project is released (deployed) there.
  • Action required: for existing projects, the upgrade guide creates one ProjectReleaseBinding per pipeline environment, so deployed state carries over. Going forward, deploy the project before its components.

Full upgrade instructions: v1.1.x → v1.2.x upgrade guide (https://openchoreo.dev/docs/platform-engineer-guide/upgrades/v1.1-to-v1.2/)

What's Changed

New Contributors

Full Changelog: v1.0.0...v1.2.0

Contributors

tishan89, kavix, and 34 other contributors
Assets 16
Loading