Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/Azure/Azure-Functions/issues/1987 below:

Functions V4 - Require a minimum version for supported extensions · Issue #1987 · Azure/Azure-Functions · GitHub

This issue proposes that functions V4 should require a minimum version for each of the supported functions extensions (storage, eventhubs, servicebus, etc).

Discussion for this proposal: #1988

Read this comment below for instructions on how to resolve.

We often fix bugs in our extensions, or update our extensions to use newer Azure SDKs that have relevant bug fixes. Unfortunately, we are not able to guarantee that our customer receive those fixes. As a result, often the first step when engaged in a support case is to have a customer update their extensions to the latest version. Sometimes we ask the customer to do this simply because the newer extension has better logging, and that can make a big difference for tracking the problem down.

For functions V4, we could reduce the size of this problem by adding logic that rejects extensions that are no longer supported. For example, we are still releasing fixes for Microsoft.Azure.WebJobs.Extensions.Storage 4.x, but the same is not true for 3.x - so why even let a v4 function app load a 3.x storage extension?

The functions host will enforce the proposed minimum versions in the table below. If an older version of one of the following extensions is present, the host will throw an error specifying the minimum required version and fail to start.

We can modify these to be less restrictive in terms of required patch version if we want to reduce how many customers will have to do an update as part of their upgrade to V4.

Note that none of the above versions reference any of the modern Azure SDKs that were released recently. Many of those SDKs have breaking changes and this proposal does not attempt to enforce that customers use those. Such a change would require customers to do significant code rewrites to be able to move to functions V4, which is not desirable.

A side effect of this will be to reject loading an application that is using the 1.0 extension bundle. We would probably implement a check for that so that we can provide a friendly error message (please upgrade to the 2.0 bundle).

Every non .NET user on the 1.0 bundle would be impacted when they try to upgrade to V4. Updating their host.json to reference the 2.0 bundle should be relatively straightforward as we have not seen much evidence of breaking changes between the major versions of the libraries in bundles 1.0 and 2.0.

For a .NET user, they would have to do a set of NuGet updates to get the supported extensions installed. Because Azure SDK API surface area is more directly accessable in .NET function apps, some of these customers would need to make small code changes to get their code compiling, but there are no known breaks that force a significant code rewrite.

We suspect around 60% of apps upgraded to V4 will require this change.

It would be straightforward to put this behind a flag, but doing so defeats the purpose. I suggest only adding a compat flag if we discover really significant upgrade blockers that are impacting customers from upgrading to V4 (especially once .NET 3.1 end-of-life gets close).

We could try to use more aggressive detection of older extensions as part of the support case submission flow. However this means that customers will spend more time struggling with bugs during development time that have been fixed long ago. It also will not deflect github issues being filed about previously fixed issues.

Yes this is trivial - we already have detectors that check the extension versions, and we can also write a detector that catches the "extension is too old and not supported" error and directs the user with specific instructions.

In the long term, this change should have a positive support impact. Cases are often resolved by just having a customer upgrade their extensions. In the short term, we might see some support case volume due to customers hitting this error when upgrading to V4. We should be able to deflect a significant portion of that by implementing a detector as mentioned above. The remaining support volume would be due to customers that do not want to upgrade their extensions for unanticipated reasons. I expect this would be low volume.

Support would need to be notified of the change, but ideally deflection would be in place by the time the change is enforced.

We'd need to update the documentation for each binding to spell out this minimum version that applies to V4.

I believe this change would only impact the host. We can consider an analyzer (helps catching the problem as part of CI).

No expected perf impact.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4