[swagger][Container Instance] Username is required even if user assigned identity is passed

• Package Name: @azure/arm-containerinstance
• Package Version: 7.1.0
• Operating system: Linux x86-64
• nodejs
  • version: 17
• browser
  • name/version:
• typescript
  • version: 4.6.2
• Is the bug related to documentation in
  • README.md
  • source code documentation
  • SDK API docs on https://docs.microsoft.com

Describe the bug Spawning a container group using client.containerGroups.createOrUpdate requires passing username in imageRegistryCredentials (type ImageRegistryCredential), but this field should not be required if identity is present.

To Reproduce Try to call client.containerGroups.createOrUpdate with only an identity:

const principalPath = '/subscriptions/...';

await someContainerClient.containerGroups.createOrUpdate('some-group', 'some-name', {
    containers: containers,
    name: name,
    osType: 'Linux',
    sku: 'Standard',
    location: this.azureContainerInstanceConfig.instanceRegion,
    identity: {
        type: 'UserAssigned',
        userAssignedIdentities: {
            [principalPath]: {},
        },
    },
    imageRegistryCredentials: [
        {
            server: 'some-server',
            identity: principalPath,
        },
    ],
    restartPolicy: 'OnFailure'
})

The types will complain that username must be present.

Expected behavior The types do not complain about username if identity is present, since the two are mutually exclusive.

Additional context If you pass undefined as unknown as string to circumvent the error, the serializer will complain that username must not be null or undefined. If you set it to an actual value, Azure will complain that you cannot combine username with identity. The only workaround so far is to pass the empty string '' as username value - Azure seems to ignore it, and the SDK does not complain.

[qiaozha]

close it as it should have been resolved. @NoTuxNoBux feel free to reopen it if you still found any issues about it. Thanks

[MaryGao]

@NoTuxNoBux Thanks for reporting this issue! We reproduced in local environment and we think this is a valid issue and are contacting the service team to fix it. Will let you know once we have a release to fix it!