feature proposal - implement line-filter callbacks in parse_indented_config

[p-sherratt]

In the main loop in parse_indented_config, allow for a filter callback argument to influence the text processing.

The callback should return the new config 'line', or None. If None, the processing loop would re-continue.

We can then implement a separate filter_ios for example to:

• Process multi-line banners
• Decrypt type-7 passwords
• Strip comments

..and wrap this up as parse_ios_config or similar for other vendors where we can implement some filtering niceties.

[p-sherratt]

e.g. develop...p-sherratt:develop

[dbarrosop]

Hi,
thanks for the idea, quick question:

Stripping of comments within IOSParser implementation, instead of text_tree.py

What does that mean exactly?

Processing multi-line banners
Decryption of type-7 passwords

I think we should certainly support multi-line banners but I don't think we should be doing any processing of data. If something needs to be decrypted, for instance, it should be done by the parser, this is just a dumb utility to turn a blob of text into a tree-like structure.

Regards

[p-sherratt]

What does that mean exactly?

I've updated my earlier comment to clarify. I'd referenced a name from my own tooling rather than yangify. eek!

Processing multi-line banners
Decryption of type-7 passwords

I think we should certainly support multi-line banners but I don't think we should be doing any processing of data.

Agree. I'd suggested the type-7 feature as a convenience but it's not really a requirement to parsing into the config tree and would really be the wrong place for it to happen.

So actually I feel the vendor-specific cases (basically any multi-line items/strings/comments lacking hierarchical structure) might be accommodated for better directly in the text_tree parser. But parse_indented_config would need to be passed or able to find the device type.

[dbarrosop]

Would you mind pasting here a few examples of multiline commands? The more you can paste the better and the more venndors covered as well. I think I have an idea that might solve this problem in a generic way but I'd like to test it against multiple examples.

[dgjustice]

@dbarrosop @p-sherratt Is this something we still need to look at implementing?

[dgjustice]

David's comments in DM

I think the “processors” should be as agnostic as possible so they can be reused, magic should happen in the parsers/translators as they are OS specific
not sure if work is needed to support multiline commands though, if they are indented it should work out of the box

[p-sherratt]

I can't give many examples unfortunately, to know whether it is worth supporting some general case of multi-line strings/comments with start & end delimiters.

IOS banners were just an annoying corner case and it needed some modification of the text_tree parser to make it work.