Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MM] Inconsistency in property types #57

Open
ArcturusZhang opened this issue Nov 7, 2019 · 1 comment
Open

[MM] Inconsistency in property types #57

ArcturusZhang opened this issue Nov 7, 2019 · 1 comment

Comments

@ArcturusZhang
Copy link
Member

I am generating api.yaml file using autorest.cli with input file: azure-rest-api-specs\specification\compute\resource-manager\readme.md

Tag in use

package-2019-07.

Cli section added in readme.md

cli:
  cli-name: compute
  azure-arm: true
  license-header: MICROSOFT_MIT_NO_VERSION
  payload-flattening-threshold: 2
  namespace: azure.mgmt.compute
  package-name: azure-mgmt-compute
  clear-output-folder: false
  debug: true
  disable-azure-cli: true

Problem encountered

Struct VirtualMachineProperties, its field AvailabilitySet and VirtualMachineScaleSet both are of type *SubResource, but they are generated as different types in computevirtualmachine/api.yaml:

      - !ruby/object:Api::Type::NestedObject
        name: 'availabilitySet'
        description: 'Specifies information about the availability set that the virtual machine should be assigned to. Virtual machines specified in the same availability set are allocated to different nodes to maximize availability. For more information about availability sets, see [Manage the availability of virtual machines](https://docs.microsoft.com/azure/virtual-machines/virtual-machines-windows-manage-availability?toc=%2fazure%2fvirtual-machines%2fwindows%2ftoc.json). <br><br> For more information on Azure planned maintenance, see [Planned maintenance for virtual machines in Azure](https://docs.microsoft.com/azure/virtual-machines/virtual-machines-windows-planned-maintenance?toc=%2fazure%2fvirtual-machines%2fwindows%2ftoc.json) <br><br> Currently, a VM can only be added to availability set at creation time. An existing VM cannot be added to an availability set. <br><br>This property cannot exist along with a non-null properties.virtualMachineScaleSet reference.'
        required: false
        azure_sdk_references: ['/availabilitySet', '/properties/availabilitySet']
        properties:
          - !ruby/object:Api::Azure::Type::ResourceReference
            name: 'id'
            description: 'Resource Id'
            required: false
            sample_value: /subscriptions/{{ subscription_id }}/resourceGroups/{{ resource_group }}/providers/Microsoft.Compute/availabilitySets/{{ name }}
            resource_type_name: TBD
            azure_sdk_references: ['/availabilitySet/id', '/properties/availabilitySet/id']
      - !ruby/object:Api::Type::NestedObject
        name: 'virtualMachineScaleSet'
        description: 'Specifies information about the virtual machine scale set that the virtual machine should be assigned to. Virtual machines specified in the same virtual machine scale set are allocated to different nodes to maximize availability. Currently, a VM can only be added to virtual machine scale set at creation time. An existing VM cannot be added to a virtual machine scale set. <br><br>This property cannot exist along with a non-null properties.availabilitySet reference. <br><br>Minimum api‐version: 2019‐03‐01'
        required: false
        azure_sdk_references: ['/virtualMachineScaleSet', '/properties/virtualMachineScaleSet']
        properties:
          - !ruby/object:Api::Type::String
            name: 'id'
            description: 'Resource Id'
            required: false
            azure_sdk_references: ['/virtualMachineScaleSet/id', '/properties/virtualMachineScaleSet/id']

One of them is String, the other is ResourceReference.
Since these kind of fields usually need to be flattened, String type is more preferred.

@ArcturusZhang
Copy link
Member Author

  • Note: this issue does not affect the normal functionality of autorest.cli

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant