OpenStack Ansible Modules¶
These are a set of modules for interacting with OpenStack as either an admin
or an end user. If the module does not begin with
os_, it’s either deprecated
or soon to be. This document serves as developer coding guidelines for
modules intended to be here.
- All module names should start with
- Name any module that a cloud consumer would expect to use after the logical resource it manages:
os_nova. This naming convention acknowledges that the end user does not care which service manages the resource - that is a deployment detail. For example cloud consumers may not know whether their floating IPs are managed by Nova or Neutron.
- Name any module that a cloud admin would expect to use with the service and the resource:
- If the module is one that a cloud admin and a cloud consumer could both use, the cloud consumer rules apply.
- If the resource being managed has an id, it should be returned.
- If the resource being managed has an associated object more complex than an id, it should also be returned.
- It should be assumed that the cloud consumer does not know a bazillion details about the deployment choices their cloud provider made, and a best effort should be made to present one sane interface to the Ansible user regardless of deployer insanity.
- All modules should work appropriately against all existing known public OpenStack clouds.
- It should be assumed that a user may have more than one cloud account that they wish to combine as part of a single Ansible-managed infrastructure.
- All modules should use
openstack_full_argument_specto pick up the standard input such as auth and ssl support.
- All modules should include
- All complex cloud interaction or interoperability code should be housed in the openstacksdk library.
- All OpenStack API interactions should happen via the openstacksdk and not via OpenStack Client libraries. The OpenStack Client libraries do no have end users as a primary audience, they are for intra-server communication.