Skip to content

Bump up network sdk version from 17.0.0.preview to 18.0.0.preview #5993

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 40 commits into from
Apr 30, 2018

Conversation

Nilambari
Copy link
Member

@Nilambari Nilambari commented Apr 19, 2018

Description

Checklist

@cormacpayne
Copy link
Member

@Nilambari tests are failing due to the change in the API version -- please let us know if you have any issues using the Network recording job on our Jenkins server to mitigate this issue

@Nilambari
Copy link
Member Author

@cormacpayne I have included all the tests recorded with new API version. Please take a look now and help merge the PR. Thanks!

@Nilambari
Copy link
Member Author

@cormacpayne Looks like build is failed due to some tests, which are not recorded/included in this PR / owned by us. Can you tell us the next action. Thanks!

@Nilambari
Copy link
Member Author

@maddieclayton Thanks. Updated the latest Network version in all test csproj files: RecoveryServices.Backup, Compute, DNS, and SQL. Can you help accept this PR?

Thanks,
Nilambari

@Nilambari
Copy link
Member Author

Can you Please help accept this PR? Thanks.

@Nilambari
Copy link
Member Author

@maddieclayton Re-recorded failing tests and unskipped them. Only one test: TestConnectivityCheck is skipped in this PR:- This test is failing due to new parameters added to the api and test needs to be updated accordingly. Related swagger changes are done but service team([email protected]) is still working on related PS changes. They said they will own fixing and rerecording this failing test.

Can you Please help accept the PR? Thanks!

@@ -2,5 +2,8 @@
<packages>
<package id="AutoMapper" version="6.0.2" targetFramework="net452" />
<package id="Microsoft.Azure.KeyVault.Core" version="1.0.0" targetFramework="net45" />
<package id="Microsoft.Azure.Management.Network" version="17.0.0-preview" targetFramework="net452" />
<package id="Microsoft.Azure.Management.Network" version="18.0.0-preview" targetFramework="net452" />
Copy link
Member

Choose a reason for hiding this comment

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

All of the changes to this file other than the network client management update must be removed.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

@@ -75,7 +75,7 @@ public void TestFlowLog()
NetworkResourcesController.NewInstance.RunPsTest("Test-FlowLog");
}

[Fact]
[Fact(Skip = "Test is failing due to design changes. Service team is going to re-record and submit it.")]
Copy link
Member

Choose a reason for hiding this comment

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

Is this failing due to design changes that impact cmdlets, or design changes that impact test setup?

Copy link
Member Author

Choose a reason for hiding this comment

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

Service team said they need to fix the test and re-record it.

@@ -21,8 +21,9 @@ function Test-ExpressRouteBGPServiceCommunities
$communities = Get-AzureRmBgpServiceCommunity

Assert-NotNull $communities
Assert-NotNull $communities[0].BgpCommunities
Assert-AreEqual true $communities[0].BgpCommunities[0].IsAuthorizedToUse
$crmOnlineCommunity = $communities | Where-Object {$_.ServiceName -match "CRMOnline"}
Copy link
Member

Choose a reason for hiding this comment

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

This seems to be testing a different property in the output. Is the old property no longer available? Why is it OK not to test for the old property?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, they are testing same property. Just previously, it was returning only one entry, now it returns many entries and we need to specify which entry param we need to validate in the test.

@@ -51,7 +51,7 @@ function Test-VirtualNetworkExpressRouteGatewayCRUD
$expected = Get-AzureRmVirtualNetworkGateway -ResourceGroupName $rgname -name $rname
Assert-AreEqual $expected.ResourceGroupName $actual.ResourceGroupName
Assert-AreEqual $expected.Name $actual.Name
#Assert-AreEqual "ExpressRoute" $expected.GatewayType
Assert-AreEqual "ExpressRoute" $expected.GatewayType
Copy link
Member

Choose a reason for hiding this comment

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

Thanks for putting the asserts back

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure.

</Reference>
<Reference Include="Microsoft.Rest.ClientRuntime, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
Copy link
Member

Choose a reason for hiding this comment

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

Do not add these bacj - these come from the common targets you have imported. The only dependency change in this file should be the network management client version

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

MNM.ExpressRouteCircuitPeeringType.AzurePrivatePeering,
MNM.ExpressRouteCircuitPeeringType.AzurePublicPeering,
MNM.ExpressRouteCircuitPeeringType.MicrosoftPeering,
MNM.ExpressRoutePeeringType.AzurePrivatePeering,
Copy link
Member

Choose a reason for hiding this comment

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

Are we sure these values are the same?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, they are same.

@@ -2604,5 +2608,39 @@
</CustomEntries>
</CustomControl>
</View>
<View>
Copy link
Member

Choose a reason for hiding this comment

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

Note: in the review, we asked that you add a table control, as table view should be the default. We can let this go for this release, but we will need to change this soon for all of these cmdlets.

Copy link
Member Author

@Nilambari Nilambari Apr 28, 2018

Choose a reason for hiding this comment

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

I will check with you offline and make this change in my next PS PR.

@@ -31,10 +31,12 @@ public class PSVirtualNetwork : PSTopLevelResource, IResourceReference

public string ProvisioningState { get; set; }

public bool? EnableDDoSProtection { get; set; }
public bool? EnableDdosProtection { get; set; }
Copy link
Member

Choose a reason for hiding this comment

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

This is marked as a breaking change, but you have used this spelling throughout. Is this a product level decision to change the way DDOS is spelled? If so, this is good, and you can simply suppress the breakign change warning, as, in PowerShell script, either 'DDos' or 'Ddos' in a script will find either value.

Copy link

@avijitgupta avijitgupta Apr 28, 2018

Choose a reason for hiding this comment

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

Hi Mark, We have used the same casingin our resource on the networking provider and during reviews. We will suppress the warning.


public bool? EnableVmProtection { get; set; }

public PSResourceId DdosProtectionPlan { get; set; }
Copy link
Member

Choose a reason for hiding this comment

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

DDos

Choose a reason for hiding this comment

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

We have used Ddos everywhere.


[Parameter(
Mandatory = false,
HelpMessage = "A switch parameter which represents whether DDoS protection is enabled or not. It can only be turned on if a DDoS Protection Plan is associated with the virtual network.")]
Copy link
Member

Choose a reason for hiding this comment

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

Is this a breaking change? If so, you need to ensure that you document this in the 'upcoming braking changes' document in network so that customers know the change is breaking.

-Also, since the protection plan is required, You should create a new parameter set that makes both of these parameters mandatory

Choose a reason for hiding this comment

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

This functionality was only in private preview. We have never GAd this ability. However, we will add it in upcoming braking change. We will also create a new parameter set.

Choose a reason for hiding this comment

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

We will add the parameter set in the next release. We added the breaking change documentation

@markcowl markcowl changed the base branch from preview to release-6.0.0 April 28, 2018 19:09
@markcowl markcowl merged commit 5919291 into Azure:release-6.0.0 Apr 30, 2018
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.

9 participants