Add support for coming up with a persist policy #563
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
"opflex": {
"startup": {
"policy-file": "/home/mchalla/thomas/pol.json",
"policy-duration": 0,
"resolve-aft-conn": false
},
- opflex.startup.policy-file contains pol.json to use at startup
- opflex.startup.policy-duration tells how long in
seconds to keep resolving policy from the above pol.json
- opflex.startup.resolve-aft-conn wait till conn before using startup db
use in combination with duration > 0
- opflex.startup.resolve-once placeholder for resolving only first time from startup db
- opflex.startup.full-proxy placeholder use startup db for life of opflex
meaning startup db will be updated at run time to keep both in sync
If policy-file exists we create a startupdb thats used for
intermediate resolves until the leaf connection succeeds based
on the above startup-policy-duration
On every local resolve we lookup startupdb and recursively
resolve children and put those in the running modb and
generating notifications as needed.
On a connect to leaf depending on the above timer and the fact
that these threads can run in parallel we will continue to resolve
from startupdb while also sending all the resolves to the leaf.
Once the curtime is beyond the set duration functionality reverts
to current behavior of only resolving from the leaf.
On stop we write current running policy into pol.json from the config
if present.
If the file is missing functionality is same as before.
Change isOrphan to skip check when using startup db since the timing
of the sync resolve is causing some valid mos to be deleted as orphans
(still investigating an async approach similar to how it would work
with a mock server or leaf)
Signed-off-by: Madhu Challa <challa@gmail.com>
(cherry picked from commit a1e4e3c)
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.
If policy-file exists we create a startupdb thats used for intermediate resolves until the leaf connection succeeds based on the above startup-policy-duration
On every local resolve we lookup startupdb and recursively resolve children and put those in the running modb and generating notifications as needed.
On a connect to leaf depending on the above timer and the fact that these threads can run in parallel we will continue to resolve from startupdb while also sending all the resolves to the leaf.
Once the curtime is beyond the set duration functionality reverts to current behavior of only resolving from the leaf.
On stop we write current running policy into pol.json from the config if present.
If the file is missing functionality is same as before.
Change isOrphan to skip check when using startup db since the timing of the sync resolve is causing some valid mos to be deleted as orphans (still investigating an async approach similar to how it would work
with a mock server or leaf)
Signed-off-by: Madhu Challa challa@gmail.com
(cherry picked from commit a1e4e3c)