Network config module warning message behaviour

[ganeshrn]

In the Jan-2021 release of ansible.netcommon collection and a couple of platform collections, the <platform>_config and cli_config modules started showing a warning to users to indicate the config diff and idempotent behaviour of the module as below.

[WARNING]: To ensure idempotency and correct diff the input configuration lines
should be similar to how they appear if present in the running configuration on
device including the indentation

The warning is currently displayed on every task run even if there is no config diff, while this behaviour might be helpful to new users of the module it might be noise for users who already understand how the module works.

To better handle the warning message and inform the users about the module behaviour couple of options were suggested on this thread which I have summarized below:

• Add a configurable option to enable helpful warning and tips for new users. By default, the value is set to False

  [defaults]
  tutor_mode = True
  

• Add warning only if diff exists.

• Add the warning message only if the verbose flag is added while running the playbook -vvvv (3v's) and above.

• Add logic to into GitHub Actions to diagnose and provide the guidance there if it is about issues coming into GH

• Remove console warning completely as it might raise more questions

• Add warning in the task response as the value of warning key if diff exists

Please suggest which option is more suitable to handle the warning message in a better way. Any better ideas apart from the one not listed above are also welcomed :-)

[jvanderaa]

The tough thing if I remember my early years of Ansible, I didn't know enough to run with any v's. So I'm not sure that will help.

If the problem is with the issues being opened on GH about it not being idempotent, then I think this should be addressed with GH not within Ansible itself.

MyVote: 4

Ideally I would like to see the tutor_mode idea added. Not sure if that is something that can be built in without a terrible amount of work.

[ganeshrn]

The tough thing if I remember my early years of Ansible, I didn't know enough to run with any v's. So I'm not sure that will help.

Won't that be the case with tutor_mode set default to False?

For option-4 I am not sure how it can be implemented also that won't help the Redhat support cases as those are not directly tracked via Github.

[jvanderaa]

Got it. Just needed the context around what "issues" were. If they were GH issues, then that can be triaged with a bit of regex inside of GH Actions. No issue from me to remove that as an option.

[jvanderaa]

With that I also would put my support behind #3.

[jvanderaa]

Tagging a few more people involved in the Twitter discussion and others that may have some interest. @nickrusso42518 @ktbyers @itdependsnetworks @dgarros

[nickrusso42518]

Option 4 sounds cool but seems difficult to implement, and I'm almost certain some false negatives would still make it past whatever logic is added. Since the raising of issues requires -vvvv debugging anyway (per the debugging template), I'm including to vote for Option 3 as a short-term solution. I like Option 1 as a long-term solution because unlike -vvvv, it wouldn't dump a thousand lines of detailed output that most newcomers won't read.

I dislike the idea of printing a warning if diff exists because a legitimate, correctly-implemented change will raise the warning. This will raise more questions than it answers and cause engineers to second-guess their work. This is what happened to me and how this whole discussion started.

[ganeshrn]

Agreed, adding a warning in verbose mode will be relatively easy without much change sounds like a good short-term solution. I like option-1 but it is an ansible wide change and it might require updates in ansible-base. IMO having a proposal created here will help get more traction for this idea.

[itdependsnetworks]

1-3 seems viable. I am not sure how 4 would work though.

[ganeshrn]

I am more inclined towards option 3 as a short term solution as discussed in the above comments.

[ganeshrn]

There is a known issue for verbose logging from module side ansible-collections/ansible.netcommon#224

Hence the PR ansible-collections/ansible.netcommon#225 moves the warning message in the warnings key of module response if changed is True.