Fixed swagger issues for Cheetah assets

[DeveloperTommy]

• Added read-only properties to id, name, and type for model definitions
• Set x-ms-azure-resource to true for corresponding models
• Removed required parameters for PATCH request body to fix swagger issues

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.

PR information

• The title of the PR is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
• Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
• If applicable, the PR references the bug/issue that it fixes.
• Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

• I have read the contribution guidelines.
• My spec meets the review criteria:
  • The spec conforms to the Swagger 2.0 specification.
  • The spec follows the guidelines described in the Swagger checklist document.
  • Validation tools were run on swagger spec(s) and have all been fixed in this PR.

[AutorestCI]

Did a commit to Azure/azure-sdk-for-go:
Azure/azure-sdk-for-go@619d455

[azuresdkciprbot]

Hi There,

I am the AutoRest Linter Azure bot. I am here to help. My task is to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:

File: specification/automation/resource-manager/readme.md
Before the PR: Warning(s): 0 Error(s): 54
After the PR: Warning(s): 0 Error(s): 38

AutoRest Linter Guidelines | AutoRest Linter Issues | Send feedback

Thanks for your co-operation.

[AutorestCI]

Did a commit to Azure/azure-sdk-for-python:
Azure/azure-sdk-for-python@53ad053

[anuchandy]

The proper way to fix this is, to split the Resource definition into 3

    "Resource": {
      "description": "The core properties of ARM resources",
      "properties": {
        "id": {
          "readOnly": true,
          "type": "string",
          "description": "Fully qualified resource Id for the resource."
        },
        "name": {
          "readOnly": true,
          "type": "string",
          "description": "The name of the resource"
        },
        "type": {
          "readOnly": true,
          "type": "string",
          "description": "The type of the resource."
        }
      },
      "x-ms-azure-resource": true
    },
    "TrackedResource": {
      "description": "The resource model definition for a ARM tracked top level resource",
      "properties": {
        "tags": {
          "type": "object",
          "additionalProperties": {
            "type": "string"
          },
          "x-ms-mutability": [
            "read",
            "create",
            "update"
          ],
          "description": "Resource tags."
        },
        "location": {
          "type": "string",
          "x-ms-mutability": [
            "read",
            "create"
          ],
          "description": "The Azure Region where the resource lives"
        }
      },
      "allOf": [
        {
          "$ref": "#/definitions/Resource"
        }
      ]
    },
    "ProxyResource": {
      "description": "The resource model definition for a ARM proxy resource. It will have everything other than required location and tags",
      "allOf": [
        {
          "$ref": "#/definitions/Resource"
        }
      ]
    }

And all top level resource to derive from the TrackedResource and nested resource (like Certificates) to derive from ProxyResource, we shouldn't annotate arbitrary types with x-ms-azure-resource.

[anuchandy]

@johanste can you chime in and confirm whether it make sense to follow the above pattern?

[johanste]

Whenever possible, I would use the common type definitions - which already defines the appropriate resource types.

@anuchandy, minor clarification: proxy resource != nested resource. A nested resource may or may not be tracked.

[anuchandy]

thanks @johanste for the response and correcting the confusion around nested resource.

Since this is an existing API version, conforming to this inheritance hierarchy will cause breaking change (for the models which are based on older Resource base type).

@DeveloperTommy can you please create a work item at your end so that in the next api version we can ensure the models uses this standard hierarchy? Also make a note on the current RPCViolations and SDKViolations reported by CI, many of them will go away once you conform to this hierarchy.

[anuchandy]

From the reviewer side I will create an issue in the spec repo and ref this PR.

[DeveloperTommy]

@anuchandy Sure, I have just created the work item "Task 139186: Refactor Swagger model to follow standard hierarchy" and noted the violations from Travis.

For now, are the current changes that I have acceptable to be merged?

[DeveloperTommy]

@anuchandy @johanste Bumping for my previous comment.

[johanste]

@anuchandy, do you have anything else you want to get addressed?

[anuchandy]

no, looks good.. merging this.

[DeveloperTommy]

Thank you both for reviewing!