|
| 1 | +[id="sbo-release-notes-1-2_{context}"] |
| 2 | +// Module included in the following assembly: |
| 3 | +// |
| 4 | +// * applications/connecting_applications_to_services/sbo-release-notes.adoc |
| 5 | +:_content-type: REFERENCE |
| 6 | += Release notes for {servicebinding-title} 1.2 |
| 7 | + |
| 8 | +{servicebinding-title} 1.2 is now available on {product-title} 4.7, 4.8, 4.9, 4.10, and 4.11. |
| 9 | + |
| 10 | +[id="new-features-1-2_{context}"] |
| 11 | +== New features |
| 12 | +This section highlights what is new in {servicebinding-title} 1.2: |
| 13 | + |
| 14 | +* Enable {servicebinding-title} to consider optional fields in the annotations by setting the `optional` flag value to `true`. |
| 15 | +* Support for `servicebinding.io/v1beta1` resources. |
| 16 | +* Improvements to the discoverability of bindable services by exposing the relevant binding secret without requiring a workload to be present. |
| 17 | + |
| 18 | +[id="known-issues-1-2_{context}"] |
| 19 | +== Known issues |
| 20 | +* Currently, when you install {servicebinding-title} on {product-title} 4.11, the memory footprint of {servicebinding-title} increases beyond expected limits. With low usage, however, the memory footprint stays within the expected ranges of your environment or scenarios. In comparison with {product-title} 4.10, under stress, both the average and maximum memory footprint increase considerably. This issue is evident in the previous versions of {servicebinding-title} as well. There is currently no workaround for this issue. link:https://issues.redhat.com/browse/APPSVC-1200[APPSVC-1200] |
| 21 | + |
| 22 | +* By default, the projected files get their permissions set to 0644. {servicebinding-title} cannot set specific permissions due to a bug in Kubernetes that causes issues if the service expects specific permissions such as, `0600`. As a workaround, you can modify the code of the program or the application that is running inside a workload resource to copy the file to the `/tmp` directory and set the appropriate permissions. link:https://issues.redhat.com/browse/APPSVC-1127[APPSVC-1127] |
| 23 | + |
| 24 | +* There is currently a known issue with installing {servicebinding-title} in a single namespace installation mode. The absence of an appropriate namespace-scoped role-based access control (RBAC) rule prevents the successful binding of an application to a few known Operator-backed services that the {servicebinding-title} can automatically detect and bind to. When this happens, it generates an error message similar to the following example: |
| 25 | ++ |
| 26 | +.Example error message |
| 27 | +[source,text] |
| 28 | +---- |
| 29 | +`postgresclusters.postgres-operator.crunchydata.com "hippo" is forbidden: |
| 30 | + User "system:serviceaccount:my-petclinic:service-binding-operator" cannot |
| 31 | + get resource "postgresclusters" in API group "postgres-operator.crunchydata.com" |
| 32 | + in the namespace "my-petclinic"` |
| 33 | +---- |
| 34 | ++ |
| 35 | +Workaround 1: Install the {servicebinding-title} in the `all namespaces` installation mode. As a result, the appropriate cluster-scoped RBAC rule now exists and the binding succeeds. |
| 36 | ++ |
| 37 | +Workaround 2: If you cannot install the {servicebinding-title} in the `all namespaces` installation mode, install the following role binding into the namespace where the {servicebinding-title} is installed: |
| 38 | ++ |
| 39 | +.Example: Role binding for Crunchy Postgres Operator |
| 40 | +[source,yaml] |
| 41 | +---- |
| 42 | +kind: RoleBinding |
| 43 | +apiVersion: rbac.authorization.k8s.io/v1 |
| 44 | +metadata: |
| 45 | + name: service-binding-crunchy-postgres-viewer |
| 46 | +subjects: |
| 47 | + - kind: ServiceAccount |
| 48 | + name: service-binding-operator |
| 49 | +roleRef: |
| 50 | + apiGroup: rbac.authorization.k8s.io |
| 51 | + kind: ClusterRole |
| 52 | + name: service-binding-crunchy-postgres-viewer-role |
| 53 | +---- |
| 54 | +link:https://issues.redhat.com/browse/APPSVC-1062[APPSVC-1062] |
| 55 | + |
| 56 | +* According to the specification, when you change the `ClusterWorkloadResourceMapping` resources, {servicebinding-title} must use the previous version of the `ClusterWorkloadResourceMapping` resource to remove the binding data that was being projected until now. Currently, when you change the `ClusterWorkloadResourceMapping` resources, the {servicebinding-title} uses the latest version of the `ClusterWorkloadResourceMapping` resource to remove the binding data. As a result, {the servicebinding-title} might remove the binding data incorrectly. As a workaround, perform the following steps: |
| 57 | ++ |
| 58 | +-- |
| 59 | +. Delete any `ServiceBinding` resources that use the corresponding `ClusterWorkloadResourceMapping` resource. |
| 60 | +. Modify the `ClusterWorkloadResourceMapping` resource. |
| 61 | +. Re-apply the `ServiceBinding` resources that you previously removed in step 1. |
| 62 | +-- |
| 63 | ++ |
| 64 | +link:https://issues.redhat.com/browse/APPSVC-1102[APPSVC-1102] |
0 commit comments