I am in the process of creating a BOT using Google Dialogflow. Based on my need the free version "Standard Edition" would be sufficient.
I came across an [article][1] which mentions that it is in Beta
This is a beta release of the Dialogflow V2 API. This product might be
changed in backward-incompatible ways and is not subject to any SLA or
deprecation policy. This product is not intended for real-time usage
in critical applications.
Though from the URL I could see that this restriction is applicable for Enterprise, I just wanted to make sure that Standard Edition do not have any such restriction.
Both Dialogflow Standard and Enterprise Edition when using Dialogflow's v2 API are in beta. In other words, both editions of Dialogflow's v2 API are in beta.
Dialogflow currently has two editions and two API versions. When using Dialogflow's v1 API only Standard Edition is available and Dialogflow's v1 API Standard Edition is general available and not in beta. When using Dialogflow's v2 API your agent can either be on the Standard or Enterprise Edition. Dialogflow's v2 API is in beta regardless of whether you choose the Standard or Enterprise Edition.
Source: Dialogflow's v2 API and Enterprise Edition launched recently and are currently in beta.
Related
I am thinking about using Pulumi for Azure and was curious how up to date the API support is. I checked the storage account as an example.
Pulumi: API Version 2021-02-01
latest version according to Microsoft docs: API version 2022-09-01
Isn't that an issue? How fast is Pulumi in adding features from new API versions?
Pulumi automatically generates new SDK versions that are always up to date with the Azure APIs. So even though the documentation you linked might not show the newest version, the SDK already supports it.
https://www.pulumi.com/blog/full-coverage-of-azure-resources-with-azure-native/
Unlike the classic Azure provider, which requires manual work to keep updated, we designed the native provider to stay always up-to-date with Azure API additions and changes. We generate Pulumi SDKs for the native Azure provider automatically from Azure API specifications published by Microsoft. We publish daily builds of the provider and have published 210 versions of the provider in the last six months.
You can find the sources for the API version you mentioned on GitHub: https://github.com/pulumi/pulumi-azure-native/tree/master/sdk/dotnet/Storage/V20220901
When visiting the url - https://developer.microsoft.com/en-us/graph/graph-explorer
In the graph explorer it has a drop down 1.0 or beta. Is beta version 2.0 that Microsoft references in all of it's documentation?
https://learn.microsoft.com/en-us/azure/active-directory/develop/azure-ad-endpoint-comparison
This would be a great question answered because I do not see a drop down for v2.0
There are a couple of things to differentiate here. Azure active directory is the central identity service behind most of Microsoft SaaS services.
It provides two main things
a central identity database that stores users, groups and more. It can be accessed via the graph.windows.net API. Although it's recommended to use the Microsoft graph instead now.
authentication and authorization services. That live mostly under login.microsoftonline.com.
The later provides two versions of the service v1/v2 that implement different capabilities and protocols. (Second documentation link you're providing).
The Microsoft graph on the other hand is the central API for Microsoft 365 services.
The v1 is supported for production workloads, Microsoft is not going to break the API contract and keep the services behind it up and running.
The beta endpoint is where Microsoft makes new things available to get some feedback. Not meant for production workloads. When those new capabilities are ready for prime time, they'll show up under v1.
There's no v2 as of today for the graph. They'll publish a v2 once they need to publish breaking changes to existing capabilities to avoid breaking v1 and disrupting customers.
As per this question - Azure functions v2 only supports .Net Core
We currently have Azure Functions v1 in production using .NET 4.6.1 which rely on 3rd party dlls which we do not have a .NET Core version yet. It could be 1-2 years before we get the 3rd party dlls to .NET Core, if ever. So some key questions I think everyone will want to know about upgrades are:
Q1 - Are there any plans to have Azure Functions v2 support the regular .NET Framework in the future to make upgrading our production system possible? If so are there any rough dates of when this might be available?
Q2 - If not then how long can we expect Microsoft to support Azure Functions v1? Is there an official mainstream & extended support schedule of dates like other Microsoft products announcing when you are going to turn off Azure Functions v1 ?
The killer issue here being if Microsoft turn off Azure Functions v1 without supporting .NET Framework on Azure Functions v2 this will cause significant problems for our production system in the future and we will need to stop migrating our code base to Azure Functions due to the lack of support.
Q1: Microsoft has not announced any plans to support the Azure Functions v2 runtime with .NET Framework. They rewrote it with .NET Core specifically to fully support the latest version of .NET, while also being cross-platform. MS has a big cross-platform push in their tools and cloud support at the moment.
Q2: I haven't seen any mention as to how long the Azure Functions v1 Runtime will be supported. I would expect it to be mentioned when the v2 Runtime becomes Generally Available (GA). They haven't stated when the v2 Runtime will be GA, but with the Microsoft //Build 2018 conference coming up next week (as I write this) we may find out more then.
Overall, I would recommend waiting to see what MS announces at //Build next week, and then contact the Azure Support team directly regarding SLA's and long term support guarantees.
I have an application that relies on Azure SDK version 1.8 and Azure table and blob storage. Azure SDK 1.8 is scheduled to be "retired" November 12, 2015.
Will Azure SDK retirement stop my app from working after November 12, 2015?
What is the relationship between Azure SDK version number and and Azure Storage Version date?
What is the difference between Azure SDK retirement and Azure Storage version removal? (I get that the version removal means it won't be there to use. Does retirement mean it just won't be supported anymore but will keep working?)
Update Question: How does Azure SDK relate to "Azure Storage Client"?
What version of my Azure SDK v1.8 maps to which version of the azure storage client?
I THINK that the SDK will keep working, and that the storage service version being retired is too old to affect me, but I'd like to be sure.
Azure SDK version retirement dates are https://msdn.microsoft.com/en-us/library/azure/dn479282.aspx
Version: 1.8/October 2012
Release Date: October 2012
Retirement Date: November 12 2015
Microsoft Azure Storage Service Version Removal versions dates are http://blogs.msdn.com/b/windowsazurestorage/archive/2015/10/19/microsoft-azure-storage-service-version-removal-update-extension-to-2016.aspx
Version 2009-07-17 and prior Azure storage versions will be turned off
and will quit working.
UPDATE:
I also found this handy "Azure Storage Client" version to Azure protocol Version chart
https://msdn.microsoft.com/en-us/library/azure/dn744252.aspx
Storage Client Underlying REST
Library Version Protocol Version
------- --------
1.7 2011-08-18
2.x 2012-02-12
3.x 2013-08-15
4.x 2014-02-14
5.x 2015-02-21
6.x 2015-04-05
UPDATE:
Following this link
https://azure.microsoft.com/en-us/documentation/articles/cloud-services-guestos-update-matrix/
I found this chart
GUEST OS FAMILY SDK VERSIONS SUPPORTED
4 Version 2.1 and later
3 Version 1.8 and later
2 Version 1.3 and later
1 Version 1.0 and later
The "Cloud Services Guest OS Update Matrix" also has some scary charts that show "Disable Date" and "Expiration Dates" which indicate everything is expired (as of today 11/6/2015) prior to Guest OS 4.19. This makes no sense to me.
I sure would like to see an "Azure SDK" to "Storage Client Library" version table.
UPDATE: 12/3/2015
It kept working. According to this azure storage blog entry, it looks like the retirement date has been pushed off to next summer.
We will delay the removal date for some REST API versions and impacted
client libraries. This includes all REST endpoints starting version
2009-07-17 and earlier. The effective date for this service removal is
August 1st, 2016.
There has been some change of plans regarding the version removal. Based on the blog post by Azure Storage team, version 2009-07-17 will now retire on August 1, 2016. Please see this blog post for more details: http://blogs.msdn.com/b/windowsazurestorage/archive/2015/10/19/microsoft-azure-storage-service-version-removal-update-extension-to-2016.aspx.
Regarding the relationship between Azure SDK and Azure Storage Version, as such there's two things to consider:
Storage Client library that gets shipped with SDK.
Storage emulator that gets shipped with SDK.
By default, a SDK version will use a particular version of the library however you're free to upgrade or downgrade the storage client library as per your requirements. Earlier there used to be some dependencies between storage client library and other components of SDK (a good example would be Azure Diagnostics) but not any more.
A storage emulator is again tied to a version of storage client library. Unfortunately if you want to use the storage emulator, then you must use the storage client library it supports. For example, you can't use storage client library version 6 and storage emulator version 4. If you want to use the latest version, and the emulator doesn't support it then you must do all your development against actual cloud storage.
Azure Storage is managed by a REST API and this API is versioned where each new version offers some improvements over the previous versions (and at times remove or change the functionality offered in the previoud version). When they say "Version Removal" essentially what is meant is that particular version of Storage REST API won't be supported. What that also means is that any client library that is tied to that particular REST API version will also stop working.
UPDATE
To answer your specific questions:
Will Azure SDK retirement stop my app from working after November 12,
2015?
Honestly, I don't know (but I will be very curious to know). Each SDK is targeted for specific Guest OS version. From this link (https://azure.microsoft.com/en-us/documentation/articles/cloud-services-guestos-update-matrix/), I gather that SDK 1.8 targets Guest OS Family 3. If you're targeting a specific Guest OS version in your application (please check service configuration file and service for the target OS version) and if that version is set to disabled (and subsequently expire), then I think it would break your application.
What is the relationship between Azure SDK version number and and
Azure Storage Version date?
By default, a SDK version will use a particular version of the library however you're free to upgrade or downgrade the storage client library as per your requirements. Earlier there used to be some dependencies between storage client library and other components of SDK (a good example would be Azure Diagnostics) but not any more.
What is the difference between Azure SDK retirement and Azure Storage
version removal? (I get that the version removal means it won't be
there to use. Does retirement mean it just won't be supported anymore
but will keep working?)
Honestly, I don't know. Sorry!
Update Question: How does Azure SDK relate to "Azure Storage Client"?
What version of my Azure SDK v1.8 maps to which version of the azure
storage client?
Azure SDK 1.8 makes use of Storage Client Library 2.0 (from SDK 1.8 release notes) and Storage Client Library 2.0 targets REST API Version 2012-02-12 (from Protocol Version Support for .NET Client Library Versions)
You can also check the version of storage client library by going into ref directory in your Azure SDK installation directory.
As a Microsoft Azure services client, I received earlier today the following mail: http://aka.ms/Qga48e.
I was wondering how I could migrate my Blob storage without services disruption to use the latest Azure File Storage service.
Anybody has already performed this action? Any feedbacks will be welcomed.
Thanks.
I don't think that it would be necessary. Besides Azure Blob Service and Azure File Service serve different purposes all together and the things you could do with blob service can't be done through file service.
As mentioned in the newsletter, what you should try to do is upgrade your client applications to make use of latest version of storage client library. If you're using an older version of library (< 2.0), there would be some pain in migration but migrating from 2.0 to 4.x (currently latest version) should be rather painless.
Next thing you should look into is the default service version of your storage account services. If you're using .Net storage client library, you can fetch it via GetServicePropertiesAsync method. You can update the default service version using SetServicePropertiesAsync method.
You may also find this link helpful about understanding storage service versioning: http://msdn.microsoft.com/en-us/library/azure/dd894041.aspx.
UPDATE: 13-DEC-2014
Azure Storage Team has published a blog post which talks more about this issue: http://blogs.msdn.com/b/windowsazurestorage/archive/2014/08/05/microsoft-azure-storage-service-version-removal.aspx.
The Storage Service REST API is not being removed. There are several versions of the API, from over the years. Older versions of the REST API (prior to the 2012-02-12 version) are being retired. But it's definitely not going away, and neither is the Azure Storage service.
Different versions of the SDKs (across the various language stacks) and command-line tools (PowerShell, CLI) may be using one of the older versions. If you're using the current versions of SDKs and command-line tools, this has no effect on you.
Consider how many versions there have been (all tracked here, and all listed in the page you linked to in your answer:
2014-02-14 (current)
2013-08-15
2012-02-12
2011-08-18
2009-09-19
2009-07-17
2009-04-14
If you're using an older version of an SDK or command-line tool, there's a chance that, in Dec. 2015, it won't work as expected anymore, as the underlying version will have been retired. So, essentially you have until December 2015 to update your Azure projects if needed.