Hello Ondrej, I see your point. I do think every configuration option should be displayed in the show commands though, it makes it easier to find their value instead of searching the configuration file and documentation for default values. I think it can also help to spot bugs if somehow a runtime value does not match the value from the configuration file (should be pretty rare, but maybe it can happen it something is missing on the reconfiguration code?). But yes I agree it is cumbersome to implement manually given the number of configuration options.
For the gw mode specifically, I added it because its default value depends on an other configuration variable (multihop), so it may not be obvious from the configuration file what value it actually is if one forgot about that. Thanks for the feedback. -- Sébastien ________________________________________ De : Ondrej Zajicek <[email protected]> Envoyé : lundi 8 septembre 2025 16:08 À : Sébastien PARISOT Cc : [email protected]; David Petera Objet : Re: Display BGP gateway mode in show protocol output On Mon, Sep 08, 2025 at 09:17:17AM +0000, Sébastien PARISOT wrote: > Hello David, > > To be honest I expected this kind of answer for the first 2 patches :) > I thought this one would be ok as it only adds a new field/line in the > output and do not touch the existing output, but sure I understand. > Relying on text output is always fragile and any change is risky. Hello You are right, this is more an answer for the first 2 patches. We are generally okay with adding a new line to 'show protocols all' from the compatibility point of view. But our rule of thumb here is that we do not want to add a line here that is purely configuration data without a good reason, as this command should mainly show runtime data. People could argue that half of BGP configuration options are important enough to be shown here and we would like to avoid adding them all, especially when these command outputs are manually implemented. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: [email protected]) "To err is human -- to blame it on a computer is even more so."
