12d927d460
fix: add human_friendly_id to 4 schemas for idempotent Repository sync ( #29 )
...
## Summary
- Add `local_identifier` attribute + `uniqueness_constraints` + `human_friendly_id` to **InfraVlanVniMapping**, **InfraEVPNInstance**, **InfraMlagInterface**, and **InfraUnderlayLink**, following the same pattern already used for `InfraBGPPeerGroup` and `InfraBGPSession`
- Populate `local_identifier` in all corresponding object YAML files with deterministic composite keys so Infrahub can upsert objects during Repository backend sync instead of creating duplicates
## Schema changes
| Schema file | Model | human_friendly_id |
|---|---|---|
| `infrahub/schemas/vlan_vxlan.yml` | `InfraVlanVniMapping` | `local_identifier__value` |
| `infrahub/schemas/vlan_vxlan.yml` | `InfraEVPNInstance` | `local_identifier__value` |
| `infrahub/schemas/mlag.yml` | `InfraMlagInterface` | `local_identifier__value` |
| `infrahub/schemas/extensions.yml` | `InfraUnderlayLink` | `local_identifier__value` |
## Object file changes
| Object file | Kind | Key format | Example |
|---|---|---|---|
| `infrahub/objects/06-vlans-vxlan.yml` | `InfraVlanVniMapping` | `{device}__vlan{vlan_id}__vni{vni_id}` | `leaf1__vlan40__vni110040` |
| `infrahub/objects/06-vlans-vxlan.yml` | `InfraEVPNInstance` | `{device}__vlan{vlan_id}` | `leaf1__vlan40` |
| `infrahub/objects/12-mlag.yml` | `InfraMlagInterface` | `mlag{id}__{device1}-{device2}` | `mlag1__leaf1-leaf2` |
| `infrahub/objects/14-fabric-links.yml` | `InfraUnderlayLink` | `{local_dev}-{local_intf}__{remote_dev}-{remote_intf}` | `spine1-eth1__leaf1-eth11` |
Note: `InfraMlagInterface` objects (4 entries, one per MLAG pair) and `InfraUnderlayLink` objects (16 entries, all spine↔leaf P2P links) are new additions to their respective files.
## Test plan
- [x] `infrahubctl schema load infrahub/schemas/*.yml` succeeds without errors
- [x] `infrahubctl object load infrahub/objects/06-vlans-vxlan.yml` succeeds
- [x] `infrahubctl object load infrahub/objects/12-mlag.yml` succeeds
- [x] `infrahubctl object load infrahub/objects/14-fabric-links.yml` succeeds
- [x] Re-running the same load is idempotent (no duplicate objects created)
- [x] Gitea Repository backend sync completes without import errors
2026-03-03 16:26:46 +00:00
1b918a4cbc
feat: Add Infrahub Jinja2 transform for BGP configuration ( #23 ) ( #27 )
...
## Summary
Closes #23 . Implements a single unified `bgp_yang_transform` covering the complete BGP router stanza for all 10 fabric devices.
**Design decision:** One transform (one query + one template) rather than 4 separate transforms, because all BGP components (process config, peer groups, neighbors, AFs) live under a single `router bgp <ASN>` stanza and must be consistent. This avoids multiple API calls per device and keeps the data model coherent.
| File | Description |
|------|-------------|
| `infrahub/transforms/queries/bgp_intent.gql` | Unified GraphQL query — `InfraBGPRouterConfig` (with peer_groups, sessions) + `InfraBGPAddressFamily` (with active_peer_groups, active_sessions, networks, optional vrf) |
| `infrahub/transforms/templates/bgp_yang.j2` | Jinja2 template — renders `bgp.global`, `bgp.peer_groups`, `bgp.neighbors`, `bgp.address_families`, `bgp.vrf_neighbors`, `bgp.vrf_address_families`; returns `[]` for devices with no BGP config |
| `infrahub/transforms/tests/bgp_yang/test.yml` | Smoke check + unit render tests for leaf1, spine1, leaf7 |
| `infrahub/transforms/tests/bgp_yang/leaf1/` | 3 peer-groups, 5 global neighbors, 2 global AFs |
| `infrahub/transforms/tests/bgp_yang/spine1/` | 1 peer-group (evpn/next-hop-unchanged), 16 neighbors (8 direct underlay + 8 EVPN), IPv4 AF activates individual sessions |
| `infrahub/transforms/tests/bgp_yang/leaf7/` | leaf1 pattern + VRF gold border session (AS 64999) + VRF-scoped IPv4 unicast AF |
| `.infrahub.yml` | Registers `bgp_intent` query and `bgp_yang_transform` |
## Validation
| Device | Expected output |
|--------|----------------|
| `leaf1` | 3 peer-groups, 5 global neighbors (underlay×2, iBGP×1, EVPN×2), 2 AFs, empty VRF sections |
| `spine1` | 1 peer-group (evpn, next-hop-unchanged), 16 neighbors (8 direct with `remote_asn`, 8 EVPN via peer-group), IPv4 AF activates individual sessions |
| `leaf7` | Same as leaf1 (AS 65004) + `vrf_neighbors: [{10.90.90.1, AS 64999, VRF gold}]` + `vrf_address_families: [{ipv4, VRF gold, active_sessions: [10.90.90.1]}]` |
```bash
infrahubctl render bgp_yang_transform device_name=leaf1
infrahubctl render bgp_yang_transform device_name=spine1
infrahubctl render bgp_yang_transform device_name=leaf7
```
## Design notes
- Follows identical conventions to existing transforms (#20–#22)
- All optional relationships (`remote_asn`, `peer_group`, `vrf`, `peer_device`, `update_source`, etc.) wrapped in `is defined and is not none` guards
- `send_community` value `"none"` (schema default) is normalised to `null` in the output — keeps the rendered JSON clean for downstream consumers
- VRF-scoped sessions and AFs are separated into `vrf_neighbors` / `vrf_address_families` arrays, each entry carrying a `"vrf"` key, so the template consumer can trivially iterate per-VRF without filtering
2026-03-01 13:22:51 +00:00
