Remove routingConfigNfv

[rutuja-s]

ARM (Control Plane) API Specification Update Pull Request

PR review workflow diagram

Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

[1] ARM review queue (for merge queues, see [4])
The PRs are processed by time opened, ascending. Your PR may show up on 2nd or later page.
If you addressed Step 1 from the diagram and your PR is not showing up in the queue, ensure the label ARMChangesRequested
is removed from your PR. This should cause the label WaitForARMFeedback to be added.
[2] https://aka.ms/azsdk/support/specreview-channel
[3] List of SDK breaking changes approvers in pinned Teams announcement
[4] public repo merge queue, private repo merge queue (for ARM review queue, [1])

If you need further help with anything, see Getting help section below.

Purpose of this PR

What's the purpose of this PR? Check all that apply. This is mandatory!

• New API version. (Such PR should have been generated with OpenAPI Hub, per this wiki doc.)
• Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
• Update existing version to fix swagger quality issues in S360.
• Other, please clarify:
  • Fixing the Routing Configuration property for NVA connection. This API is not publicly available yet and this change should not have any cx impact

Due diligence checklist

To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

• I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
• I have reviewed following Resource Provider guidelines, including
  ARM resource provider contract and
  REST guidelines (estimated time: 4 hours).
  I understand this is required before I can proceed to Step 2, "ARM Review", for this PR.

Breaking changes review (Step 1)

• If the automation determines you have breaking changes, i.e. Step 1 from the diagram applies to you,
  you must follow the breaking changes process.
  IMPORTANT This applies even if:
  • The tool fails while it shouldn't, e.g. due to runtime exception, or incorrect detection of breaking changes.
  • You believe there is no need for you to request breaking change approval, for any reason.
    Such claims must be reviewed, and the process is the same.

ARM API changes review (Step 2)

• If this PR is in purview of ARM review then automation will add the ARMReview label.
• If you want to force ARM review, add the label yourself.
• Proceed according to the diagram at the top of this comment.

Viewing API changes

For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.

Suppressing failures

If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
Swagger-Suppression-Process
to get approval.

Getting help

• For general PR approval workflow, see the diagram at the top of this comment.
• For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
  and https://aka.ms/ci-fix.
• If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

[openapi-pipeline-app]

Next Steps to Merge

✔️ All automated merging requirements have been met! Refer to step 4 in the PR workflow diagram (even if your PR is for data plane, not ARM).

[openapi-pipeline-app]

Swagger Validation Report

️️✔️BreakingChange succeeded [Detail] [Expand]

There are no breaking changes.

️️✔️Breaking Change(Cross-Version) succeeded [Detail] [Expand]

There are no breaking changes.

️️✔️LintDiff succeeded [Detail] [Expand]

Validation passes for LintDiff.

️️✔️Avocado succeeded [Detail] [Expand]

Validation passes for Avocado.

️️✔️SwaggerAPIView succeeded [Detail] [Expand]

️️✔️TypeSpecAPIView succeeded [Detail] [Expand]

️️✔️ModelValidation succeeded [Detail] [Expand]

Validation passes for ModelValidation.

️️✔️SemanticValidation succeeded [Detail] [Expand]

Validation passes for SemanticValidation.

️️✔️PrettierCheck succeeded [Detail] [Expand]

Validation passes for PrettierCheck.

️️✔️SpellCheck succeeded [Detail] [Expand]

Validation passes for SpellCheck.

️🔄PR Summary inProgress [Detail]

️⌛Automated merging requirements met pending [Detail]

_{Posted by Swagger Pipeline | How to fix these errors?}

[openapi-pipeline-app]

Swagger Generation Artifacts

️️✔️ApiDocPreview succeeded [Detail] [Expand]

️⌛SDK Breaking Change Tracking pending [Detail]

_{Posted by Swagger Pipeline | How to fix these errors?}

[openapi-pipeline-app]

Swagger pipeline restarted successfully. If there is ApiView generated, it will be updated in this comment.

[openapi-workflow-bot]

Please address or respond to feedback from the ARM API reviewer.
When you are ready to continue the ARM API review, please remove the ARMChangesRequested label.
This will notify the reviewer to have another look.
If the feedback provided needs further discussion, please use this Teams channel to post your questions - aka.ms/azsdk/support/specreview-channel.
Please include [ARM Query] in the title of your question to indicate that it is ARM-related.

[rutuja-s]

NVA connection (just another virtual wan connection) is an Nfvrp resource as opposed to other connections in virtual wan (VPN, Express route etc) which are Nrp resources. RoutingConfigurationNfv was a new definition added as a Nfvrp version of already existing definition of RoutingConfiguration (used by Nrp resources) in the Swagger. The difference in this definition is as below:

Existing Routing configuration has reference ‘#definitions/SubResource’ which uses property name ‘Id’ and the result is looks like below :

routingConfiguration": {
            "associatedRouteTable": {
              "id": "/subscriptions/subid/resourceGroups/rg1/providers/Microsoft.Network/virtualHubs/virtualHub1/hubRouteTables/hubRouteTable1"
            },

and Nfvrp version of Routing configuration was intended to have this same same property named as ResourceUri instead of id as below:

"routingConfiguration": {
            "associatedRouteTable": {
              "resourceUri": "/subscriptions/subid/resourceGroups/rg1/providers/Microsoft.Network/virtualHubs/virtualHub1/hubRouteTables/hubRouteTable1"
            },

To achieve this, we introduced a new definition in previous API versions which would allow this change from id -> resourceUri

"RoutingConfigurationNfvSubResource": {
      "type": "object",
      "properties": {
        "resourceUri": {
          "type": "string",
          "description": "Resource ID."
        }
      },
      "description": "Reference to RouteTableV3 associated with the connection."
    },

However, in recent reviews and discussions for NVA connection, it was decided to have same Routing configuration property for all the connections to have consistency across them so that portal/terraform or anyone else using rest doesn’t need different automation based on connection type. This would also providing consistent results to the customers. In order to have this consistency, I’ve removed RoutingConfigurationNfv and used RoutingConfiguration instead which is now being flagged as a breaking change in 2023-06-01.

On the customer impact side, NVA connection feature is not yet enabled and hence we do not have any active users that would be impacted by this change.

[Joanna-Yang-Art]

@rutuja-s Please get your PR merged before code freeze date 10/12

[ms-zhenhua]

/azp run

[rutuja-s]

/pr RequestMerge

[Joanna-Yang-Art]

@rutuja-s please request ARM to get the PR merged as soon as possible. NRP don't help review and approve PRs

[rutuja-s]

@rkmanda can you please help with the pr merge? I have all the necessary approvals

[rkmanda]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[rkmanda]

waiting for all checks to pass

[rutuja-s]

@rkmanda any update on this merge?

[rkmanda]

azp /run

[rkmanda]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[rkmanda]

automated checks are stuck, waiting for those to finish

[rkmanda]

Pl get help from the API spec review channel to get unblocked on these stuck checks you can tag Konrad Jamrozik in your post

[rkmanda]

/azp run