The Peering Location for an Express Route Cross Connection ... cannot be modified from PL Name to .

[jbernardini]

• Package Name: azure-mgmt-network
• Package Version: 16.0.0b1, 16.0.0 and 18.0.0
• Operating System: Win10
• Python Version: 3.9.4

Describe the bug
Appears to be the same behavior as described in: Azure/azure-sdk-for-net#20546. Only I've never had this working and can't find an example anywhere so I can't say for sure I haven't done something wrong. Note too I first worked through errors that seem to require the location and circuit id. These seem redundant to the skey (as does peering location) since you pull these values on a get(skey).

network_client.express_route_cross_connections.begin_create_or_update()

fails with:

File "./modify.py", line 38, in main
response = network_client.express_route_cross_connections.begin_create_or_update(
File "/home/user/.local/lib/python3.8/site-packages/azure/mgmt/network/v2020_11_01/operations/_express_route_cross_connections_operations.py", line 336, in begin_create_or_update
raw_result = self._create_or_update_initial(
File "/home/user/.local/lib/python3.8/site-packages/azure/mgmt/network/v2020_11_01/operations/_express_route_cross_connections_operations.py", line 292, in _create_or_update_initial
raise HttpResponseError(response=response, error_format=ARMErrorFormat)
azure.core.exceptions.HttpResponseError: (PeeringLocationCannotBeModifiedForACrossConnection) The Peering Location for an Express Route Cross Connection /subscriptions//resourceGroups//providers/Microsoft.Network/expressRouteCrossConnections/********* cannot be modified from PL Name to .

To Reproduce
Steps to reproduce the behavior:

1. expsrt = getexpressroute(skey)
2. resgrp = expsrt['id'].split('/')[4]
3. response = network_client.express_route_cross_connections.begin_create_or_update(
   resgrp,
   skey,
   {
   "location": expsrt['location'],
   "service_provider_provisioning_state": "Provisioned",
   "express_route_circuit": expsrt['express_route_circuit'],
   "peering_location": expsrt['peering_location'] #same error if this is not included.
   }
   ).result()

Expected behavior
Successful update of "service_provider_provisioning_state": "Provisioned",

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
I also added a comment on the other bug in the description.

[mccoyp]

Hi @jbernardini, thank you for opening this issue! We'll investigate ASAP.

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @aznetsuppgithub.

Issue Details

---

• Package Name: azure-mgmt-network
• Package Version: 16.0.0b1, 16.0.0 and 18.0.0
• Operating System: Win10
• Python Version: 3.9

Describe the bug
Appears to be the same behavior as described in: Azure/azure-sdk-for-net#20546. Only I've never had this working and can't find an example anywhere so I can't say for sure I haven't done something wrong. Note too I first worked through errors that seem to require the location and circuit id. These seem redundant to the skey (as does peering location) since you pull these values on a get(skey).

network_client.express_route_cross_connections.begin_create_or_update()

fails with:

File "./modify.py", line 38, in main
response = network_client.express_route_cross_connections.begin_create_or_update(
File "/home/user/.local/lib/python3.8/site-packages/azure/mgmt/network/v2020_11_01/operations/_express_route_cross_connections_operations.py", line 336, in begin_create_or_update
raw_result = self._create_or_update_initial(
File "/home/user/.local/lib/python3.8/site-packages/azure/mgmt/network/v2020_11_01/operations/_express_route_cross_connections_operations.py", line 292, in _create_or_update_initial
raise HttpResponseError(response=response, error_format=ARMErrorFormat)
azure.core.exceptions.HttpResponseError: (PeeringLocationCannotBeModifiedForACrossConnection) The Peering Location for an Express Route Cross Connection /subscriptions//resourceGroups//providers/Microsoft.Network/expressRouteCrossConnections/********* cannot be modified from PL Name to .

To Reproduce
Steps to reproduce the behavior:

1. expsrt = getexpressroute(skey)
2. resgrp = expsrt['id'].split('/')[4]
3. response = network_client.express_route_cross_connections.begin_create_or_update(
   resgrp,
   skey,
   {
   "location": expsrt['location'],
   "service_provider_provisioning_state": "Provisioned",
   "express_route_circuit": expsrt['express_route_circuit'],
   "peering_location": expsrt['peering_location'] #same error if this is not included.
   }
   ).result()

Expected behavior
Successful update of "service_provider_provisioning_state": "Provisioned",

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
I also added a comment on the other bug in the description.

Author:	jbernardini
Assignees:	msyyc
Labels:	Mgmt, Network, Service Attention, bug, customer-reported
Milestone:	-

[jbernardini]

With the function call below so that no parameter serialization was required, I was able to replace line 283 of _express_route_cross_connections_operations.py as shown here and move past the error. So as noted in the other bug the issue seems to be in the serialization. Specifically what was happing is the peeringLocation key/value pair was being stripped out. You can see this by first printing parameters and then body_content.

283 #body_content = self._serialize.body(parameters, 'ExpressRouteCrossConnection')
284 body_content = parameters

response = network_client.express_route_cross_connections.begin_create_or_update(
resource_group,
skey,
{
"location": expsrt['location'],
"properties": {
"expressRouteCircuit": {
"id": expsrt['express_route_circuit']['id']
},
"peeringLocation": expsrt['peering_location'],
"bandwidthInMbps": expsrt['bandwidth_in_mbps'],
"serviceProviderProvisioningState": "Provisioned",
}
}
).result()

[jbernardini]

Did a bit more digging and found what is maybe a more correct fix in the model and reverted _express_route_cross_connections_operations.py to original. The following changes are all in the ExpressRouteCrossConnection class definition in _models_py3.py. For the changes in init I followed the earlier convention from _models.py just because it is simple and required less line edits.

in _validation, commented out these lines since we don't want to drop these values in the serializer/validation.

9468 #'peering_location': {'readonly': True},
9469 #'bandwidth_in_mbps': {'readonly': True},

in init, commented out 9509/10 and inserted replacements with values in 9511/12 since we need to pass values. As noted above there's a clear convention I did not follow but it works for a patch.

9509 #self.peering_location = None
9510 #self.bandwidth_in_mbps = None
9511 self.peering_location = kwargs.get('peering_location', None)
9512 self.bandwidth_in_mbps = kwargs.get('bandwidth_in_mbps', None)

If you recall from my first comment I mentioned having to provide these values felt redundant and now having worked through this it's clear the model wasn't written with the intent to provide them. So I'm guessing this all stems from a recentish change where they've become required parameters even though you can't modify them. So if that's true the best solution is to revert the requirement but this should work for a patch in the meantime if someone else needs it.

Here's my function call. If anyone grabs this for an example pay attention to where I've used camelCase vs. snake_case. I think it may matter if you look at the attribute map in the model. When I tried all snake_case in my function call it failed and I didn't bother looking any harder since this was working.

response = network_client.express_route_cross_connections.begin_create_or_update(
resource_group,
skey,
{
"location": expsrt['location'],
"properties": {
"expressRouteCircuit": {
"id": expsrt['express_route_circuit']['id']
},
"peeringLocation": expsrt['peering_location'],
"bandwidthInMbps": expsrt['bandwidth_in_mbps'],
"serviceProviderProvisioningState": "NotProvisioned",
}
}
).result()

[ghost]

Hi @jbernardini. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[ghost]

Hi @jbernardini, since you haven’t asked that we “/unresolve” the issue, we’ll close this out. If you believe further discussion is needed, please add a comment “/unresolve” to reopen the issue.

[jbernardini]

/unresolve

[jbernardini]

Upgraded to azure-mgmt-network 19.3.0 and the issue persists.

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @exrsuppgithub.

Issue Details

---

• Package Name: azure-mgmt-network
• Package Version: 16.0.0b1, 16.0.0 and 18.0.0
• Operating System: Win10
• Python Version: 3.9.4

Describe the bug
Appears to be the same behavior as described in: Azure/azure-sdk-for-net#20546. Only I've never had this working and can't find an example anywhere so I can't say for sure I haven't done something wrong. Note too I first worked through errors that seem to require the location and circuit id. These seem redundant to the skey (as does peering location) since you pull these values on a get(skey).

network_client.express_route_cross_connections.begin_create_or_update()

fails with:

File "./modify.py", line 38, in main
response = network_client.express_route_cross_connections.begin_create_or_update(
File "/home/user/.local/lib/python3.8/site-packages/azure/mgmt/network/v2020_11_01/operations/_express_route_cross_connections_operations.py", line 336, in begin_create_or_update
raw_result = self._create_or_update_initial(
File "/home/user/.local/lib/python3.8/site-packages/azure/mgmt/network/v2020_11_01/operations/_express_route_cross_connections_operations.py", line 292, in _create_or_update_initial
raise HttpResponseError(response=response, error_format=ARMErrorFormat)
azure.core.exceptions.HttpResponseError: (PeeringLocationCannotBeModifiedForACrossConnection) The Peering Location for an Express Route Cross Connection /subscriptions//resourceGroups//providers/Microsoft.Network/expressRouteCrossConnections/********* cannot be modified from PL Name to .

To Reproduce
Steps to reproduce the behavior:

1. expsrt = getexpressroute(skey)
2. resgrp = expsrt['id'].split('/')[4]
3. response = network_client.express_route_cross_connections.begin_create_or_update(
   resgrp,
   skey,
   {
   "location": expsrt['location'],
   "service_provider_provisioning_state": "Provisioned",
   "express_route_circuit": expsrt['express_route_circuit'],
   "peering_location": expsrt['peering_location'] #same error if this is not included.
   }
   ).result()

Expected behavior
Successful update of "service_provider_provisioning_state": "Provisioned",

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
I also added a comment on the other bug in the description.

Author:	jbernardini
Assignees:	msyyc
Labels:	bug, Network - ExpressRoute, Service Attention, Mgmt, customer-reported, needs-team-attention
Milestone:	-

[navba-MSFT]

@jbernardini Apologies for the late reply. We are looking into this issue. We will provide an update on this once we have more details.

@exrsuppgithub Could you please look into this and provide an update once you get a chance ? Awaiting your reply.

[jonstout]

Any updates on this? This is still broken and the work around mentioned by @jbernardini isn't working for me.

[jbernardini]

@jonstout we've got an operational patch as part of our container image. can probably help get you working in the meantime.

[jamesharr]

Is your operational patch going to be put into a release of this SDK in the future?

We have a work-around in place already (querying the API directly) and would like to use the patched API. It might be more work to import your patch than to just continue using our work-around until there's a fix released.

[jbernardini]

no we're just an API consumer like you, but we had to have it working in production.Sent from my iPhoneOn Oct 20, 2022, at 12:34 PM, James Harr ***@***.***> wrote: Is your operational patch going to be put into a release of this SDK soon? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[jamesharr]

no we're just an API consumer like you, but we had to have it working in production.

How simple is your patch?

[jbernardini]

Sorry for the delayed response. I saw this, intended to respond the next morning and then spaced it till tonight. Our patch is pretty basic. We build on Ubuntu 20.04 which includes Python 3.8. We just use the patch command.

We install the pip library azure-mgmt-network==18.0.0. I see the line numbers have changed in 22.1.0 as follows:

The following changes are all in the ExpressRouteCrossConnection class definition in _models_py3.py.

in _validation, commented out these lines since we don't want to drop these values in the serializer/validation.
11511 #'peering_location': {'readonly': True},
11512 #'bandwidth_in_mbps': {'readonly': True},

in init, replace 11573/11574 since we need to pass values.

-- self.peering_location = None
-- self.bandwidth_in_mbps = None
++ self.peering_location = kwargs.get('peering_location', None)
++ self.bandwidth_in_mbps = kwargs.get('bandwidth_in_mbps', None)

We have a patches/azure.patch file in our project root with the following contents (for 18.0.0).

diff -ruN azure/mgmt/network/v2020_11_01/models/_models_py3.py azure/mgmt/network/v2020_11_01_patched/models/_models_py3.py
--- azure/mgmt/network/v2020_11_01/models/_models_py3.py	2022-02-22 21:38:18.831088781 +0000
+++ azure/mgmt/network/v2020_11_01_patched/models/_models_py3.py	2022-02-25 20:36:07.920358200 +0000
@@ -9465,8 +9465,6 @@
         'primary_azure_port': {'readonly': True},
         'secondary_azure_port': {'readonly': True},
         's_tag': {'readonly': True},
-        'peering_location': {'readonly': True},
-        'bandwidth_in_mbps': {'readonly': True},
         'provisioning_state': {'readonly': True},
     }
 
@@ -9506,8 +9504,8 @@
         self.primary_azure_port = None
         self.secondary_azure_port = None
         self.s_tag = None
-        self.peering_location = None
-        self.bandwidth_in_mbps = None
+        self.peering_location = kwargs.get('peering_location', None) 
+        self.bandwidth_in_mbps = kwargs.get('bandwidth_in_mbps', None)
         self.express_route_circuit = express_route_circuit
         self.service_provider_provisioning_state = service_provider_provisioning_state
         self.service_provider_notes = service_provider_notes

And finally our Dockerfile includes:

RUN cd /usr/local/lib/python3.8/dist-packages \
     && for FILE in `ls /tmp/patches/*.patch`; do patch -p0 < ${FILE}; done

[jbernardini]

issue persists in azure-mgmt-network 25.3.0. The same patch as above works now targeting /usr/local/lib/python3.8/dist-packages/azure/mgmt/network/models/_models.py

[github-actions]

Hi @jbernardini, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.