Change Details

This is related to two features I was talking about earlier, one of which is not in VyOS 1.x because it's blocked by issues with handling defaults, and the other is entirely new. The first feature is "deactivate/activate". JunOS has this. If you do "deactivate interfaces tunnel tun0", the node can be viewed in the show output, but is not used for generating any actual config. "activate interfaces tunnel tun0" brings it back to life. The second feature is "ephemeral nodes". Those are temporary nodes that do not appear in the saved config. Typical situations when they can be handy is 1) VRRP transition scripts or similar adds a node that should only exist on the active router 2) an IPS, fail2ban-like tool, or an administrator adds something to solve a temporary problem. If someone saves the config, in the first case routers may end up in a conflicting state upon reboot; in the second case the config get filled with nodes that outlived its usefulness. Marking such nodes ephemeral can solve the problem. We are still to decide how it should look in the config, but first we need to add the plumbing. I lump those features together here because the code is virtually identical, the only difference is in field names. The steps required for minimal support before we can do anything else: * Add "inactive: bool" and "ephemeral: bool" fields to the config_node_data record type * Add those fields to the default_data record, default to "false" * Add the following function type signatures to the Config_tree module interface (src/config_tree.mli): ``` val set_inactive : t -> string list -> bool -> t val is_inactive : t -> string list -> bool val set_ephemeral : t -> string list -> bool -> t val is_ephemeral : t -> string list -> bool ``` * Add implementations to the Config_tree module (src/config_tree.ml) * Add unit tests for them to test/config_tree_test.ml If you want to take it up, you can use the code for T224 as example.

This is related to two features I was talking about earlier, one of which is not in VyOS 1.x because it's blocked by issues with handling defaults, and the other is entirely new. The first feature is "deactivate/activate". JunOS has this. If you do "deactivate interfaces tunnel tun0", the node can be viewed in the show output, but is not used for generating any actual config. "activate interfaces tunnel tun0" brings it back to life. The second feature is "ephemeral nodes". Those are temporary nodes that do not appear in the saved config. Typical situations when they can be handy is 1) VRRP transition scripts or similar adds a node that should only exist on the active router 2) an IPS, fail2ban-like tool, or an administrator adds something to solve a temporary problem. If someone saves the config, in the first case routers may end up in a conflicting state upon reboot; in the second case the config get filled with nodes that outlived its usefulness. Marking such nodes ephemeral can solve the problem. We are still to decide how it should look in the config, but first we need to add the plumbing. I lump those features together here because the code is virtually identical, the only difference is in field names. The steps required for minimal support before we can do anything else: * Add "inactive: bool" and "ephemeral: bool" fields to the config_node_data record type in src/config_tree.ml and update it in the module interface (src/config_tree.mli) * Add those fields to the default_data record, default to "false" * Add the following function type signatures to the Config_tree module interface (src/config_tree.mli): ``` val set_inactive : t -> string list -> bool -> t val is_inactive : t -> string list -> bool val set_ephemeral : t -> string list -> bool -> t val is_ephemeral : t -> string list -> bool ``` * Add implementations to the Config_tree module (src/config_tree.ml) * Add unit tests for them to test/config_tree_test.ml If you want to take it up, you can use the code for T224 as example.

This is related to two features I was talking about earlier, one of which is not in VyOS 1.x because it's blocked by issues with handling defaults, and the other is entirely new. The first feature is "deactivate/activate". JunOS has this. If you do "deactivate interfaces tunnel tun0", the node can be viewed in the show output, but is not used for generating any actual config. "activate interfaces tunnel tun0" brings it back to life. The second feature is "ephemeral nodes". Those are temporary nodes that do not appear in the saved config. Typical situations when they can be handy is 1) VRRP transition scripts or similar adds a node that should only exist on the active router 2) an IPS, fail2ban-like tool, or an administrator adds something to solve a temporary problem. If someone saves the config, in the first case routers may end up in a conflicting state upon reboot; in the second case the config get filled with nodes that outlived its usefulness. Marking such nodes ephemeral can solve the problem. We are still to decide how it should look in the config, but first we need to add the plumbing. I lump those features together here because the code is virtually identical, the only difference is in field names. The steps required for minimal support before we can do anything else: * Add "inactive: bool" and "ephemeral: bool" fields to the config_node_data record type in src/config_tree.ml and update it in the module interface (src/config_tree.mli) * Add those fields to the default_data record, default to "false" * Add the following function type signatures to the Config_tree module interface (src/config_tree.mli): ``` val set_inactive : t -> string list -> bool -> t val is_inactive : t -> string list -> bool val set_ephemeral : t -> string list -> bool -> t val is_ephemeral : t -> string list -> bool ``` * Add implementations to the Config_tree module (src/config_tree.ml) * Add unit tests for them to test/config_tree_test.ml If you want to take it up, you can use the code for T224 as example.