Repository navigation
document multi-fabric and multi-domain - #360
edipascale wants to merge 1 commit into
Conversation
|
🚀 Deployed on https://preview-360--hedgehog-docs.netlify.app |
There was a problem hiding this comment.
🟡 Changes recommended
Several statements misdescribe topology defaults, and the BFD example contradicts its configured value.
4 open findings
What changed in this PR
Documents multi-fabric, multi-domain, and External local-ASN configuration.
Changes:
- Adds a comprehensive multi-fabric deployment guide.
- Links related user and architecture guides.
- Adds the default
Fabricto the sample wiring.
| File | Description |
|---|---|
docs/user-guide/multi-fabric.md |
Documents fabrics, domains, placement, and constraints. |
docs/user-guide/vpcs.md |
Links VPC topology configuration guidance. |
docs/user-guide/gateway-add.md |
Explains domain-specific gateway ASNs. |
docs/user-guide/external.md |
Documents topology placement and local ASN. |
docs/user-guide/devices.md |
Links switch topology guidance. |
docs/user-guide/connections.md |
Notes connection fabric constraints. |
docs/install-upgrade/build-wiring.md |
Adds the default Fabric resource. |
docs/architecture/fabric.md |
Introduces multiple fabrics and domains. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
8a68d3d to
056697d
Compare
There was a problem hiding this comment.
This page needs some pictures/ diagrams, which is easier said than done
There was a problem hiding this comment.
100% agree. I have to check what can be done with the hhfab diagram tool @pau-hedgehog built and adapt it if needed so it can better represent fabrics and domains
There was a problem hiding this comment.
claude kindly helped to produce this, but the mermaid version does not come out as pretty, and in any case it is a pretty dense picture with a lot of detail, which makes it hard to show it in the tiny width we have in the guide 🤔
| ``` | ||
|
|
||
| 1. Must match `config.gateway.asn` from Fabricator configuration (use `kubectl get fabricator -n fab -o jsonpath='{.items[0].spec.config.gateway.asn}'`) | ||
| 1. Must match `config.gateway.asn` from Fabricator configuration (use `kubectl get fabricator -n fab -o jsonpath='{.items[0].spec.config.gateway.asn}'`). With [more than one fabric or domain](multi-fabric.md), it must instead be the `gatewayASN` of the domain named in the gateway's `spec.topology` |
There was a problem hiding this comment.
Would it be the same to just give the new jsonpath string instead of describing it
There was a problem hiding this comment.
the ask from @Frostman was to "hide the multi-fabric stuff from users who don't need it", insofar as possible, so that's why I tried to keep everything contained to that one new page and only mention it in passing in other places. But I agree that it's a thin line to walk between clarity and hiding unnecessary complexity. If we decide to be explicit I'd probably add the topology fields to all of the specs of the objects that got one (while still referring to the new page for details)
plus the local ASN for externals that was recently added. keep the multi-fabric stuff self contained as much as possible, so that users that do not care about it do not have to deal with it. Signed-off-by: Emanuele Di Pascale <emanuele@githedgehog.com>
056697d to
79f2bcb
Compare
plus the local ASN for externals that was recently added.
keep the multi-fabric stuff self contained as much as possible, so that users that do not care about it do not have to deal with it.