[cmaster-next] VTYSH behavior change and extract.pl elimination

[Donald Sharp]

Even though I asked Quentin to send this email, I'd like to put a +1
on it.  Let's think about modifying vtysh to ask running daemons what
their command set is.

donald

On Thu, Dec 8, 2016 at 8:32 PM, Quentin Young
<qlyoung at cumulusnetworks.com> wrote:
> Folks,
>
> I've been doing some hacking on vtysh in an effort to clean it up and fix
> some obscure bugs and less-than-sane interactions with daemons. Initially my
> efforts were focused on getting vtysh to automatically update its vty->node
> when a daemon node changes instead of needing a manual DEFUN override for
> every such daemon command. I have this working; after executing a command,
> the daemon side of the vty returns what node it is in in addition to the
> command status code and any output, which vtysh uses to update its own node.
> This in contrast to attempting to synchronize shared state over the life of
> a vtysh session without actually communicating said state.
>
> That said, I think vtysh could use some more work on a slightly larger
> scale. In my opinion extract.pl is fragile and error-prone. For example, any
> command definitions outside the source files it looks in (such as the
> default commands installed by lib/command.c) are not picked up and thus need
> to be manually replicated in vtysh. Additionally anytime new submodes are
> added, one has to remember to update extract.pl. And there are quite a few
> edge cases that vtysh has to handle that ain't pretty.
>
> I propose to change vtysh's behavior such that it no longer needs
> compile-time knowledge of daemon CLI. Instead it should ask each daemon for
> its CLI at runtime whenever needed, for example when a user types '?' or
> hits tab. This has several benefits:
>
> extract.pl can go away since vtysh no longer needs to know about daemon cli,
> and just implements CLI specific to itself
> vtysh binary becomes ~93% smaller
> problem of keeping vtysh in sync with daemons becomes trivial
> daemons gain the ability to choose what CLI they expose
> saves confusion caused by vtysh silently accepting CLI for which the
> appropriate daemon is not running
> CLI for daemons which are not running is not shown
>
> How to deal with this last point is probably the most important thing to
> discuss because that is the change the user will see. Since vtysh will no
> longer have foreknowledge of all CLI, it won't be able to distinguish
> between a bogus command and a command that's valid but for which the daemon
> is not running. I think this is an easy one to solve; we can just change
>
> % Unknown command
>
> to something like, for example,
>
> % Unknown command (or daemon not running).
>
> As mentioned above I see this as a benefit since it will prevent users
> getting confused by vtysh silently accepting CLI for stopped daemons.
>
> Feedback welcome.
>
> Quentin
>
> _______________________________________________
> cmaster-next mailing list
> cmaster-next at lists.nox.tf
> https://lists.nox.tf/listinfo/cmaster-next
>