409d95d67e
This is a refactoring of the existing GCE utility module to support other projects on Google Cloud Platform. The previous gce.py module was hard-coded specifically for GCE, and attempting to use it with other projects in GCP failed. See https://github.com/ansible/ansible/pull/15918#issuecomment-220165913 for more detail. This has also been an issue for others in the past, although they've handled it by simply duplicating some of the logic of gce.py in their own modules. - The existing gce.py module was renamed to gcp.py, and modified to remove any imports or other code that refers to libcloud.compute or GCE (the GCE_* params were retained for compatibility). I also renamed the gce_connect function to gcp_connect, and modified the function signature to make supplying a provider, driver, and agent information mandatory. - A new gce.py module was created to handle connectivity to GCE. It imports the appropriate libcloud.compute providers and drivers, and then passes them on to gcp_connect in gcp.py. The constants and function signatures are the same as the old gce.py, so compatibility with existing modules is retained. - A new gcdns.py module was created to support PR ansible/ansible-modules-extras#2252 for two new Google Cloud DNS modules, and to demonstrate support for a non-GCE Google Cloud service. It follows the same basic structure as the new gce.py module, but imports from libcloud.dns instead. |
||
|---|---|---|
| .. | ||
| code-smell | ||
| integration | ||
| samples | ||
| units | ||
| utils | ||
| README.md | ||
Ansible Test System
Folders
unit
Unit tests that test small pieces of code not suited for the integration test layer, usually very API based, and should leverage mock interfaces rather than producing side effects.
Playbook engine code is better suited for integration tests.
Requirements: sudo pip install paramiko PyYAML jinja2 httplib2 passlib nose mock
integration
Integration test layer, constructed using playbooks.
Some tests may require cloud credentials, others will not, and destructive tests are separated from non-destructive so a subset can be run on development machines.
learn more
hop into a subdirectory and see the associated README.md for more info.