Azure-cli: [Network] Public IP addresses should be easier to retrieve for LB and NIC resources

[lostintangent]

Is there any way to use the az network lb command group to retrieve the public IP address associated with a load balancer instance? Neither az network lb show nor az network lb frontend-ip list seem to actually provide this data. The only way I can figure out how to find this is via az network public-ip commands, which makes sense, but seems kind of non-ideal, since I may have auto-created the public IP as part of creating the load balancer, and therefore, am logically managing the LB, not a separate public IP resource.

Oddly enough, if you look at the JSON output of either the network lb show or network lb frontend-ip list commands, there seems to be a property for the public IP address, but it doesn't seem to ever be populated in my experience (is that a bug?). So in my tests, neither of the following queries ever return anything:

az network lb show -g foo -n foo --query "frontendIpConfigurations[].publicIpAddress.ipAddress"

az network lb frontend-ip list -g foo --lb-name foo --query "[].publicIpAddress.ipAddress"

And therefore, I have to retrieve the name of the public IP associated with the LB, and then run the following instead:

az network public-ip show -g foo -n PublicIPfoo --query "ipAddress"

Am I doing something wrong in the first example? Or is it expected that you'd need to use az network public-ip commands to get the IP address?

[johanste]

You should be able to use the --expand <attributes to expand> parameter to list additional properties to retrieve. We should consider having a default value for --expand for the networking commands to get the most interesting properties. Please note that --expand is only available for network show commands, not network list ones (limitation of the Azure REST APIs)

[lostintangent]

@johanste Cool! What would be the syntax for expanding the public IP address? I just tried a few different uses of --expand and I'm clearly missing something :) For example, running az network lb show -g foo -n foo --expand "frontendIpConfigurations" -ojsonc results in the following error:
$expand query option value is invalid. The resource does not have property frontendIpConfigurations or the property does not represent a reference to another resource.

I tried playing with the case of the property name, and I can't figure out how to get it to work.

[lostintangent]

Ah nevermind, I figured out I had to do --expand "frontendIpConfigurations/publicIpAddress" after refreshing myself on the syntax for OData $expand expressions. That said, using this, the command to retrieve the IP of an LB is pretty verbose:

az network lb show -g foo -n foo \
   --query "frontendIpConfigurations[].publicIpAddress.ipAddress" \
   --expand "frontendIpConfigurations/publicIpAddress" \
   -otsv

This functions as expected, but I'd definitely agree with the value in providing some kind of shortcut here.

[lostintangent]

Would it be worth considering an az network lb list-ip-addresses command that functioned similar to the az vm list-ip-addresses command? The scenario of retrieving an LB's public IP seems common enough to potentially justify it.

[johanste]

@lostintangent, that sounds like a reasonable idea. Thanks for the suggestion!

[lostintangent]

@johanste Would you prefer that we repurpose this issue as the feature request or close this one and create another?

[lostintangent]

I just updated the title to reflect the actual discussion here, and also ensure that it includes NIC resources in addition to LBs, since the same feedback is relevant for both.

[robsonpeixoto]

But how to get the private ip?

[yugangw-msft]

@tjprescott, any thoughts? The key is on what people would do next once have the PIP? And how common is that? For VMSS with LB, people want to get tge PIP so to connect to the instance and for that case we expose az vmss list-instance-connection-info to get all done.

[tjprescott]

@yugangw-msft my recommendation would be to close this as:

1. there has been no supporting activity (+1s by external customers, for example)
2. it is asking for a convenience command, not API coverage or a bug fix

[tjprescott]

Closing this issue due to insufficient customer demand. That being said, we would welcome any external contribution that would simplify this scenario.

[tjprescott]

Reopening this with the help wanted tag in case the community would like to take this up. If it doesn't progress after a time, we will close.

[tjprescott]

No one has expressed interest in this in 6 months. Closing.