Enhancement: commit configuration despite warnings "statement not found" are raised

[ymitsos]

ansible does not provide an efficient way to do selective committing of changes depending on the configuration available in the device. To address this issue and provided Juniper's configuration database architecture one may decide to delete a whole section of configuration and send it again to ensure consistency with the local repository.

For instance,

delete snmp
set snmp name example.com
...

Another example tackles the creation of a prefix list where order of statements is important and a new entry should be places somewhere but the end of a list.

If the aforementioned approach is adopted (firstly to delete sections and then build them again), there might be cases where warnings "statement not found" may be raised (ie during the initial provisioning when the respective configuration snippet is missing).

This enhancement proposes the implementation of a mechanism in the junos_install_config where users may decide to ignore such warnings and proceed with committing their configuration.

[ymitsos]

and the respective PR #168

[jeffbrl]

@ymitsos Thanks for writing the PR to address this issue.

I encountered this behavior while writing a playbook to deploy a new loopback firewall filter. Ideally, network operators would be able to generate an entire config and and deploy it using the overwrite parameter. A wholesale move to config management with ansible is too difficult for large networks. An iterative approach is needed. During this iterim period, using a set-style config with delete commands is needed.

I was able to work around this issue for my particular use case; however, it is very messy. For every delete line, I added a dummy set command to ensure the delete does not generate a warning.

[frederic-loui]

@ymitsos , Thanks for this PR. I second the fact that at some point the operator should have the choice to ignore specific task warning (and sometime not). Even if JUNOS is idempotent we need to make sure that the config subtree is not merged with other existing config. What would be great is to catch a message "Warning DELETE on non-existing configuration object"

[jeffbrl]

@stacywsmith Can this pull request be merged and marked in the docs as experimental? My customer found another use case for ignoring warnings. The "protect" keyword can be very useful in a lab environment for temporary configuration. Doing a "replace" action on a top level stanza currently causes a warning if that stanza has a protected section.

@ymitsos Can you please synch your fork to master? I couldn't figure out how to manually resolve the merge conflicts.

[jeffbrl]

Allow me to clarify my previous comments. I would like to see an option to ignore all warnings, not only "statement not found." I recognize the risk in encountering the ""error: too many errors; remaining input ignored" error. I am curious if there is a similar error in junos source code for attempting to replace too many protected stanzas. In the CLI, I successfully performed a 'replace' on the groups stanza with 100 protected groups. The action resulted in warnings but was successful. The protected groups were maintained.

[ymitsos]

@jeffbrl I just synced with master. The previous commit included two patches. The one we are addressing in this thread and another one allowing us to choose between "commit check" or "show | compare".

[jeffbrl]

Thanks, @ymitsos. People who want to ignore "statement not found" in the near term can use your fork without losing the fixes to the project since Sept 2016. For those who want an "ignore_warnings" flag to ignore all warnings, we'll have to wait until the core devs determine how they want to proceed.

[vnitinv]

@jeffbrl @ymitsos We have added ignore_warning feature in PyEZ. That will be extended to to Ansible so that code is generic. Please check this:
https://github.com/Juniper/py-junos-eznc/blob/67a563b63f8872390a6242a966e77a8252120415/lib/jnpr/junos/device.py#L651

[ymitsos]

Great, should we expect the patch to ansible-junos-stdlib from the maintainers or is a PR required to augment this feature?

[vnitinv]

@ymitsos We will do the required changes in few days.

[jeffbrl]

@vnitinv when do you expect to commit the changes?

[Milan-Benes]

@jeffbrl
Hello, can you please elaborate on:
"For every delete line, I added a dummy set command to ensure the delete does not generate a warning." ?
I'm trying to run delete switch-options voip interface ge-0/0/0.0 (which is nonexistent in the config) and I end up with the statement not found warning.

Thank you

[jeffbrl]

@Milan-Benes Sure.

Let's say that a router may or may not have a firewall filter defined. To avoid the "statement not found" error, define the filter in the most minimalist way before deleting it.

set firewall family inet filter MY_FILTER term DUMMY then accept
delete firewall family inet filter MY_FILTER

This is useful when working on networks that are not built from templates. These networks tend to be full of cruft and other forms of configuration drift. Getting such networks to a point that they can be templatized is very manual and tedious. This hack only fixes a subset of the problems though. We'll be in a better position once a real fix is delivered.