Add new property for CORS settings

[juniwang]

Changes:

Add new property for CORS settings which enables customers to configure Cross-Origin Resource Sharing.

Tests:

all validations documented on https://github.com/Azure/adx-documentation-pr/wiki/Swagger-Validation-Tools passed.

Latest improvements:

MSFT employees can try out our new experience at OpenAPI Hub - one location for using our validation tools and finding your workflow.

Contribution checklist:

• I have reviewed the documentation for the workflow.
• Validation tools were run on swagger spec(s) and have all been fixed in this PR.
• The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

• Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
• adding/removing APIs.
• adding/removing properties.
• adding/removing API-version.
• adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

• If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
  Please follow the link to find more details on API review process.

[openapi-sdkautomation]

SDK Automation [Logs] (Generated from b038fea)

Python: Azure/azure-sdk-for-python [Logs] [Diff]

• sdk/signalr/azure-mgmt-signalr [Logs] [Instructions]
  • azure-mgmt-signalr-0.2.0.zip
  • azure_mgmt_signalr-0.2.0-py2.py3-none-any.whl

Java: Azure/azure-sdk-for-java [Logs] [Diff]

• signalr/resource-manager/v2018_03_01_preview [Logs]
• signalr/resource-manager/v2018_10_01 [Logs] [Instructions]
  • pom.xml
  • azure-mgmt-signalrservice-1.0.0-beta-javadoc.jar
  • azure-mgmt-signalrservice-1.0.0-beta-sources.jar
  • azure-mgmt-signalrservice-1.0.0-beta.jar

JavaScript: Azure/azure-sdk-for-js [Logs] [Diff]

• @azure/arm-signalr [Logs] [Instructions]
  • azure-arm-signalr-1.2.0.tgz

Go: Azure/azure-sdk-for-go [Logs] [Diff]

• preview/signalr/mgmt/2018-03-01-preview [Logs] [Instructions]
  • preview.signalr.mgmt.2018-03-01-preview.zip
• signalr/mgmt/2018-10-01 [Logs] [Instructions]
  • signalr.mgmt.2018-10-01.zip

Ruby: Azure/azure-sdk-for-ruby [Logs] [Diff]

• azure_sdk [Logs] [Instructions]
  • azure_sdk-0.27.0.gem
• data/signalr [Logs]

[AutorestCI]

Automation for azure-sdk-for-python

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-python#5532

[AutorestCI]

Automation for azure-sdk-for-ruby

A PR has been created for you:
Azure/azure-sdk-for-ruby#2688

[AutorestCI]

Automation for azure-sdk-for-java

A PR has been created for you based on this PR content.

Once this PR will be merged, content will be added to your service PR:
Azure/azure-sdk-for-java#3177

[AutorestCI]

Automation for azure-sdk-for-go

A PR has been created for you based on this PR content.

Once this PR will be merged, content will be added to your service PR:
Azure/azure-sdk-for-go#5348

[azuresdkci]

Can one of the admins verify this patch?

[ghost]

@openapi sdkautomation rebuild

[sanjaiganesh]

pls add this new property under new api version, to avoid confusion when client uses mix of new and old sdks.
(one call to populate 'cors' property and one call with old sdk without 'cors' property)

[juniwang]

Do we have to add a new api-version? Our latest RP is compatible with older SDKs. It works fine with or without the cors property

[KrisBash]

Do we have to add a new api-version? Our latest RP is compatible with older SDKs. It works fine with or without the cors property

@juniwang The concern with adding a writable property in an existing API version is that there will be a mix of clients that are on older and newer versions. If the property is set by a latest version client, and the resource is then modified by a downlevel client, your service cannot know whether the property was intentionally removed or the result of a downlevel client.

[juniwang]

@juniwang The concern with adding a writable property in an existing API version is that there will be a mix of clients that are on older and newer versions. If the property is set by a latest version client, and the resource is then modified by a downlevel client, your service cannot know whether the property was intentionally removed or the result of a downlevel client.

Thanks @KrisBash. We got the point. It's a good pattern to add new API version to avoid confusion. But for this perticular case, the CORS settings by design CANNOT be removed. Clients are only allowed to modify it by passsing in an non-empty value. A value of null (either using older SDK or intentionally set in newer ones) results in remaining the current value unchanged. A default non-empty value will be set while creating(for both older clients and newer clients with null value). Does this make sense to keep using the same api-version?

[KrisBash]

@juniwang The concern with adding a writable property in an existing API version is that there will be a mix of clients that are on older and newer versions. If the property is set by a latest version client, and the resource is then modified by a downlevel client, your service cannot know whether the property was intentionally removed or the result of a downlevel client.

Thanks @KrisBash. We got the point. It's a good pattern to add new API version to avoid confusion. But for this perticular case, the CORS settings by design CANNOT be removed. Clients are only allowed to modify it by passsing in an non-empty value. A value of null (either using older SDK or intentionally set in newer ones) results in remaining the current value unchanged. A default non-empty value will be set while creating(for both older clients and newer clients with null value). Does this make sense to keep using the same api-version?

I think that's ok.

[KrisBash]

Approving for ARM