[network] Add: az network nic create: created new --ip-config-name …

[mason1999]

Related command

az network nic create

Description

• This PR exists because it is useful to be able to configure the network interface card ip configuration name at creation time. Currently it is fixed at "ipconfig1"
• The effect is the ability to be able to be able to customise the ip configuration name upon creation of the network interface card. Changes to the codebase itself are minimal (as customisation is placed in azure-cli/azure/cli/command_modules/network/custom.py) and the change itself is just send a simple string along the request.
• The impact is that for services which rely on ip configuration name (for example: azure load balancer when adding a backend nic to the pool) you can have assurance to be able to add the nic by a name determined by you (e.g az network nic ip-config address-pool add --resource-group {rg} --nic-name {nic} --lb-name {lb} --ip-config-name {ip_config_name} --address-pool {backend_pool_name} instead of hardcoding "ipconfig1" into the --ip-config-name parameter).

Testing Guide
To test the command run:

az network nic create --resource-group {rg} --name {nic} --subnet {subnet_id} --ip-config-name {ip_config_name}

I tested this in practice by updating the file: azure-cli/azure/cli/command_modules/network/custom.py and running the command with the new parameter and it worked.

But I wasn't sure how to integrate it fully into the testing framework provided. After trying my best to read through the code base I think the way to test this is to:

1. Add properties to the azure-cli/azure/cli/command_modules/network/aaz/latest/network/nic/_create.py (i.e something like properties.set_prop("ipConfigName", AAZStrType, ".ip_config_name")
2. Add a line to the azure-cli/azure/cli/command_modules/network/test/latest/test_network_commands.py (i.e something like self.check('NewNIC.ipConfigName", {ip_config_name}) (where {ip_config_name} is obtained by the following code also in the same file):

        self.kwargs.update({
            'nic': 'cli-test-nic',
            'rt': 'Microsoft.Network/networkInterfaces',
            'subnet': 'mysubnet',
            'vnet': 'myvnet',
            'nsg1': 'mynsg',
            'nsg2': 'myothernsg',
            'lb': 'mylb',
            'pri_ip': '10.0.0.15',
            'pub_ip': 'publicip1',
            'ip_config_name': 'myipconfig1'
        })

But I'm not sure how to run the tests themselves. Any help on this would be appreciated!

PR Checklist

• The PR title and description has followed the guideline in Submitting Pull Requests.

• I adhere to the Command Guidelines.

• I adhere to the Error Handling Guidelines.

[azure-client-tools-bot-prd]

Validation for Azure CLI Full Test Starting...

Thanks for your contribution!

[azure-client-tools-bot-prd]

Validation for Breaking Change Starting...

Thanks for your contribution!

[Yong Zhang (yonzhan)]

Thank you for your contribution! We will review the pull request and get back to you soon.

[github-actions]

The git hooks are available for azure-cli and azure-cli-extensions repos. They could help you run required checks before creating the PR.

Please sync the latest code with latest dev branch (for azure-cli) or main branch (for azure-cli-extensions).
After that please run the following commands to enable git hooks:

pip install azdev --upgrade
azdev setup -c <your azure-cli repo path> -r <your azure-cli-extensions repo path>

[Ethan Yang (necusjz)]

unfortunately, it's by design.

[mason1999]

wait could you elaborate instead of closing it straight away? does that mean it will always be fixed at "ipconfig1". Because my concern is that if I use "ipconfig1" in things like adding a nic to a load balancer by name, I don't know if it's guaranteed it will always be "ipconfig1". I wanted to understand more the thinking why it's fixed at "ipconfig1" by design.

[Ethan Yang (necusjz)]

it will always be "ipconfig1", the original intention might have been to reduce some input and to create certain dependencies by default.

[mason1999]

but doesn't setting a default value of "ipconfig1" preserve the intention while allow for an optional flexibility to change the name if you'd like to? From what I can see, it also follows the pattern of the code snippets around it?

I'm not trying to be argumentative here, it's just that I struggle to see how it is better by design with the points you've raised (in terms of intentions, dependencies and hardcoding it to "ipconfig1"). So if you could help me understand why better that would greatly benefit my own understanding.

[mason1999]

I would like to get another contributor / maintainers thoughts on it Yong Zhang (@yonzhan). Could you please give me your thoughts on the discussion and help me see how my code doesn't conform to the overall intention and design. This will be more helpful and beneficial for my own understanding because I want to try and help contribute more to this tool as I use it every day for work.

[Yu Yi Yu (ayualn)]

Just a quick thought here:

• The Az Pwsh cmdlet enables naming for the child resource of ipconfiguration child resource name by passing through the parameter -IpConfigurationName
• To enable feature parity, wouldn't we want to standardise the behaviour and user experience across both the CLI and Az Pwsh ?

Source:

• https://learn.microsoft.com/en-us/powershell/module/az.network/new-aznetworkinterface?view=azps-14.4.0#example-1-create-an-azure-network-interface