Add Virtual Router top level resource. Add Identity under Microsoft.Network/ExpressRoutePort and MacSecConfig under Microsoft.Network/ExpressRouteLink

[naveenchekuri]

If you are a MSFT employee you can view your work branch via this link.

Contribution checklist:

• I have reviewed the documentation for the workflow.
• Validation tools were run on swagger spec(s) and have all been fixed in this PR.

[openapi-sdkautomation]

In Testing, Please Ignore

[Logs] (Generated from a93e01b, Iteration 5)

.NET: test-repo-billy/azure-sdk-for-net [Logs] [Diff]

• Microsoft.Azure.Management.Network [Logs] [Instructions] [Generation PR]
  • Microsoft.Azure.Management.Network.19.14.0-preview.nupkg
  • Microsoft.Azure.Management.Network.19.14.0-preview.snupkg

Python: test-repo-billy/azure-sdk-for-python [Logs] [Diff]

• azure-mgmt-network [Logs] [Instructions] [Generation PR]
  • azure-mgmt-network-4.0.0.zip
  • azure_mgmt_network-4.0.0-py2.py3-none-any.whl

Java: test-repo-billy/azure-sdk-for-java [Logs] [Diff]

• network/resource-manager/v2017_10_01 [Logs]
• network/resource-manager/v2018_04_01 [Logs]
• network/resource-manager/v2018_06_01 [Logs]
• network/resource-manager/v2018_07_01 [Logs]
• network/resource-manager/v2018_08_01 [Logs]
• network/resource-manager/v2018_12_01 [Logs]
• network/resource-manager/v2019_02_01 [Logs]
• network/resource-manager/v2019_04_01 [Logs]
• network/resource-manager/v2019_06_01 [Logs]

Go: test-repo-billy/azure-sdk-for-go [Logs] [Diff]

• No packages generated.

JavaScript: test-repo-billy/azure-sdk-for-js [Logs] [Diff]

• No packages generated.

Ruby: test-repo-billy/azure-sdk-for-ruby [Logs] [Diff]

• No packages generated.

[azuresdkci]

Can one of the admins verify this patch?

[AutorestCI]

Automation for azure-sdk-for-python

Encountered a Subprocess error: (azure-sdk-for-python)

Command: ['/usr/local/bin/autorest', '/tmp/tmphdwvrzyb/rest/specification/network/resource-manager/readme.md', '--keep-version-file', '--multiapi', '--no-async', '--python', '--python-mode=update', '--python-sdks-folder=/tmp/tmphdwvrzyb/sdk/sdk', '--use=@microsoft.azure/autorest.python@4.0.70', '--version=preview']
Finished with return code -6
and output:

AutoRest code generation utility [version: 2.0.4283; node: v10.15.3]
(C) 2018 Microsoft Corporation.
https://aka.ms/autorest
   Loading AutoRest core      '/root/.autorest/@microsoft.azure_autorest-core@2.0.4392/node_modules/@microsoft.azure/autorest-core/dist' (2.0.4392)
   Loading AutoRest extension '@microsoft.azure/autorest.python' (4.0.70->4.0.70)
   Loading AutoRest extension '@microsoft.azure/autorest.modeler' (2.3.44->2.3.44)
Processing batch task - {"tag":"package-2019-06"} .

<--- Last few GCs --->

[18400:0x3870cc0]    99363 ms: Mark-sweep 1380.2 (1426.1) -> 1380.1 (1426.6) MB, 2361.0 / 0.0 ms  (average mu = 0.168, current mu = 0.092) allocation failure GC in old space requested
[18400:0x3870cc0]   101766 ms: Mark-sweep 1381.0 (1426.6) -> 1380.9 (1427.1) MB, 2399.1 / 0.0 ms  (average mu = 0.087, current mu = 0.001) allocation failure GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x1f9bdc05be1d]
Security context: 0x2641d7a9e6e9 <JSObject>
    1: newScalar [0x1e3d69f38801] [/node_modules/yaml-ast-parser/dist/src/yamlAST.js:~38] [pc=0x1f9bdc794096](this=0x084b1be55759 <Object map = 0x8ed2c022cd9>,v=0x0ab21a7026f1 <undefined>)
    2: arguments adaptor frame: 0->1
    3: readDoubleQuotedScalar(aka readDoubleQuotedScalar) [0x2d8bb6948cd9] [/node_modules/yaml-ast-parser/dist/src/loader.js:~530] [pc...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x8dc510 node::Abort() [node]
 2: 0x8dc55c  [node]
 3: 0xad9b5e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xad9d94 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xec7bf2  [node]
 6: 0xec7cf8 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [node]
 7: 0xed3dd2 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
 8: 0xed4704 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 9: 0xed7371 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [node]
10: 0xea07f4 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [node]
11: 0x11402db v8::internal::Runtime_AllocateInTargetSpace(int, v8::internal::Object**, v8::internal::Isolate*) [node]
12: 0x1f9bdc05be1d

[AutorestCI]

Automation for azure-sdk-for-go

A PR has been created for you:
Azure/azure-sdk-for-go#5599

[anton-evseev]

Updated commit to the next API version (2019-07-01) and re-targeted to network-august-release

[anthony-c-martin]

LGTM!

[naveenchekuri]

@lirenhe and @number213 ARM team has signed off on the PR. Could you sign off as well

[anton-evseev]

@anthony-c-martin I'm still concerned about PATCH operations' operationId. I think if should be _UpdateTags since it only updates tags and that's how such operations are named in other Network specs. But previous ARM reviewer insisted on using _Update.

[anton-evseev]

@lirenhe could you please take a look at CI failures? Maybe network-august-release is missing some updates from master? Could you please merge master into our release branch?

[anthony-c-martin]

@number213 @naveenchekuri _UpdateTags sounds fine to me if it's consistent with your other API declarations, and you don't support patching any other resource properties.

[anton-evseev]

Sounds good! @naveenchekuri could you please update two operationIds to use _UpdateTags?

[naveenchekuri]

@number213 Done. Made changes to set as UpdateTags

[lirenhe]

@naveenchekuri I saw there are a couple of check errors which is a regression issue on our side. So to solve those check errors, could you sync the code from master to your working branch?

[PhoenixHe-NV]

@naveenchekuri Please pick this PR #7068 or merge from master to fix the CI

[anton-evseev]

Hi, @lirenhe, I've cherry picked two commit that solved CI errors. SDK java is failing due to timeout as usual, can we get this PR merged?
Also, regarding SDK java... Could we try bumping timeout in SwaggerToSDK.yml to 3 hours? Azure DevOps supports timeouts up to 6 hours for public pipelines, maybe that would resolve our issues.

[PhoenixHe-NV]

@number123 I'm the owner of the swagger to sdk automation. I'm not aware of that the automation need to run that long of time. I need to confirm that does it really need over than an hour to generate SDK？

[anton-evseev]

Yes, as you can see, Java SDK takes more than two hours to generate because it is multi-API SDK and it tries to generate code for each version.

[anton-evseev]

@lirenhe @NullMDR gentle ping

[naveenchekuri]

@lirenhe @NullMDR. We need to commit the PR before 09. please help with this

[PhoenixHe-NV]

@yungezz please force merge this one. The timeout issue will be fixed in the new automation.

[anton-evseev]

Rebased PR to include fixes for CI that were merged into network-august-branch recently

[naveenchekuri]

@yungezz could you please merge the PR