-
-
Notifications
You must be signed in to change notification settings - Fork 736
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
GARP/GNA fixes and improvements to parsing quoted strings #2482
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes the order of some entries more logical. Signed-off-by: Quentin Armitage <[email protected]>
Signed-off-by: Quentin Armitage <[email protected]>
If garp_master_delay is non zero, then after a reload when VIPs are added to a VRRP instance in master state, as well as the initial block of GARP messages that are sent, the messages need to be repeated after garp_master_delay seconds. This commit adds sending the second block. Signed-off-by: Quentin Armitage <[email protected]>
Signed-off-by: Quentin Armitage <[email protected]>
Combine garp_pending and gna_pending flags into a single flags; that is all that is necessary and simplifies the code. Signed-off-by: Quentin Armitage <[email protected]>
Signed-off-by: Quentin Armitage <[email protected]>
Previously whenever a VRRP instance send an advert, it checked to see if any more GARPs/GNAs were due to be sent, either for garp_master_delay or garp_master_refresh. Using timer threads removes the checking every time an advert is sent, and the relevant code is only triggered when a timer expires. Further, if any GARPs/GNAs wre delayed to to rate limiting of sending these messages on an interface or group, there was a single timer thread for the next time a delayed GARP/GNA could be sent, and when the timer expired, all VRRP instances had to be checked, and any instances that had been delayed sending had to check all VIPs/eVIPs to see if a GARP/GNA was needed for it. This also meant that once a GARP/GNA had been delayed for a VIP, only one more GARP/GNA would be sent, rather than the number configured by garp_master_repeat/garp_lower_prio_repeat/garp_master_refresh_repeat. This commit now uses a thread per interface/garp_group and address family for handling delayed sending, and will always send the configured number of repeat messages configure by the garp_..._repeat parameters. This approach of using threads per activity will enable keepalived to scale much better with very large configurations that send multiple GARP/GNA messages. Signed-off-by: Quentin Armitage <[email protected]>
The field simply was not needed, or really used. Signed-off-by: Quentin Armitage <[email protected]>
…alues Also allies to gna_interval Signed-off-by: Quentin Armitage <[email protected]>
Signed-off-by: Quentin Armitage <[email protected]>
Following \x keepalived processed all following hex digits, but only returned one byte. For example \x20file would result in a byte 0x0f followed by the string "ile". This commit limits the number of hex digits consumed to 2. Signed-off-by: Quentin Armitage <[email protected]>
Signed-off-by: Quentin Armitage <[email protected]>
It was a good idea at the time, but is not really appropriate. The parsing can be done just as simply without using alloc_strvec(). Signed-off-by: Quentin Armitage <[email protected]>
If a line with a quoted string has unbalanced quote characters when parsed as a standard (not quoted) string, an innapropriate warning was issued for unmatches quotes. This commit now stops the warning. This commit is not elegant, and it would be appreciated if a neater solution could be found. If anyone has a better solution, please submit a pull request or raise an issue explaining the solution. Signed-off-by: Quentin Armitage <[email protected]>
Debian has a patch for building keepalived that removed -ffile-prefix-map=... to assist with repeatible build. The commit adds removing -ffile-prefix-map= from the gcc options if repeatible builds are enabled. Signed-off-by: Quentin Armitage <[email protected]>
Commit 3e842cb - "configure: Remove -ffile-prefix-map= for repeatible builds" missed a closing ')' in the introduced AS_IF() test. Signed-off-by: Quentin Armitage <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.