Project: KubeStellar (Orchestration & Management / Scheduling & Orchestration)
File: release-notes.md

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. The main change is introduction of the an all-in-one chart, called the hub chart, for installing KubeStellar in a given hosting cluster and creating an initial set of WDSes and ITSes. 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 for full details. 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. 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. This release mainly updates the documentation exposed under kubestellar.io. This release introduces pluggable transport. Currently the only plugin is . dynamic changes to WECs are

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. 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. 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.