projectcalico / projectcalico/vpp-dataplane
use Felixconfiguration to able to define uplink
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 172
- Forks
- 47
- Avg merge
- 4d 23h
- Merged PRs (30d)
- 3
Description
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
We have an environment that uplink name is not always the same across all worker/master nodes. in some it's called eth1 and others eth2 for example. right now if we deploy VPP DS it'll take config map (https://github.com/projectcalico/vpp-dataplane/blob/ad7080150fe82518b1e0f612f88b6851def9c271/yaml/generated/calico-vpp.yaml#L182) having a static config with uplink name there.
Describe the solution you'd like
A clear and concise description of what you want to happen.
To solve the issue now we have to keep deploying multiple DS with a nodeselector or affinity rules to be able to differenciate between node uplink interfaces , it'll make our deployment complex as we have to keep track of config maps sparely per node for vpp.
It would be nice to be able to have a way to configure uplink configurable per node but a bit easier than maintaining the whole deployment and config map separate.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context about the feature request here.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the generated deployment configuration in yaml/generated/calico-vpp.yaml, especially the static uplink setting, and trace how Felix configuration is consumed. Determine how an uplink can vary per node without separate DaemonSets or ConfigMaps; done means the deployment supports node-specific uplink names while retaining a manageable shared configuration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100