Jeff has pointed out that the current practice in the SDK of having a ServiceVersion which contains the current API versions of the service (for instance:
```c++
class ServiceVersion final {
public:
explicit ServiceVersion(std::string version) : m_version(std::move(version)) {}
AZ_STORAGE_QUEUES_DLLEXPORT const static ServiceVersion V2018_03_28;
AZ_STORAGE_QUEUES_DLLEXPORT const static ServiceVersion V2020_10_01;
};
)
```
Has a problem because the `ServiceVersion` construct has an implication that each of the `ServiceVersion` values listed is fully supported by the SDK.
The reality is that the SDK client team only tests the most recent API version listed in the SDK (the value which is the default version listed in the `ServiceClient` constructor).
How do we resolve this issue?
There are a few possible solutions that we’ve explored:
1) Test all the API versions listed in the `ServiceVersion` enumeration.
2) Remove the unsupported values from the `ServiceVersion` enumeration.
3) Remove the `ServiceVersion` enumeration
4) Remove the ability to set the API version at all.
Each of these solutions has some fairly significant drawbacks.
1) Test all the API versions listed.
The core problem with this is that the SDK team is small and adding tests to support every possible API version is going to be prohibitively expensive.
2) Remove the unsupported values from the `ServiceVersion` enumeration.
This is a breaking change and it means that moving to a new API version requires a breaking change to the SDK, even if the changes between API versions is strictly additive.
3) Remove the ServiceVersion enumeration.
This is also a breaking change for shipping SDKs (specifically KeyVault and Storage Queues). However, it is a one-time breaking change and we don’t have evidence of customers actually using the feature.
4) Remove the ability to set the API version at all.
Having *some* mechanism to set the API version is an important “escape hatch” which will allow customers to specify a specific API version even if that API version is not fully supported.
After discussing this a LOT, [@Ahson Khan](mailto:ahkha@microsoft.com), [@Rick Winter](mailto:Rick.Winter@microsoft.com), [@Jeffrey Richter](mailto:jeffreyr@microsoft.com), [@George Arama](mailto:George.Arama@microsoft.com), and [@Larry Osterman](mailto:Larry.Osterman@microsoft.com) came to the conclusion that we should probably take option #3, but leave the ClientOptions.Version value as a std::string.
* Removed internal references from public headers
* Updated changelog files
* Updated DistributedTracing.md to reflect Factory construction of Azure::Core::Tracing::OpenTelemetry::OpenTelemetryProvider type
Co-authored-by: Ahson Khan <ahkha@microsoft.com>
Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com>
* stress test script and docs migration from test to pg cluster
* comments for stress-test-deployment-lib script
Co-authored-by: Albert Cheng <albertcheng@microsoft.com>
* Update verify-readme to take a single or multiple paths
* chance ScanPaths to a comma delimited list and coalesce ScanPath/ScanPaths into a single variable for the script
* VS Code was nice enough to add an extra single quote when adding a quote to the end of the line'
* Capture ScanPaths.Split into an array so we don't have to call Split again
Co-authored-by: James Suplizio <jasupliz@microsoft.com>
We had continueOnError set to true so if the emulator failed to start we would still try to run the tests which all fail but take a long time to run. The timeout for this step is about 10mins of trying so that should be enough time and so we also don't really need another retry step.
Co-authored-by: Wes Haggard <weshaggard@users.noreply.github.com>
* Support local addons path override in stress test deployment
* Support username based deployId in local stress deployment
* Support WhatIf in stress infrastructure provision script
* Simplify stress user detection
Co-authored-by: Wes Haggard <weshaggard@users.noreply.github.com>
* Run helm plugin add with helper
* Add WhatIf support to ps module install helper function
Co-authored-by: Ben Broderick Phillips <bebroder@microsoft.com>
Co-authored-by: Wes Haggard <weshaggard@users.noreply.github.com>
* one commit to rule them all
* main merge
* error
* main merge
* error
* main merge
* error
* main merge
* error
* example of perf test
* remove file
* create certs and keys in post setup, use to run the test
* PR comments
* ManagedIdentityCredential: Add support for AppServiceV2019
* Attempt to create 2019 before 2017
* Changelog update
Co-authored-by: Anton Kolesnyk <antkmsft@users.noreply.github.com>
* Increment package version after release of azure-security-keyvault-certificates
* Increment package version after release of azure-security-keyvault-secrets
* Update the order of remarks and examples to align with docs.ms
* change all occurance
* Update class.tmpl.partial
Co-authored-by: sizhu <sizhu@microsoft.com>
Co-authored-by: Sima Zhu <48036328+sima-zhu@users.noreply.github.com>
* Use seperate scripts
* address comments.
* do compare and update
* save on the service level readme
* have the helper for reuse function
* remove mgmt table
* changes
* fix
* no return on error
* return if no contents
* Address comments
* change the table
* address wes comments.
* address wes comments.
* address more comments.
Co-authored-by: sima-zhu <sizhu@microsoft.com>
* Implement tracing for Attestation and Template services
* Pipeline no longer requires service name if opting into distributed tracing; enable tracing in attestation service
* Generate user-agent header from request activity policy
* Added test to catch the redacted header regression
* Updated documentation to reflect API surface changes
* OpenTelemetry vcpkg fixes
* Update ci.yml
* Drop version >= from project-level vcpkg
* find_package only supports numeric versions
* include(AzureBuildTargetForCI)
* Do not build as Windows/UWP DLL
* Docs and package dependencies
* Update condition
* Move condition down
* Move more under condition
* Rephrase condition
* Try hack for CI that won't affect vcpkg
Co-authored-by: Anton Kolesnyk <antkmsft@users.noreply.github.com>
