Banner

[arulkumar9690]

SUMMARY
Banner - Module implementation

GitHub Issues
N/A.

ISSUE TYPE
Feature Pull Request

COMPONENT NAME
sonic_banner

ADDITIONAL INFORMATION

OUTPUT

Regression test HTML report:
Banner.pdf

Checklist:
[yes ] I have performed a self-review of my own code to ensure there are no formatting, linting, or security issues
[ yes] I have verified that new and existing unit tests pass locally with my changes
[ yes] I have not allowed coverage numbers to degenerate
[ yes] I have maintained at least 90% code coverage
[ yes] I have commented my code, particularly in hard-to-understand areas
[ yes] I have made corresponding changes to the documentation
[ yes] I have added tests that prove my fix is effective or that my feature works
[ yes] I have maintained backward compatibility or have provided any relevant "breaking_changes" descriptions in a "fragment" file in the "changelogs/fragments" directory of this repository.
[ yes] I have provided a summary for this PR in valid "fragment" file format in the "changelogs/fragments" directory of this repository branch. Reference : Ansible Change Log Document

How Has This Been Tested?
Ran lots of unit testing and regression testing on some SONIC target systems.

[kerry-meyer]

It would be better to add the relevant code sections from the following PRs to the already existing "sonic_system" resource module. The recent PRs for "auditd" (#405) and "Ansible support for versatile hash feature" (#401) can be used as examples for doing this. Adding the entire set of supporting base files and the required accompanying minimum code for each of these small sets of additional options creates a significant amount of additional lines of code and files to the repo and would require an undesirable added amount of maintenance overhead time and resources.

Each of the new options can be added to the "sonic_system" module/argspec as a new dict named based on the supported feature (e.g. pw_options and banner), or just a single new option (exec_timeout):

#427
#426
#425

Please refactor these PRs as described above into one new PR unless there is some reason that these should all be separate resource modules. (If you feel that they should be separate modules, please explain the reasoning for this.)