cmueller/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
ansible/cloud/openstack
History
Timothy R. Chavez b9fe8166fd Get new server object after adding floating IP 
We need a new server object once we add the floating ip, otherwise we
will be operating with the older server object pre-floating-ip
assignment.
2015-12-10 13:01:57 -06:00
..
__init__.py added __init__.py to new cloud subcategories so builds work again 2014-11-05 11:07:19 -05:00
_glance_image.py Add OpenStack Image module 2015-06-05 15:58:10 -04:00
_keystone_user.py @lorin stepping down as maintainer 2015-10-28 14:38:11 -04:00
_nova_compute.py The nova_compute module create a list of un-use floating ip by value of fixed_ip. 2015-07-14 13:48:42 +09:00
_nova_keypair.py Add OpenStack Keypair module 2015-06-18 08:01:24 -04:00
_quantum_floating_ip.py Add OpenStack Floating IP Module 2015-06-16 15:50:31 -07:00
_quantum_floating_ip_associate.py Add OpenStack Floating IP Module 2015-06-16 15:50:31 -07:00
_quantum_network.py fixed quantum_ modules to work with minimum access rights if greater access rights are not needed 2015-11-26 15:34:47 +02:00
_quantum_router.py fixed quantum_ modules to work with minimum access rights if greater access rights are not needed 2015-11-26 15:34:47 +02:00
_quantum_router_gateway.py Deprecate older router modules. 2015-10-02 09:24:03 -04:00
_quantum_router_interface.py fixed quantum_ modules to work with minimum access rights if greater access rights are not needed 2015-11-26 15:34:47 +02:00
_quantum_subnet.py fixed quantum_ modules to work with minimum access rights if greater access rights are not needed 2015-11-26 15:34:47 +02:00
os_auth.py Updating cloud modules with proper github author information 2015-06-15 14:41:22 -04:00
os_client_config.py removed hyphens in module name in examples 2015-08-28 08:46:45 -04:00
os_floating_ip.py Get new server object after adding floating IP 2015-12-10 13:01:57 -06:00
os_image.py Bug fix for os_image and min_disk/min_ram 2015-11-23 11:29:00 -05:00
os_image_facts.py doc fixes 2015-10-09 18:36:58 -04:00
os_ironic.py minor doc fixes 2015-06-16 18:56:24 -04:00
os_ironic_node.py minor doc fixes 2015-06-16 18:56:24 -04:00
os_keypair.py make os_keypair return a top level 'id' key 2015-10-22 13:59:45 -04:00
os_network.py make os_network correctly report changed status 2015-10-22 13:38:32 -04:00
os_networks_facts.py doc fixes 2015-10-09 18:36:58 -04:00
os_nova_flavor.py make os_flavor return a top-level 'id' key 2015-10-22 13:56:56 -04:00
os_object.py Return resource objects from OpenStack modules 2015-06-17 05:24:08 -04:00
os_port.py allow os_port to accept a list of security groups 2015-10-23 09:44:07 -04:00
os_router.py make os_router return a top level 'id' key 2015-10-23 13:32:37 -04:00
os_security_group.py allow empty description attribute for os_security_group 2015-10-22 21:26:47 -04:00
os_security_group_rule.py checking remote_group_id while comparing os_security_group_rule 2015-08-04 12:52:56 +05:30
os_server.py allow os_server to accept a list of security groups 2015-10-22 22:53:05 -04:00
os_server_actions.py Adding start and stop actions to os_server_actions 2015-08-23 11:51:28 -07:00
os_server_facts.py os_server_facts returns facts about multiple servers 2015-10-28 13:18:54 -04:00
os_server_volume.py Updating cloud modules with proper github author information 2015-06-15 14:41:22 -04:00
os_subnet.py return information about created subnet 2015-10-22 13:27:17 -04:00
os_subnets_facts.py fixed results docs 2015-10-16 14:12:11 -04:00
os_user.py Clarify password requirement and add return docs. 2015-10-20 15:49:52 -04:00
os_user_group.py Fix os_user_group module 2015-11-18 15:03:07 -05:00
os_volume.py Return resource objects from OpenStack modules 2015-06-17 05:24:08 -04:00
README.md Return resource objects from OpenStack modules 2015-06-17 05:24:08 -04:00

README.md

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.

Interface

  • 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.

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 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.