Contributing and feature requests

Contributing: You know the drill. Fork it, branch it, change it, commit it, and pull-request it. We are passionate about improving this project, and glad to accept help to make it better.

NOTE: We reserve the right to reject changes that we feel do not fit the scope of this project. For feature additions, please open an issue to discuss your ideas before doing the work.

Feature Requests: If you have needs not being met by the current implementation, please let us know (via a new issue). This feedback is crucial for us to deliver a useful product. Do not assume we have already thought of everything, because we assure you that is not the case.

Naming Convention for OneView Resources

The following summarizes code structure and naming conventions for the OneView resources.

• Packages: The package is named according to the HPE OneView API Reference group, with all characters in lowercase, replacing spaces with underscores.
• Modules: The module is named according to the HPE OneView API Reference endpoint title, with all characters in lowercase, replacing spaces with underscores. For example: In the documentation we have FC Networks, so the module name will be fc_networks.
• Classes: We are using camel case to define the class name, for example: FcNetworks.
• OneViewClient properties: In the oneview_client, the property name follows exactly the module name, for example: fc_networks.
• Examples: The example is named with the same name of the resource module: fc_networks.
• Tests: The unit test folders follow the same structure of the resources. The name of the test modules should start with "test," for example: test_fc_networks.

Testing

When contributing code to this project, we require tests to accompany the code being delivered. That ensures a higher standing of quality, and also helps to avoid minor mistakes and future regressions.

When writing the unit tests, the standard approach we follow is to use the python library unittest.mock to patch all calls that would be made to a OneView appliance and return mocked values.

We have packaged everything required to verify if the code is passing the tests in a tox file. The tox call runs all unit tests against Python 2 and 3, runs a flake8 validation, and generates the test coverage report.

To run it, use the following command:

$ tox

You can also check out examples of tests for different resources in the tests folder.