Config Format Detection about napalm-junos HOT 2 CLOSED

Hi @zachmoody, thanks for your thoughts!

E.g. deactivating or deleting a bit of config w/o hacking in a superfluous command that starts with set first.
I'd be happy to submit a PR that made _detect_config_format more robust.

You are correct. I have also thought about that, although I didn't raise and issue or submitted a PR to enhance it. If you are happy to help, please go ahead.

Also was curious what you all think about explicitly exposing a format argument (that defaults to text) to the relevant methods that's passed to pyEZ's load()? Maybe in addition to a _detect_config_format refactor?

This is one of the subjects long debated internally. For the time being we have agree on the solution above, but if you have a specific use case for this we'd like to hear more.

Cheers,
-Mircea

from napalm-junos.

Awesome, I'll get started on a PR then. Out of the available "verbs" I thought these might make sense to include for completeness:

• activate
• annotate
• copy
• deactivate
• delete
• insert
• protect
• rename
• unprotect

Any others you all might want to add or drop from that list?

This is one of the subjects long debated internally. For the time being we have agree on the solution above, but if you have a specific use case for this we'd like to hear more.

Sure, so for everything related to loading a config we've encountered text format has worked well, save this one scenario. When we're looking to deactivate a stanza w/o building out the child elements; junos will throw a warning (at least in vSRX) which is fatal to pyEZ. E.g. if we have:

system {
    login {
        user bob {
            uid 2000;
            class admin;
        }
    }
}

and I want to deactivate bob w/o knowing his uid or class. The docs say that I can just do this:

system {
    login {
        inactive:
        user bob;
    }
}

Which works, but not without a warning (warning: statement has no contents; ignored). So it seems we're relegated to using set syntax for this this, which is fine.

The whole idea of passing a format named arg was just coming from a place of being (maybe overly) explicit. I think a refactored _detect_config_format will work just as well, assuming no new actions come out. :)

While we're on the topic, does the same stance keep get_config() from having a format arg as well?

from napalm-junos.