Skip to content

Release notes#

The following sections list the known issues for each release. The issue list is not differential (i.e., compared to previous releases) but a full list representing the overall state of the specific release.

0.22.0 and its release candidates#

The changes include adding the following features.

  • Custom WEC-independent transformations of workload objects on their way from WDS to WEC.
  • WEC-dependent Go template expansion in the strings of a workload object on its way from WDS to WEC.
  • PriorityClass objects (from API group scheduling.k8s.io) propagate now.
  • Support multiple WDSes.
  • Allow multiple ITSes.
  • Use the new Helm chart from kubestellar/ocm-transport-plugin for deploying the transport controller.

Prominent bug fixes include more discerning cleaning of workload objects on their way from WDS to WEC. This includes keeping a "headless" Service headless and removing the spec.suspend field from a Job.

See the changelogs on GitHub for full details.

Remaining limitations in 0.22.0 and its release candidates#

  • Removing of WorkStatus objects (in the transport namespace) is not supported and may not result in recreation of that object
  • Singleton status return: It is the user responsibility to make sure that if a BindingPolicy requesting singleton status return matches a given workload object then no other BindingPolicy matches the same object. Currently there is no enforcement of that.
  • Objects on two different WDSs shouldn't have the exact same identifier (same group, version, kind, name and namespace). Such a conflict is currently not identified.

0.21.2 and its release candidates#

The changes since 0.21.1 include efficiency improvements, reducing costs of running the kubestellar-controller-manager for a WDS that is an OpenShift cluster. There are also bug fixes and documentation improvements.

0.21.1#

This release mainly updates the documentation exposed under kubestellar.io.

0.21.0 and its release candidates#

Major changes for 0.21.0 and its release candidates#

Bug fixes in 0.21.0 and its release candidates#

  • dynamic changes to WECs are supported. Existing Bindings and ManifestWorks will be updated when new WECs are added/updated/delete or when labels are added/updated/deleted on existing WECs
  • An update to a workload object that removes some BindingPolicies from the matching set is handled correctly.
  • These changes that happen while a controller is down are handled correctly:
  • If a workload object is deleted, or changed to remove some BindingPolicies from the matching set;
  • A BindingPolicy update that removes workload objects or clusters from their respective matching sets.

Remaining limitations in 0.21.0 and its release candidates#

  • Removing of WorkStatus objects (on the transport namespace) is not supported and may not result in recreation of that object
  • Singleton status return: It is the user responsibility to make sure that if a BindingPolicy requesting singleton status return matches a given workload object then no other BindingPolicy matches the same object. Currently there is no enforcement of that.
  • Objects on two different WDSs shouldn't have the exact same identifier (same group, version, kind, name and namespace). Such a conflict is currently not identified.

0.20.0 and its release candidates#

  • Dynamic changes to WECs are not supported. Existing ManifestWorks will not be updated when new WECs are added or when labels are added/deleted on existing WECs
  • Removing of WorkStatus objects (on the transport namespace) is not supported and may not result in recreation of that object
  • Singleton status return: It is the user responsibility to make sure that if a BindingPolicy requesting singleton status return matches a given workload object then no other BindingPolicy matches the same object. Currently there is no enforcement of that.
  • Objects on two different WDSs shouldn't have the exact same identifier (same group, version, kind, name and namespace). Such a conflict is currently not identified.
  • An update to a workload object that removes some BindingPolicies from the matching set is not handled correctly.
  • Some operations are not handled correctly while the controller is down:
  • If a workload object is deleted, or changed to remove some BindingPolicies from the matching set, it will not be handled correctly.
  • A BindingPolicy update that removes workload objects or clusters from their respective matching sets is not handled correctly.