[servicefabricmanagedclusters] sdk configuration changes for java and dotnet

[iliu816]

SDK configuration pull request

Purpose of this PR

• Make changes to the SDK configuration only when there are no modifications to the API specification, eliminating the need for an ARM or Stewardship Board API review.

Due diligence checklist

To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

• I confirm this PR is modifying only SDK configurations, and not API related specifications.
• I have reviewed and used the respective tspconfig.yaml templates:
  • ARM tspconfig template
  • Data plane tspconfig template

Getting help

• First, carefully read through this PR description, from top to bottom. Fill out the Purpose of this PR and Due diligence checklist.
• If you don't have permissions to remove or add labels to the PR, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories
• To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
• For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure and https://aka.ms/ci-fix.
• If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run.
  This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
• If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

[openapi-pipeline-app]

Next Steps to Merge

Next steps that must be taken to merge this PR:

• ❌ This PR is in purview of the ARM review (label: ARMReview). This PR must get ARMSignedOff label from an ARM reviewer.
  This PR has ARMChangesRequested label. Please address or respond to feedback from the ARM API reviewer.
  When you are ready to continue the ARM API review, please remove the ARMChangesRequested label.
  Automation should then add WaitForARMFeedback label.
  ❗If you don't have permissions to remove the label, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories.
  For details of the ARM review, see aka.ms/azsdk/pr-arm-review
  
• ❌ The required check named Automated merging requirements met has failed. This is the final check that must pass. Refer to the check in the PR's 'Checks' tab for details on how to fix it and consult the aka.ms/ci-fix guide. In addition, refer to step 4 in the PR workflow diagram

[openapi-pipeline-app]

PR validation pipeline restarted successfully. If there is ApiView generated, it will be updated in this comment.

[github-actions]

API Change Check

APIView identified API level changes in this PR and created the following API reviews

Language	API Review for Package
Swagger	Microsoft.ServiceFabric
TypeSpec	Microsoft.ServiceFabric
Go	sdk/resourcemanager/servicefabricmanagedclusters/armservicefabricmanagedclusters
Java	com.azure.resourcemanager:azure-resourcemanager-servicefabricmanagedclusters
C#	Azure.ResourceManager.ServiceFabricManagedClusters
JavaScript	@azure/arm-servicefabricmanagedclusters
Python	azure-mgmt-servicefabricmanagedclusters

[rkmanda]

please book a slot in the ARM API review office hours to explain why your scenario needs additionalProperties

[iliu816]

I had used record based on advice from

https://teams.microsoft.com/l/message/19:[email protected]/1747972523177?tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47&groupId=3e17dcb0-4257-4a30-b843-77f47f1d4121&parentMessageId=1747972523177&teamName=Azure%20SDK&channelName=SDK%20release%20support&createdTime=1747972523177

Would appreciate insight from @weidongxu-microsoft on whether it should be changed from record to unknown, which would remove the additionalProperties. Awaiting further discussion below about Compute team's use of unknown and whether that is the correct approach.

Further discussion about unknown vs record that makes me believe we should be using unknown:
Azure/typespec-azure#1725 (comment)

settings and protectedSettings are represented as JObjects in our code:
https://msazure.visualstudio.com/One/_git/winfab-RP?path=/src/CSMTemplate/Model/VMExtensionResourcePropertites.cs&version=GBdevelop&_a=contents&line=14&lineStyle=plain&lineEnd=15&lineStartColumn=1&lineEndColumn=1

[weidongxu-microsoft]

Yes, AFAIK, Azure/typespec-azure#1725 (comment) is the recommended migrate solution given by TypeSpec dev.

Strictly speaking, unknown means any JSON type, include JSON object, but could also be JSON string or numeric or boolean or array.
Record<unknown> means JSON object.

[MaryGao]

Is the translation from TypeSpec unknown to swagger {} correct?

From table, it seems it could be {} or {"type": "object"} in swagger side? I can understand that Autorest has never made a clear difference between {} and {type: object} but it doesn't mean the openapi has no difference for them.

[weidongxu-microsoft]

I assume the dev on typespec-autorest already figured that out.

Not expert but here is one stackoverflow

[iliu816]

Hi @rkmanda, we are no longer adding "additionalproperties" to the model. Were there any other points of concern about this PR blocking approval?

[mentat9]

The ARM concern here isn't specifically about "additionalProperties": {}, rather it is the fact that the API uses an unschematized object. This is a major ARM anti-pattern. The suggestion of booking office hours was to discuss better, more ARM and client-friendly options for modeling this API object. So the more general question of "why does this API require a property that has no schema?" remains.

[iliu816]

From my understanding, this is an existing model in our spec that is also present in previous versions. It is a pass through for Microsoft.Compute. The change introduced in this PR is to align with how Java SDK client generation handles the Typespec. The api surface on the service side hasn't changed, and it would be a breaking change to change the behavior.

[a-santamaria]

@mentat9 we can go to ARM office hours to discuss further. But this shouldn't block this pr because that property has been there since it was introduced and we are following the same pattern as VMSS https://learn.microsoft.com/en-us/azure/templates/microsoft.compute/virtualmachinescalesets?tabs=bicep&pivots=deployment-language-arm-template#virtualmachinescalesetextensionproperties-1. Each extension owner can define their own model for this property.

[weidongxu-microsoft]

A notice that I found the unmerged migration of compute (which contains VMSS) uses unknown.

PR #32748
tsp

azure-rest-api-specs/specification/compute/Compute.Management/models.tsp

Lines 2989 to 2999 in 710a6e4

	/**
	* Json formatted public settings for the extension.
	*/
	#suppress "@azure-tools/typespec-azure-core/no-unknown"
	settings?: unknown;
	/**
	* The extension can contain either protectedSettings or protectedSettingsFromKeyVault or no protected settings at all.
	*/
	#suppress "@azure-tools/typespec-azure-core/no-unknown"
	protectedSettings?: unknown;

unknown would affect Swagger too, make them

  "settings": {
  }

without type: object -- basically it means any

Loop @pshao25 for advise too.

[a-santamaria]

/azp run

[azure-pipelines]

You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list.