community.general/lib/ansible/modules/cloud/openstack
Lars Kellogg-Stedman b2e5c75131 server.security_groups is a list of dicts (#48798)
os_server was trying to access `[sg.name for sg in
server.security_groups]`, but the items in `server.security_groups`
are dictionaries, so that should be `sg['name']`.
2018-11-30 06:42:50 -05:00
..
README.md
__init__.py
_os_server_actions.py
os_auth.py
os_client_config.py
os_coe_cluster_template.py
os_flavor_facts.py
os_floating_ip.py
os_group.py
os_image.py
os_image_facts.py
os_ironic.py
os_ironic_inspect.py
os_ironic_node.py
os_keypair.py
os_keystone_domain.py Validate DOCUMENTATION.author (#48993) 2018-11-21 17:29:29 +00:00
os_keystone_domain_facts.py
os_keystone_endpoint.py E325 Removal - Part II (#49196) 2018-11-28 13:55:52 +05:30
os_keystone_role.py
os_keystone_service.py
os_listener.py
os_loadbalancer.py
os_member.py
os_network.py
os_networks_facts.py
os_nova_flavor.py
os_nova_host_aggregate.py
os_object.py
os_pool.py
os_port.py E325 Removal - Part II (#49196) 2018-11-28 13:55:52 +05:30
os_port_facts.py
os_project.py
os_project_access.py
os_project_facts.py
os_quota.py
os_recordset.py fixed parsing issue with openstacksdk and idempotent checking issues (#44928) 2018-11-28 12:13:50 -05:00
os_router.py Add filters to os_router and os_subnet Fixes #37921 (#47220) 2018-11-24 08:07:37 -05:00
os_security_group.py
os_security_group_rule.py
os_server.py server.security_groups is a list of dicts (#48798) 2018-11-30 06:42:50 -05:00
os_server_action.py
os_server_facts.py
os_server_group.py
os_server_metadata.py
os_server_volume.py
os_stack.py
os_subnet.py Add filters to os_router and os_subnet Fixes #37921 (#47220) 2018-11-24 08:07:37 -05:00
os_subnets_facts.py
os_user.py
os_user_facts.py
os_user_group.py
os_user_role.py
os_volume.py
os_volume_snapshot.py
os_zone.py

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

Testing