NSX promotion API fails with the following error message:
"Applying policy intents failed : Config migration failed [Reason: Edge or DFW Section promotion failed]"
The promotion operation fails while creating policy rules with the identifiers specified by the NCP migration errand, with an error like the following:
{'httpStatus': 'BAD_REQUEST', 'error_code': 500287, 'module_name': 'policy', 'error_message': 'Multiple RULE objects with same id, path=[/infra/domains/<foundation_name>/security-policies/asg_<asg_uuid>/rules/pr_<rule_hash>_<proto_uuid>] present in request.'}rule_hash is a SHA1 hash built from the rule's destinations
proto_uuid is a UUID generated from the rule's protocol name and port.
In the corresponding TAS ASG, there will be multiple rules having the same protocol, port, and destinations. There is no reason for having more than 1 rule with a given protocol, port, and destinations.
The migration operation fails and cannot be completed until the issue is resolved. There is, however, no impact on the TAS foundation. Rollback is completed, and NCP keeps operating in MP mode.
VMware Tanzu Application Service (TAS)
NSX-T Policy API Migration tool (MP2P)
NSX Container Plugin (NCP) versions before 4.2.4
This issue is caused by duplicated rules in TAS ASG definition.
In policy mode, NCP builds a hash of the rule content to create the policy rule identifier. A duplicated rule in the TAS ASG definition will cause NCP to fail processing for the ASG. This issue has been resolved in 9.0.2 and 4.2.4, by adding a random 5-character suffix to each rule identifier, thus allowing NCP to tolerate ASGs with duplicated rules.
1) Identify duplicated ASG rules using the script attached to this PR.
2) Delete duplicated rules. It is recommended to remove them directly from the TAS ASG while operating in MP mode.
3) If, for any reason, NCP cannot be restarted in MP mode, delete the duplicated rules directly from NSX.
4) Retry the migration.
DFW rule deletion via UI might not be possible if the TAS foundation is configured to use an NSX principal identity. In this case, proceed with NSX API call using the X-Allow-Overwrite: True header.