Skip to content

Ipsec Policy for Virtual Network Gateway Connection#3666

Merged
cormacpayne merged 24 commits into
Azure:release-3.8.0from
henry416:dev
Apr 3, 2017
Merged

Ipsec Policy for Virtual Network Gateway Connection#3666
cormacpayne merged 24 commits into
Azure:release-3.8.0from
henry416:dev

Conversation

@henry416
Copy link
Copy Markdown
Member

@henry416 henry416 commented Mar 22, 2017

Description

THIS CHANGE MUST GO IN EARLY APRIL RELEASE

IPsec Policy support for Virtual Network Gateway Connection

  • updated Network nuget package (2017-03-01 api version)
  • updated existing Virtual Network Gateway Connection model + cmdlets
  • added IPsec Policy model + cmdlet
  • added connection test for IPsec Policy

Reference PR: Azure/azure-sdk-for-net#2943

This checklist is used to make sure that common guidelines for a pull request are followed. You can find a more complete discussion of PowerShell cmdlet best practices here.

General Guidelines

  • Title of the pull request is clear and informative.
  • There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.
  • The pull request does not introduce breaking changes (unless a major version change occurs in the assembly and module).

Testing Guidelines

  • Pull request includes test coverage for the included changes.
  • PowerShell scripts used in tests should do any necessary setup as part of the test or suite setup, and should not use hard-coded values for locations or existing resources.

Cmdlet Signature Guidelines

  • New cmdlets that make changes or have side effects should implement ShouldProcess and have SupportShouldProcess=true specified in the cmdlet attribute. You can find more information on ShouldProcess here.
  • Cmdlet specifies OutputType attribute if any output is produced - if the cmdlet produces no output, it should implement a PassThru parameter.

Cmdlet Parameter Guidelines

  • Parameter types should not expose types from the management library - complex parameter types should be defined in the module.
  • Complex parameter types are discouraged - a parameter type should be simple types as often as possible. If complex types are used, they should be shallow and easily creatable from a constructor or another cmdlet.
  • Cmdlet parameter sets should be mutually exclusive - each parameter set must have at least one mandatory parameter not in other parameter sets.

@msftclas
Copy link
Copy Markdown

@henry416,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@azuresdkci
Copy link
Copy Markdown

Can one of the admins verify this patch?

@henry416
Copy link
Copy Markdown
Member Author

This PR is pending a merge from azure-sdk-for-net, will update nuget packages properly when this occurs.
Please let me know if there are any other missing items from the PR while we wait.

@henry416
Copy link
Copy Markdown
Member Author

@cormacpayne Are there any steps / files I am missing in this PR? (other than the help files)

@cormacpayne
Copy link
Copy Markdown
Member

@azuresdkci add to whitelist

@henry416
Copy link
Copy Markdown
Member Author

@cormacpayne can we rerun the check? It seems to be stuck.

@cormacpayne
Copy link
Copy Markdown
Member

@azuresdkci test this please

@henry416
Copy link
Copy Markdown
Member Author

@cormacpayne I think the checks are failing b/c we haven't built and published a nuget package for the azure-sdk network branch. In the meantime is there any other component of this PR that is missing?

Copy link
Copy Markdown
Member

@cormacpayne cormacpayne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 Hey Henry, I left a couple of comments (most are about the version bump) that need to be resolved

<Reference Include="Microsoft.Azure.Management.Network, Version=9.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\..\packages\Microsoft.Azure.Management.Network.9.1.0-preview\lib\net45\Microsoft.Azure.Management.Network.dll</HintPath>
<Reference Include="Microsoft.Azure.Management.Network, Version=9.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\..\packages\Microsoft.Azure.Management.Network.9.2.0-preview\lib\net45\Microsoft.Azure.Management.Network.dll</HintPath>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 this will need to be bumped up to 10.0.0-preview

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cormacpayne Shouldn't the version be 9.2.0? Anyways, the azure-sdk branch hasn't been merged yet so the nuget package to be published isn't available yet - think of the references as a placeholder for now.

Copy link
Copy Markdown
Member

@cormacpayne cormacpayne Mar 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 it will be 10.0.0-preview after the changes that @jobatzil made, but yes, this is a temporary placeholder until the SDK gets published 😄

<package id="Microsoft.Azure.Management.Authorization" version="1.0.0" targetFramework="net45" />
<package id="Microsoft.Azure.Management.Compute" version="14.0.0-prerelease" targetFramework="net45" />
<package id="Microsoft.Azure.Management.Network" version="9.1.0-preview" targetFramework="net45" />
<package id="Microsoft.Azure.Management.Network" version="9.2.0-preview" targetFramework="net45" />
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 same comment

<Reference Include="Microsoft.Azure.Management.Network, Version=9.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\..\packages\Microsoft.Azure.Management.Network.9.1.0-preview\lib\net45\Microsoft.Azure.Management.Network.dll</HintPath>
<Reference Include="Microsoft.Azure.Management.Network, Version=9.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\..\packages\Microsoft.Azure.Management.Network.9.2.0-preview\lib\net45\Microsoft.Azure.Management.Network.dll</HintPath>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 same comment

<None Include="..\..\Common\Commands.ScenarioTests.ResourceManager.Common\AzureRM.Resources.ps1">
<Link>ScenarioTests\AzureRM.Resources.ps1</Link>
</None>
<None Include="app.config" />
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 please remove this

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do.

}

[Fact]
[Fact(Skip = "Rerecord tests")]
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 are these tests going to be re-recorded before this PR gets merged?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that the standard procedure? I can change both tests back to [Fact]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 is there any reason you are skipping these tests?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed them back to [Fact]

{
public class PSIpsecPolicy
{
public int SALifeTimeSeconds { get; set; }
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 can you add a quick summary for each the properties?

/// <summary>
/// Brief description of property.
/// <summary>
public int SALifeTimeSeconds { get; set; }

ipsecPolicy.DhGroup = this.DhGroup;
ipsecPolicy.PfsGroup = this.PfsGroup;

WriteObject(ipsecPolicy);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 as an FYI, StaticAnalysis is going to throw an exception because this cmdlet uses the New verb, but doesn't implement ShouldProcess . Since this cmdlet is creating a local object, you do not need to implement this attribute, so you can suppress the exception. I will show you how to do so when the time comes 😄

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cormacpayne Ah ok, that was an error that was confusing me. What would be the procedure to suppress that?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 we have a suppression .csv file for each of the StaticAnalysis analyzers that we have, so the one you will be concerned about is tools/StaticAnalysis/Exceptions/SignatureIssues.csv, which is where you will paste the exception you want to suppress.

If you run the build locally, you will find a SignatureIssues.csv file in src/Package/Debug that contains all of the errors picked up during the build, and you will just need to copy the severity 1 issues from this file into the suppressed exceptions file mentioned previously.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cormacpayne I have suppressed the exceptions for the files I have altered.

Mandatory = false,
ValueFromPipelineByPropertyName = true,
HelpMessage = "Whether to enable policy-based traffic selectors for a S2S connection")]
public string UsePolicyBasedTrafficSelectors { get; set; }
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 why use a string here if you're going to just parse it into a bool? The recommended pattern is to add a parameter called EnablePolicyBasedTrafficSelectors, and when this switch is enabled, users can provide a value for the IpsecPolicies parameter. These two parameters would need to be in a separate parameter set from the default one, and EnablePolicyBasedTrafficSelectors would need to be a mandatory parameter. Let me know if you have any questions about this.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cormacpayne This field is meant to act similar to the enableBgp field - it should be completely optional so that it doesn't break any existing PS scripts. PolicyBasedTrafficSelectors is also independent of the IpsecPolicies field.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 oops, sorry, I thought the two new parameters should be grouped together. In that case, you should just make this string parameter into a SwitchParameter called EnablePolicyBasedTrafficSelectors.

Following this pattern will make for a much better user experience - if the user wants to enable policy-based traffic selectors, then they will add -EnablePolicyBasedTrafficSelectors to the end of the command, and if they don't want to use it, then they don't have to do anything extra. Having the user provide a string that is being parsed into a bool is a less user-friendly way of having using a SwitchParameter.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cormacpayne I have changed it to SwitchParameter

```

## DESCRIPTION
{{Fill in the Description}}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 there are a few templates left behind from platyPS when generating the markdown for the first time. Would you mind replacing these templates (description, examples, etc.) with useful information for the user?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cormacpayne during platyPS regen, there were also a lot of other .md files changed that are not related to my work + Commands.Network/Microsoft.Azure.Commands.Network.dll-Help.xml - should I add those files as well?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 you do not need to add those files - I am working on a change that will get rid of the XML help from the repository and refresh all of the markdown files (updating them with the latest changes in the code), so all of that should be taken care of when my PR gets merged

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cormacpayne Synopsis is added.

<package id="Microsoft.Azure.Management.Authorization" version="1.0.0" targetFramework="net45" />
<package id="Microsoft.Azure.Management.Compute" version="14.0.0-prerelease" targetFramework="net45" />
<package id="Microsoft.Azure.Management.Network" version="9.1.0-preview" targetFramework="net45" />
<package id="Microsoft.Azure.Management.Network" version="9.2.0-preview" targetFramework="net45" />
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 same comment

@henry416
Copy link
Copy Markdown
Member Author

@cormacpayne Will I be able to push in changes after today? I haven't seen the sdk-for-net package being built yet - should I just put in the 10.0.0 version in the nuget references despite the package not existing?

@henry416
Copy link
Copy Markdown
Member Author

@cormacpayne I have added auto-generated .md files - picked up several changes from other services that weren't in the checked-in files

Creates a new peering configuration to be added to an ExpressRoute circuit.

### [New-AzureRmIpsecPolicy](New-AzureRmIpsecPolicy.md)
{{Fill in the Synopsis}}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henry416 can you fill in this synopsis?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cormacpayne Done.

@cormacpayne
Copy link
Copy Markdown
Member

@henry416 we will make sure the SDK gets published by early next week, and then once it is published (and any other feedback for this PR is resolved), then we can merge this

@henry416
Copy link
Copy Markdown
Member Author

@cormacpayne Okay, just to make sure, will this PR make the early april release in that case?

@henry416
Copy link
Copy Markdown
Member Author

@azuresdkci test this please

@henry416
Copy link
Copy Markdown
Member Author

@cormacpayne I updated the nuget package. Pending sign off if nothing else is blocking.

@henry416
Copy link
Copy Markdown
Member Author

@cormacpayne Fixed nuget package for compute

@henry416
Copy link
Copy Markdown
Member Author

@cormacpayne I have fixed two tests, however, I think the application gateway test is failing - could you contact someone on app gw to fix this?

@jobatzil
Copy link
Copy Markdown
Contributor

jobatzil commented Mar 30, 2017

@henry416 Hey Henry :)
yes, we have breaking changes in the new azure-sdk version (which is the reason for the major version incrementation). I update the Application Gateway related part of PS in this PR: #3678

@henry416
Copy link
Copy Markdown
Member Author

@cormacpayne Looks clear then - can merge proceed?

@cormacpayne cormacpayne changed the base branch from dev to release-3.8.0 March 31, 2017 20:49
@henry416
Copy link
Copy Markdown
Member Author

@cormacpayne Fixed merge issues and added changelog

@henry416
Copy link
Copy Markdown
Member Author

henry416 commented Apr 3, 2017

@cormacpayne Can this be merged?

@cormacpayne cormacpayne merged commit 71824da into Azure:release-3.8.0 Apr 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants