50 lines
2.3 KiB
Markdown
50 lines
2.3 KiB
Markdown
|
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.
|
||
|
|
|
||
|
|
Naming
|
||
|
|
------
|
||
|
|
|
||
|
|
* All modules should start with os_
|
||
|
|
* If the module is one that a cloud consumer would expect to use, it should be
|
||
|
|
named after the logical resource it manages. Thus, os\_server not os\_nova.
|
||
|
|
The reasoning for this is that there are more than one resource that are
|
||
|
|
managed by more than one service and which one manages it is a deployment
|
||
|
|
detail. A good example of this are floating IPs, which can come from either
|
||
|
|
Nova or Neutron, but which one they come from is immaterial to an end user.
|
||
|
|
* If the module is one that a cloud admin would expect to use, it should be
|
||
|
|
be named with the service and the resouce, such as os\_keystone\_domain.
|
||
|
|
* If the module is one that a cloud admin and a cloud consumer could both use,
|
||
|
|
the cloud consumer rules apply.
|
||
|
|
|
||
|
|
Interoperability
|
||
|
|
----------------
|
||
|
|
|
||
|
|
* 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.
|
||
|
|
|
||
|
|
Libraries
|
||
|
|
---------
|
||
|
|
|
||
|
|
* All modules should use openstack\_full\_argument\_spec to pick up the
|
||
|
|
standard input such as auth and ssl support.
|
||
|
|
* All modules should extends\_documentation\_fragment: openstack to go along
|
||
|
|
with openstack\_full\_argument\_spec.
|
||
|
|
* All complex cloud interaction or interoperability code should be housed in
|
||
|
|
the [shade](http://git.openstack.org/cgit/openstack-infra/shade) library.
|
||
|
|
* All OpenStack API interactions should happen via shade 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. The
|
||
|
|
python-openstacksdk is the future there, and shade will migrate to it when
|
||
|
|
its ready in a manner that is not noticable to ansible users.
|