Adding new parameters for CustomIpPrefix

[gitlwh]

Description

Checklist

• I have read the Submitting Changes section of CONTRIBUTING.md
• The title of the PR is clear and informative
• The appropriate ChangeLog.md file(s) has been updated:
  • For any service, the ChangeLog.md file can be found at src/{{SERVICE}}/{{SERVICE}}/ChangeLog.md
  • A snippet outlining the change(s) made in the PR should be written under the ## Upcoming Release header -- no new version header should be added
• The PR does not introduce breaking changes
• If applicable, the changes made in the PR have proper test coverage
• For public API changes to cmdlets:
  • a cmdlet design review was approved for the changes in this repository (Microsoft internal only)
    • {Please put the link here}
  • the markdown help files have been regenerated using the commands listed here

[BethanyZhou]

Please add change log for your change.

[BethanyZhou]

• I recommend using bool as the type of Provision so that we needn't two parameters for one function.
• Please update the help message.

[gitlwh]

type would change behavior of our command because we need to use like
'''-Provision $true''' right?

[BethanyZhou]

Hi @gitlwh , How about Provision and Deprovision?

[gitlwh]

Hi @gitlwh , How about Provision and Deprovision?

What do you mean by that? I think they should have same behavior as commission and decommission. Only one of the four should exist.

[gitlwh]

type would change behavior of our command because we need to use like
'''-Provision $true''' right?

[BethanyZhou]

Only one of the four should exist.

How to check this logic? It's in backend side?

Type would change behavior of our command because we need to use like
'''-Provision $true''' right?

Yes, I prefer this behavior because we can avoid customer using Provision and Deprovision at same time

[gitlwh]

Only one of the four should exist.

How to check this logic? It's in backend side?

Type would change behavior of our command because we need to use like
'''-Provision $true''' right?

Yes, I prefer this behavior because we can avoid customer using Provision and Deprovision at same time

If you read my code, my implementation is
if ((Commission ? 1 : 0) + (Decommission ? 1 : 0) + (Provision ? 1 : 0) + (Deprovision ? 1 : 0) > 1)
{
throw new ArgumentException(Microsoft.Azure.Commands.Network.Properties.Resources.CommissioningStateConflict);
}

And if we change the behavior of command it would be a break change right?

[BethanyZhou]

And if we change the behavior of command it would be a break change right?

• Thank you for you quick response. Yes, It would be a breaking change if we change the behavior of Commission. Since Commission had been release, I want to discuss about the design of Provision with you.
• I understand that you want to keep the behavior of Provision same with Commission. Your design looks acceptable but I'm wondering how to design is more friendly to customer. Will you feel better if you are customer and can set Provision $true, $null and $false by one parameter?

[BethanyZhou]

Please sync your code with latest network-march branch so that your change log msg can include in upcoming release section.

[gitlwh]

And if we change the behavior of command it would be a break change right?

• Thank you for you quick response. Yes, It would be a breaking change if we change the behavior of Commission. Since Commission had been release, I want to discuss about the design of Provision with you.
• I understand that you want to keep the behavior of Provision same with Commission. Your design looks acceptable but I'm wondering how to design is more friendly to customer. Will you feel better if you are customer and can set Provision $true, $null and $false by one parameter?

No, The original way is more simple for cx to use and we don't have a plan to change this bahavior.

[gitlwh]

Added one more parameter for update operation CIDR