-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A route rule is added for each line in route-tables.cfg #11
Labels
Comments
brakthehack
added
bug
Something isn't working
good first issue
Good for newcomers
labels
Jan 21, 2021
brakthehack
added a commit
to brakthehack/vmware-haproxy
that referenced
this issue
Mar 11, 2021
Given duplicate route entries can be added because of different route types, we need to account for this in the route table addition logic to ensure only a single route table gets added in case multiple routes from that table exist. Fixes haproxytech#11
brakthehack
added a commit
to brakthehack/vmware-haproxy
that referenced
this issue
Mar 11, 2021
Previously, HAProxy would not route to additional workload networks without user customization because we did not give them the option to provide workload networks interfaces via the UI. This change implements the ability for the user to provide workload networks the user wishes to route to. Since we expect workload networks to be routable to each other, we can program route rules to user-provided CIDR ranges in which routes will exit via the workload default gateway. These routes are configurable via a new file located at /etc/vmware/workload-networks.cfg. This file is written once just before cloud-init performs the bootstrapping. This change also fixes a few bugs in route table configuration. Closes haproxytech#15, haproxytech#11, haproxytech#10
brakthehack
added a commit
to brakthehack/vmware-haproxy
that referenced
this issue
Mar 11, 2021
Previously, HAProxy would not route to additional workload networks without user customization because we did not give them the option to provide workload networks interfaces via the UI. This change implements the ability for the user to provide workload networks the user wishes to route to. Since we expect workload networks to be routable to each other, we can program route rules to user-provided CIDR ranges in which routes will exit via the workload default gateway. These routes are configurable via a new file located at /etc/vmware/workload-networks.cfg. This file is written once just before cloud-init performs the bootstrapping. This change also fixes a few bugs in route table configuration. Closes haproxytech#15, haproxytech#11, haproxytech#10
brakthehack
added a commit
to brakthehack/vmware-haproxy
that referenced
this issue
Mar 12, 2021
Previously, HAProxy would not route to additional workload networks without user customization because we did not give them the option to provide workload networks interfaces via the UI. This change implements the ability for the user to provide workload networks the user wishes to route to. Since we expect workload networks to be routable to each other, we can program route rules to user-provided CIDR ranges in which routes will exit via the workload default gateway. These routes are configurable via a new file located at /etc/vmware/workload-networks.cfg. This file is written once just before cloud-init performs the bootstrapping. This change also fixes a few bugs in route table configuration. Closes haproxytech#15, haproxytech#11, haproxytech#10
brakthehack
added a commit
to brakthehack/vmware-haproxy
that referenced
this issue
Apr 22, 2021
Given duplicate route entries can be added because of different route types, we need to account for this in the route table addition logic to ensure only a single route table gets added in case multiple routes from that table exist. Fixes haproxytech#11
brakthehack
added a commit
to brakthehack/vmware-haproxy
that referenced
this issue
Apr 22, 2021
Previously, HAProxy would not route to additional workload networks without user customization because we did not give them the option to provide workload networks interfaces via the UI. This change implements the ability for the user to provide workload networks the user wishes to route to. Since we expect workload networks to be routable to each other, we can program route rules to user-provided CIDR ranges in which routes will exit via the workload default gateway. These routes are configurable via a new file located at /etc/vmware/workload-networks.cfg. This file is written once just before cloud-init performs the bootstrapping. This change also fixes a few bugs in route table configuration. Closes haproxytech#15, haproxytech#11, haproxytech#10
brakthehack
added a commit
that referenced
this issue
Apr 22, 2021
Previously, HAProxy would not route to additional workload networks without user customization because we did not give them the option to provide workload networks interfaces via the UI. This change implements the ability for the user to provide workload networks the user wishes to route to. Since we expect workload networks to be routable to each other, we can program route rules to user-provided CIDR ranges in which routes will exit via the workload default gateway. These routes are configurable via a new file located at /etc/vmware/workload-networks.cfg. This file is written once just before cloud-init performs the bootstrapping. This change also fixes a few bugs in route table configuration. Closes #15, #11, #10
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We observed that route rules are added for each route in
/etc/vmware/route-tables.cfg
. See below:Instead we should see only a single lookup for each network for each route table, which means it should look something like this:
There's no harm with this bug per se, but it may be confusing to users.
The text was updated successfully, but these errors were encountered: