lib, zebra: Vty show yield/resume, use for "show ip route"#19337
lib, zebra: Vty show yield/resume, use for "show ip route"#19337mjstapp wants to merge 3 commits into
Conversation
mjstapp
force-pushed
the
vty_show_resume
branch
from
fd2d932 to
3c90c22
Compare
mjstapp
force-pushed
the
vty_show_resume
branch
from
3c90c22 to
ddb83de
Compare
mjstapp
force-pushed
the
vty_show_resume
branch
2 times, most recently
from
7327949 to
00baaab
Compare
|
added a small commit that should help some CI pass - only yield in common show handler when the calling path supports yield/resume. Also cleaned up a style warning. |
mjstapp
force-pushed
the
vty_show_resume
branch
from
00baaab to
a4dbea6
Compare
|
rebase to newer master |
| &vty->yield_resume.t_resume); | ||
|
|
||
| /* Ensure reading new input is disabled */ | ||
| event_cancel(&vty->t_read); |
There was a problem hiding this comment.
If we stop the read action at this point, how can we respond to certain control commands, such as using Ctrl+C to terminate output?
Can we control vtysh so that it does not respond to any command line input, except for control commands, until it receives the finish response from the previous command?
There was a problem hiding this comment.
correct - there isn't a way yet to interrupt one of these long-running commands. I'm hoping we can get some benefits from this first round of changes, ensure that they're working correctly, and then that's a follow-on that I'm hoping to do.
mjstapp
force-pushed
the
vty_show_resume
branch
from
a4dbea6 to
579c85a
Compare
|
Updated and rebased; start another CI cycle, and open for review now |
mjstapp
changed the title
mjstapp
force-pushed
the
vty_show_resume
branch
from
579c85a to
16aeda8
Compare
|
pushed some fixes |
mjstapp
force-pushed
the
vty_show_resume
branch
from
16aeda8 to
4582565
Compare
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
mjstapp
force-pushed
the
vty_show_resume
branch
from
4582565 to
6498a1c
Compare
mjstapp
force-pushed
the
vty_show_resume
branch
from
6498a1c to
002cb3b
Compare
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
mjstapp
force-pushed
the
vty_show_resume
branch
from
cb983d8 to
1abc68e
Compare
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
mjstapp
force-pushed
the
vty_show_resume
branch
2 times, most recently
from
d08581d to
77cd1e2
Compare
mjstapp
force-pushed
the
vty_show_resume
branch
from
77cd1e2 to
880d5cd
Compare
|
rebase to use new srcdest table api, and newer master |
mjstapp
force-pushed
the
vty_show_resume
branch
from
880d5cd to
8997b21
Compare
|
fixed a one-liner, let's try CI again... |
|
the only question I think is open here is whether |
|
yes, still looking at that, and doing some additional testing around vrfs and route-tables
|
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
mjstapp
force-pushed
the
vty_show_resume
branch
2 times, most recently
from
2e4bddb to
e5484a4
Compare
|
clearing conflicts, again, sigh |
|
really just waiting on deciding if this should be configurable, I think (?) ... I don't know if @choppsv1 still has comments open here |
I don't have any comments. I've done this generically for YANG modeled data (which does include routes), but haven't opened a PR for it yet, and regardless that shouldn't block this work. |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Support YIELD operation for long-running cli operations. A new api allows a daemon to supply a callback and context pointer; the vty lib will reschedule and call through to the daemon allowing it to resume a long-running show operation. The vty lib avoids new reads until the daemon is done. Signed-off-by: Mark Stapp <mjs@cisco.com>
Yield and resume long-running show operation using the vty yield feature; capture "resume" context as we iterate through route tables. Signed-off-by: Mark Stapp <mjs@cisco.com>
Ensure the common show code can tell when it's being used in a path that supports yield/resume; only yield when that's happening. Signed-off-by: Mark Stapp <mjs@cisco.com>
4 participants
This is some preliminary work towards support for yield/resume during long-running show commands - such as "show ip route" or the high-scale bgp show commands. I understand there's been some interest in that area that may appear in a PR ... soon, and I wanted to offer some of the vty library ideas in case that aspect is useful.
This PR adds library support, and converts the "show ip[X] route" commands in zebra so that they can use the yield/resume features.
The main zebra change is converting the series of apis that locates vrfs and route-tables and then iterates for the all-vrfs and all-tables forms of the clis. These apis now use a common show "context" struct that captures the incoming cli parameters, such as afi/safi and various filters. The context struct also includes fields to capture the last-processed key data from zebra's route-nodes and route-entries; that data is then used after yielding when resuming iteration.
A question for reviewers would be: which error cases should be treated as failure, and which should be handled gracefully? For example, if a vrf or route-table is deleted before a show iteration resumes, should the show command just fail and stop? or should it terminate data from the deleted vrf (for json particularly) and move on to the next object in the iteration?