-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Password Complexity #426
base: main
Are you sure you want to change the base?
Password Complexity #426
Conversation
…0/dellemc.enterprise_sonic into Password_Complexity
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): 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.) |
SUMMARY
Password Complexity - Module implementation
GitHub Issues
N/A.
ISSUE TYPE
Feature Pull Request
COMPONENT NAME
sonic_password_complexity
ADDITIONAL INFORMATION
OUTPUT
Regression test HTML report:
Password_Complexity.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.