Bootstrap cross reference rules

[mthurstocisco]

Related Issue(s)

Related Collection Role

• cisco.nac_dc_vxlan.validate
• cisco.nac_dc_vxlan.dtc.create
• cisco.nac_dc_vxlan.dtc.deploy
• cisco.nac_dc_vxlan.dtc.remove
• other

Related Data Model Element

• vxlan.fabric
• vxlan.global
• vxlan.topology
• vxlan.underlay
• vxlan.overlay
• vxlan.overlay_extensions
• vxlan.policy
• vxlan.multisite
• defaults.vxlan
• other

Proposed Changes

Test Notes

Cisco Nexus Dashboard Version

Checklist

• Latest commit is rebased from develop with merge conflicts resolved
• New or updates to documentation has been made accordingly
• Assigned the proper reviewers

[dacasti2mx]

WiP

[dacasti2mx]

use keys_found, not keys_data, for enable_bootstrap

data_model_key_check() puts False into keys_no_data, so keys_data means "present and truthy", not just "present".

That creates a false negative when both paths exist:

vxlan.global.ibgp.bootstrap.enable_bootstrap: false
vxlan.global.bootstrap.enable_bootstrap: true

The current rule skips the explicit fabric-type false, falls back to the deprecated common true, and passes. But the inventory template reads the fabric-type path, so POAP/preprovision is still silently dropped.

we can use keys_found and only fall back to the deprecated common path when the fabric-type key is absent.

[dacasti2mx]

Remove the unused ISN map entry
This rule lives in common/, and ISN fabrics load isn/ only. Also, ISN bootstrap uses:

vxlan.multisite.isn.bootstrap.enable_bootstrap

not vxlan.global.isn....

[mthurstocisco]

@dacasti2mx Noted on the ISN part, I will create a copy of the policy for ISN but with the correct paths.

Re the first point though, I don't think there is anything wrong with the logic there, I am not covering for the situation where a user has used both parts of the model, I think if you defined both, the framework ignores the old one anyway? is this the case @mtarking @mikewiebe ?

[dacasti2mx]

Hi Matt, I understand your point, and I think we are aligned on the intended behavior.

To make my comment clearer, I intentionally tested a mixed/bad data model that contains both the current path and the deprecated fallback path. I know this is not a valid current model when the nac-vxlan schema is enforced, but it is useful to test the fallback logic directly.

The test case was:

current path:

vxlan.global.ibgp.bootstrap.enable_bootstrap: false

deprecated fallback path:

vxlan.global.bootstrap.enable_bootstrap: true

With pdb, after checking the current path, data_model_key_check() reported:

(Pdb) p check

{
  'keys_found': ['vxlan', 'global', 'ibgp', 'bootstrap', 'enable_bootstrap'],
  'keys_not_found': [],
  'keys_data': ['vxlan', 'global', 'ibgp', 'bootstrap'],
  'keys_no_data': ['enable_bootstrap']
}

So the key exists in the correct location, but because its value is False, it is not in keys_data.

With the current PR condition:

if "enable_bootstrap" in check["keys_data"]:

the explicit False value is not read, enable_bootstrap stays None, and the fallback block can still run. In this mixed test case, the deprecated fallback path was true, so the current rule ended with enable_bootstrap=True and returned no error.

I also checked against the current nac-vxlan schema, and as expected, vxlan.global.bootstrap is rejected as an unexpected element. So this is not a schema-valid current model; it is only a targeted fallback test.

The reason I still think keys_found is the right change is that it matches the behavior you described exactly: if the correct key exists, read its actual value, including False; only fall back when the correct key is absent.

Long story short, I would prefer to use keys_found over keys_data

[mthurstocisco]

updated @dacasti2mx

[dacasti2mx]

LGTM

[juburnet]

@mthurstocisco look at adding to https://github.com/netascode/ansible-dc-vxlan/blob/develop/roles/validate/files/rules/common/204_global_bootstrap.py and isn

[dacasti2mx]

re-tested the latest changes.
tested both common and ISN paths with minimal schema-valid models, plus the mixed fallback case we discussed earlier

Everything behaves as expected:

• POAP + bootstrap false -> semantic error
• POAP + bootstrap true -> no error
• no POAP -> no error
• ISN uses the correct vxlan.multisite.isn.bootstrap.enable_bootstrap path
  LGTM.