Skip to content
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

Allow configuration of router_virtual_id #26

Closed
David-Igou opened this issue Aug 4, 2020 · 1 comment
Closed

Allow configuration of router_virtual_id #26

David-Igou opened this issue Aug 4, 2020 · 1 comment

Comments

@David-Igou
Copy link
Contributor

If the cluster keepalived-operator is deployed on shares an environment with other instances of keepalived, it is possible for conflicts to happen. Operators should be able to override router_virtual_id to prevent this from happening

By default router_virtual_id always starts with "1" as VIPs are assigned, and this cannot be configured. If router_virtual_id is set by adding annotation `keepalived-operator.redhat-cop.io/verbatimconfig: '{ "router_virtual_id": "11" }' It does not overwrite the original entry, instead producing the config:

vrrp_instance helloworld/helloworld {
  interface ens192
  virtual_router_id 1
  virtual_ipaddress {
    13.37.13.37
  }

  virtual_router_id 10
}

Which leads to more issues.

@raffaelespazzoli
Copy link
Collaborator

raffaelespazzoli commented Aug 5, 2020

each loadbalancer/externalIP service gets a different virtual_router_id, the operator assumes that all of the 255 are available in the subnet where the operator runs.
To allow for the operator to run in subnets where other ipfailover instances are running I think the best approach would be to pass a list of unavailable of virtual_router_ids in the CR. This will reduce the number of supportable services, but should allow for the coexistence.
Also see this #9 on allowing enabling support for more than 255 services.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants