user-guide: add gateway-failover documentation #259
Conversation
|
🚀 Deployed on https://preview-259--hedgehog-docs.netlify.app |
Fredi-raspall
force-pushed
the
pr/fredi/gw_failover
branch
2 times, most recently
from
6947ea5 to
2e2879c
Compare
There was a problem hiding this comment.
Pull request overview
This PR extends the user guide to document gateway redundancy/fail-over behavior and integrates the new material into the navigation and existing gateway docs. It also slightly refines existing gateway-related titles to better reflect their scope.
Changes:
- Add a dedicated “Gateway fail-over and redundancy” user-guide page explaining gateway groups, traffic mapping, and fail-over behavior.
- Link the new page from the overview and the
.pagesnavigation under a new “Gateway” section. - Retitle the main gateway and gateway-add docs to “Gateway overview” and “Adding Gateways to the fabric” for clearer context.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| docs/user-guide/overview.md | Adds a TOC entry pointing to the new gateway-failover documentation so users can discover redundancy guidance. |
| docs/user-guide/gateway.md | Renames the main heading to “Gateway overview” to clarify that this page introduces gateway concepts now complemented by a separate fail-over page. |
| docs/user-guide/gateway-failover.md | Introduces detailed documentation for gateway redundancy, gateway groups, traffic mapping, and fail-over behavior, including configuration snippets and design rationale. |
| docs/user-guide/gateway-add.md | Updates the title to “Adding Gateways to the fabric” to align with a more general multi-gateway deployment story. |
| docs/user-guide/.pages | Groups gateway-related docs under a “Gateway” nav section and includes the new fail-over page, improving navigation around gateway topics. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
qmonnet
left a comment
qmonnet
left a comment
There was a problem hiding this comment.
Great document!
I'm usually picky with the style in the docs (Logan knows something about it), so I've got tons of nitpicks, but nothing major.
I'd also wrap the text on 80-character lines as I find it easier to diff and work with smaller lines, although I'm not sure we have a consensus about that.
One comment would be to remain careful with the number of admonitions (!!! note) in the document. It's good to have a few ones to insert visual pauses in long sections, but having too many ones may break the flow. You have quite a number of nots, and I think some of them could be regular paragraphs and it would help with overall readability.
Fredi-raspall
force-pushed
the
pr/fredi/gw_failover
branch
3 times, most recently
from
f6dacef to
629ca3b
Compare
|
I come to this PR to say that you could put a diagram on it: ;) I could work on representing the gateway group if you need it |
Hey Pau. I'm fine adding a diagram. However I am not sure if it will help too much if:
We could add some representation, but it will mostly need to be manual? |
Fredi-raspall
force-pushed
the
pr/fredi/gw_failover
branch
3 times, most recently
from
9bae58e to
5f9f499
Compare
On fabricator master we can represent VPCs already by querying a running Fabric (hhfab vlab diagram --live):
I was thinking something similar to ESLAG groups to enclose gateways in a dashed rectangle. Shouldn't be too difficult. But I don't want to add noise to this review. We can address it some other time |
Nice! I'm fine with adding it if it helps to understand the feature. Can be now or later. |
Fredi-raspall
force-pushed
the
pr/fredi/gw_failover
branch
from
5f9f499 to
163577a
Compare
qmonnet
left a comment
qmonnet
left a comment
There was a problem hiding this comment.
Looks OK from my side, thanks!
Frostman
left a comment
Frostman
left a comment
There was a problem hiding this comment.
It looks okay other then the primary gateway selection - that have to be fixed but docs could be updated later
Fredi-raspall
force-pushed
the
pr/fredi/gw_failover
branch
from
163577a to
0d487dc
Compare
Signed-off-by: Fredi Raspall <fredi@githedgehog.com>
Signed-off-by: Fredi Raspall <fredi@githedgehog.com>
Fredi-raspall
force-pushed
the
pr/fredi/gw_failover
branch
from
ec4c7e4 to
5eb1819
Compare
| Gateways implement services that are, in many cases, stateful. To correctly handle flows, the packets in the forward and reverse direction should be processed by the same gateway. The Hedgehog Fabric fail-over strategy is such that only one gateway handles a particular flow at any point in time. Gateway group priorities help to ensure that edge devices participating in a VPC peering select the same gateway. In future releases, it may be possible to balance the traffic of a single VPC peering over multiple gateways. | ||
|
|
||
| !!! note | ||
| Since group membership priorities are specified in the gateways themselves (instead of the `GatewayGroup`s), with many groups and gateways, two or more gateways may end up being assigned the same priority in a given group. The fabric will not reject such a configuration: despite having the same priorities, only one of the gateways will be the preferred; the first when ordering the gateways within the group alphabetically by name. This tie-breaking criteria is implemented by all gateways so that only one gateway per group is selected consistently across the fabric. |
There was a problem hiding this comment.
I think we should clarify here that it applies to when prio are the same, but ok for me
There was a problem hiding this comment.
I think we should clarify here that it applies to when prio are the same, but ok for me
Sorry @Frostman . I don't understand your point. Isn't it clear that we're talking about the case when you have two or more gateways with the same priority (and it is higher than the rest)?
... two or more gateways may end up being assigned the same priority in a given group...
... despite having the same priorities, only one of the gateways will be the preferred; the first when ordering the gateways within the group alphabetically by name
4 participants
Closes: #248
Unsure if this closes #249