Network devices info new changes

[Priyadharshini16092002]

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Description

Code changes have been implemented in accordance with the new playbook discussed.
The update includes fixes for three identified bugs in the network_devices_info module.

Bug Fix:

1. [Network_device_info]The module's timeout, retry, and interval settings are not working.
2. [Network_device_info]Module fails to apply default timeout, retry and interval settings
3. [Network_device_info]The module does not properly support filtering by the parent 'site_hierarchy'.

Root Cause (if applicable):

1. When parent site hierarchy is provided, it does not retrieve devices from its corresponding child sites.
2. Default timeout of 120sec and retry mechanism is not working
3. The module fails to execute the retry mechanism when the retry count is set to a value greater than 1.

Fix Implemented: [Describe the fix applied]

1. Enhanced the device retrieval logic to ensure that when a parent site hierarchy is specified, all devices within its corresponding child sites are also included.
2. Corrected the default timeout, retry, and interval handling mechanisms to ensure that the default values are applied during execution when not specified.
3. Corrected the retry logic to ensure that the module correctly re-attempts API calls when the retry count is greater than one.

Enhancement: NA
Enhancement Description: NA
Impact Area: NA

Testing Done:

• Manual testing
• Unit tests
• Integration tests

UT - Yet to be updated

Test cases covered: [Mention test case IDs or brief points]

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• All the sanity checks have been completed and the sanity test cases have been executed

Ansible Best Practices

• Tasks are idempotent (can be run multiple times without changing state)
• Variables and secrets are handled securely (e.g., using ansible-vault or environment variables)
• Playbooks are modular and reusable
• Handlers are used for actions that need to run on change

Documentation

• All options and parameters are documented clearly.
• Examples are provided and tested.
• Notes and limitations are clearly stated.

Screenshots (if applicable)

Notes to Reviewers