Context
The current segment configuration uses a simple $group token that gets instantiated once per registered group. While this covers the primary use case (per-group hub-and-spoke isolation), it's limited when more complex segment topologies are needed.
For example, today you can do:
topology:
segments:
- name: segment-$group
links:
- name: cloud
neighbors: [$group]
But you cannot express things like:
- "customer-a should see all
customer-a-* sub-groups"
- Conditional segment membership based on group name patterns
- Multiple groups matching a prefix in a single segment
Proposal
Replace the simple $group substitution with a proper template engine, similar to what ArgoCD / Helm / External Secrets Operator use. The config would support a segments-template field with Jinja2-style syntax:
topology:
segments-template: |
{% for group in groups %}
- name: segment-{{ group }}
links:
- name: cloud
neighbors: [{{ group }}]
{% endfor %}
This enables more advanced patterns like prefix-based grouping:
topology:
segments-template: |
- name: segment-customer-a
links:
{% for group in groups %}
{% if group is startingwith("customer-a-") %}
- name: {{ group }}
neighbors: [customer-a]
{% endif %}
{% endfor %}
Possible engine to integrate
MiniJinja (minijinja crate)
Context
The current segment configuration uses a simple
$grouptoken that gets instantiated once per registered group. While this covers the primary use case (per-group hub-and-spoke isolation), it's limited when more complex segment topologies are needed.For example, today you can do:
But you cannot express things like:
customer-a-*sub-groups"Proposal
Replace the simple
$groupsubstitution with a proper template engine, similar to what ArgoCD / Helm / External Secrets Operator use. The config would support asegments-templatefield with Jinja2-style syntax:This enables more advanced patterns like prefix-based grouping:
Possible engine to integrate
MiniJinja (
minijinjacrate)