[Monitor Query] Update swagger

[pvaneck]

The swagger file commit SHAs are updated and the code is regenerated.

[azure-sdk]

API change check

API changes are not detected in this pull request.

[pvaneck]

/azp run python - monitor - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[xiangyan99]

Do we want to expose something like https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/search/azure-search-documents/azure/search/documents/_api_versions.py?

[pvaneck]

Do we want to expose something like https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/search/azure-search-documents/azure/search/documents/_api_versions.py?

I think in the next API version updates, this will be a good idea. This is the first API version where all the metrics APIs are aligned under the same version, and going forward the versions should update in sync. I'll save it for the next time the version is updated.

[xiangyan99]

Do we want to expose something like https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/search/azure-search-documents/azure/search/documents/_api_versions.py?

I think in the next API version updates, this will be a good idea. This is the first API version where all the metrics APIs are aligned under the same version, and going forward the versions should update in sync. I'll save it for the next time the version is updated.

I am a little confused, didn't we support api version 2023-10-01?

[pvaneck]

I am a little confused, didn't we support api version 2023-10-01?

Most metrics query operations did support 2023-10-01, but metric namespace operations used 2017-12-01-preview. This new updated version aligns all metrics api versions to be the same, and I don't want to create an enum for 2023-10-01 if not all metrics operations support it. (The metrics api versions were in a bit of a messy state that is now corrected)

[xiangyan99]

I am a little confused, didn't we support api version 2023-10-01?

Most metrics query operations did support 2023-10-01, but metric namespace operations used 2017-12-01-preview. This new updated version aligns all metrics api versions to be the same, and I don't want to create an enum for 2023-10-01 if not all metrics operations support it. (The metrics api versions were in a bit of a messy state that is now corrected)

Do you mean we made a GA release on preview API version? Is it by design?

[pvaneck]

Do you mean we made a GA release on preview API version? Is it by design?

Yes, specifically for the arm metrics namespaces endpoint. Not sure the history behind this decision since this was well before my time, but now action has been taken to better align with Azure policies (i.e. versioning uniformly, not using preview in a GA).

[xiangyan99]

Do you mean we made a GA release on preview API version? Is it by design?

Yes, specifically for the arm metrics namespaces endpoint. Not sure the history behind this decision since this was well before my time, but now action has been taken to better align with Azure policies (i.e. versioning uniformly, not using preview in a GA).

Do you mean we made a GA release on preview API version? Is it by design?

Yes, specifically for the arm metrics namespaces endpoint. Not sure the history behind this decision since this was well before my time, but now action has been taken to better align with Azure policies (i.e. versioning uniformly, not using preview in a GA).

So the new API 2024-02-01 is fully compatible with old ones, 2023-10-01 & 2017-12-01-preview? Can user explicitly specify old versions?

[pvaneck]

So the new API 2024-02-01 is fully compatible with old ones, 2023-10-01 & 2017-12-01-preview? Can user explicitly specify old versions?

Yea, 2024-02-01 has the same apis as 2023-10-01 and 2017-12-01-preview for metrics. Some context here: Azure/azure-rest-api-specs#27559 (comment)

A user can still explicitly specify old versions with the api_version kwarg for each operation. Older versions still work.