dapr · artursouza · Dec 6, 2021 · Nov 30, 2021 · Dec 3, 2021 · Dec 6, 2021
@@ -1,23 +1,23 @@
 apiVersion: v1
-appVersion: "1.4.4-rc.2"
+appVersion: "1.4.4"
 description: A Helm chart for Dapr on Kubernetes
 name: dapr
-version: 1.4.4-rc.2
+version: 1.4.4
 dependencies:
   - name: dapr_rbac
-    version: "1.4.4-rc.2"
+    version: "1.4.4"
     repository: "file://dapr_rbac"
   - name: dapr_operator
-    version: "1.4.4-rc.2"
+    version: "1.4.4"
     repository: "file://dapr_operator"
   - name: dapr_placement
-    version: "1.4.4-rc.2"
+    version: "1.4.4"
     repository: "file://dapr_placement"
   - name: dapr_sidecar_injector
-    version: "1.4.4-rc.2"
+    version: "1.4.4"
     repository: "file://dapr_sidecar_injector"
   - name: dapr_sentry
-    version: "1.4.4-rc.2"
+    version: "1.4.4"
     repository: "file://dapr_sentry"
   - name: dapr_dashboard
     version: "0.8.0"

@@ -76,7 +76,7 @@ The Helm chart has the follow configuration options that can be supplied:
 | Parameter                                 | Description                                                             | Default                 |
 |-------------------------------------------|-------------------------------------------------------------------------|-------------------------|
 | `global.registry`                         | Docker image registry                                                   | `docker.io/daprio`      |
-| `global.tag`                              | Docker image version tag                                                | `1.4.4-rc.2`            |
+| `global.tag`                              | Docker image version tag                                                | `1.4.4`            |
 | `global.logAsJson`                        | Json log format for control plane services                              | `false`                 |
 | `global.imagePullPolicy`                  | Global Control plane service imagePullPolicy                            | `IfNotPresent`          |
 | `global.imagePullSecrets`                 | Control plane service images pull secrets for docker registry            | `""`                   |

@@ -2,4 +2,4 @@ apiVersion: v1
 appVersion: "1.0"
 description: A Helm chart for Dapr configuration
 name: dapr_config
-version: 1.4.4-rc.2
+version: 1.4.4
@@ -2,4 +2,4 @@ apiVersion: v1
 appVersion: "1.0"
 description: A Helm chart for Dapr Kubernetes Operator
 name: dapr_operator
-version: 1.4.4-rc.2
+version: 1.4.4
@@ -2,5 +2,5 @@ apiVersion: v1
 appVersion: "1.0"
 description: A Helm chart for Dapr Kubernetes placement
 name: dapr_placement
-version: 1.4.4-rc.2
+version: 1.4.4
 
@@ -2,5 +2,5 @@ apiVersion: v1
 appVersion: "1.0"
 description: A Helm chart for Dapr Kubernetes RBAC components
 name: dapr_rbac
-version: 1.4.4-rc.2
+version: 1.4.4
 
@@ -2,4 +2,4 @@ apiVersion: v1
 appVersion: "1.0"
 description: A Helm chart for Dapr Sentry
 name: dapr_sentry
-version: 1.4.4-rc.2
+version: 1.4.4
@@ -2,4 +2,4 @@ apiVersion: v1
 appVersion: "1.0"
 description: A Helm chart for the Dapr sidecar injector
 name: dapr_sidecar_injector
-version: 1.4.4-rc.2
+version: 1.4.4
@@ -1,6 +1,6 @@
 global:
   registry: docker.io/daprio
-  tag: "1.4.4-rc.2"
+  tag: "1.4.4"
   dnsSuffix: ".cluster.local"
   logAsJson: false
   imagePullPolicy: IfNotPresent

@@ -0,0 +1,87 @@
+
+# Dapr 1.4.4
+
+## Summary
+
+This release addresses several issues with the following fixes:
+* Adds retry logic for TooManyRequests initialization error for CosmosDb State and Binding components (https://github.com/dapr/components-contrib/pull/1329)
+* Add scopes to Pub/Sub subscription conversion from `v1alpha1` to `v2alpha1`
+(https://github.com/dapr/dapr/issues/3914)
+* Upgrade `github.com/nhooyr/websocket` to > 1.8.6 with DoS vulnerability fixes
+(https://github.com/dapr/dapr/pull/3892)
+
+## Upgrading
+
+**Important**: If upgrading to this version using Helm instead of the Dapr CLI, you will need to update the Subscription CRD prior to performing the Helm upgrade.
+
+```cli
+kubectl replace -f https://raw.githubusercontent.com/dapr/dapr/v1.4.4/charts/dapr/crds/subscription.yaml
+```
+## Details
+
+### Initialization erros of Azure Cosmos DB components & Production Guidance
+
+#### Overview
+
+- New **strongly advised** production guidance for Azure Cosmos DB components have been established.
+- Dapr now retries connecting to Azure Cosmos DB during sidecar initialization.
+
+#### Problem
+
+Some sidecars with Azure Cosmos DB components (both Output Binding and State Store) fail to initialize, causing the sidecar to restart or hang (up to the `initTimeout` duration which is 5 seconds by default). Sidecar logs show a response from Cosmos DB with status `429 Request rate too large`.
+
+#### Root cause
+
+Every new connection to Azure Cosmos DB initially performs a large number of metadata requests ([Cosmos DB documentation](https://docs.microsoft.com/azure/cosmos-db/sql/troubleshoot-request-rate-too-large#rate-limiting-on-metadata-requests)). The metadata request rate limit for Azure Cosmos DB Accounts can easily be exceeded when multiple connections to the same Azure Cosmos DB account (even distinct datatabases within the same account) are made simultaneously. If the attempt to initialize the component and connect to Azure Cosmos DB fails due to this rate limit Dapr did not previously retry the connection until the sidecar restarts.
+
+
+#### Solution
+
+The following **production best practices** must be applied to minimize the likelihood this issue will occur:
+- Ensure applications and sidecars only load the Azure Cosmos DB component when it is required for that application, which avoid unnecessary database connections from other microservices or applications. This can be done by [scoping your components to specific applications](https://docs.dapr.io/operations/components/component-scopes/#application-access-to-components-with-scopes).
+- Choose deployment strategies that sequentially deploy or start all applications to minimize bursts in new connections to your Azure Cosmos DB accounts. 
+- Avoid reusing the same Azure Cosmos DB account for unrelated databases or systems (even outside of Dapr). Distinct Azure Cosmos DB accounts have distinct rate limits.
+
+Additionally, **Dapr now retries establishing the initial Azure Cosmos DB connection for up to 5 minutes, when the component is configured by setting the `initTimeout` value**. 
+
+The default component initialization timeout is 5 seconds. Please update your [component definitions](https://docs.dapr.io/operations/components/component-schema/) specifying a greater `initTimeout` duration value for the component to attempt reconnections. Note that this will delay the readiness of your sidecar. In Kubernetes you may need to [adjust your liveness and readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
+
+### Add scopes to Pub/Sub subscription conversion from `v1alpha1` to `v2alpha1`
+
+#### Overview
+
+In order to add the Pub/Sub routing preview feature, the subscriptions CRD required a new version `v2alpha1`. This requires the Dapr operator to provide a conversion webhook that converts `v1alpha1` to `v2alpha1`.
+
+#### Problem
+
+Subscriptions created as `v1alpha1` would drop the scopes when converted by the operator to `v2alpha1`.
+
+#### Root cause
+
+The conversion function was not copying the `Scopes` field from `v1apha1` to `v2alpha1`.
+
+#### Solution
+
+The conversion function was updated to include copying the `Scopes` field.
+
+### Upgrade `github.com/nhooyr/websocket` to > 1.8.6 with DoS vulnerability fixes
+
+#### Overview
+
+From [https://security.snyk.io/vuln/SNYK-GOLANG-GITHUBCOMNHOOYRWEBSOCKET-1244800](https://security.snyk.io/vuln/SNYK-GOLANG-GITHUBCOMNHOOYRWEBSOCKET-1244800):
+
+[github.com/nhooyr/websocket](https://github.com/nhooyr/websocket) is a minimal and idiomatic WebSocket library for Go.
+
+Affected versions of this package are vulnerable to Denial of Service (DoS). A double channel close panic is possible if a peer sent back multiple pongs for every ping. If the second pong arrived before the ping goroutine deleted its channel from the map, the channel would be closed twice and a panic would occur.
+
+#### Root cause
+
+Dapr was using v1.8.6 of the package.
+
+#### Solution
+
+The package was upgrade to v1.8.7.
+
+## Related releases
+
+Applications using the `1.5.x` release of Dapr should consider taking the related `1.5.1` release (or higher) that addresses a similar set of issues.