Enhanced support for associating NICs with Load Balancers

[martinsawicki]

Backend: simple usage to associate an existing NIC (primary IP config) with an existing LB backend:

nic.update()  
    .withExistingLoadBalancerBackend(lb, "backend1")  
    .apply();

same idea for NIC definition.

NAT rule:

nic.update()
    .withExistingLoadBalancerInboundNatRule(lb,  "natrule1")
    .apply();

[azuresdkci]

Can one of the admins verify this patch?

[azuresdkci]

Runtime changes detected. pull request created. CI running:

[azuresdkci]

Runtime changes detected. pull request created. CI running:

[azuresdkci]

Runtime changes detected. pull request created. CI running:

[anuchandy]

We should return this here right? otherwise null ptr exception while running the next stage wither?

same with withExistingLoadBalancerInboundNatRule as well.

[martinsawicki]

null is returned because the user cannot proceed here - the user is pointing at a Backend that does not exist, so the logic should fail fast here.

[martinsawicki]

...so to make their error checking robust, the user code should fist ensure that the backend exists:

if (!lb.backends().contains(backendName)) {
    // Missing backend
} else {
    // Call the code in question
}

[anuchandy]

ah ok. I do have similar situation in VMSS, there i just throw ArgumentException with a message so that user knows whats wrong, returning null seems fine.

[martinsawicki]

the reason I figured returning null would be ok in scenarios involving the passing of a child's name as an argument is because it seems equivalent to trying to access LoadBalancer.backends().get(backendName) and similar child access scenarios, where children are returned as a Map. The Map doesn't throw in the case of a bad name.

[azuresdkci]

Runtime changes detected. pull request created. CI running: