mirror of
https://github.com/ansible-collections/community.general.git
synced 2025-04-24 19:31:26 -07:00
3e7b240696
* Add os_keystone_service_endpoint This patch adds a new Ansible module which allows a user to create an endpoint to a service with Keystone. Fixes #23909 * os_keystone_endpoint: Fix style and messages Fix comments, pep8, version, metadata, license header and imports according to the Contributing Modules Checklist Signed-off-by: Alberto Murillo <albertomurillosilva@gmail.com> * os_keystone_endpoint: Fix return values - Change type of 'endpoint' return value from dictionary to complex in order to get validate_module checks passed. - Remove 'id' from the return data since it is included inside the 'endpoint' value wich is already being returned. - Rename 'service' field to 'service_id' which is the correct name for the service id field returned in json. Signed-off-by: Alberto Murillo <albertomurillosilva@gmail.com> * os_keystone_endpoint: Update shade version Update minimum shade version to 1.11.0 Signed-off-by: Alberto Murillo <albertomurillosilva@gmail.com> * os_keystone_endpoint: Make region optional Signed-off-by: Alberto Murillo <albertomurillosilva@gmail.com> * os_keystone_endpoint: Validate service exists before using service.id Signed-off-by: Alberto Murillo <albertomurillosilva@gmail.com> * os_keystone_endpoint: Fix documentation for service to accept name or id Signed-off-by: Alberto Murillo <albertomurillosilva@gmail.com> * os_keystone_endpoint: Pass the full service object to create_endpoint() We already have the service object retrieved in code, by passing service.id to create_endpoint, the shade librarie queries the api again to get the full service object. By Passing the already rerieved service object to create_endpoint() we save one request to the API. Signed-off-by: Alberto Murillo <albertomurillosilva@gmail.com> * os_keystone_endpoint: Make type explicit in module arguments. Althoug type is default to str when not specified in module arguments this commit explicitly defines type='str' for better readability. Signed-off-by: Alberto Murillo <albertomurillosilva@gmail.com> |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| _os_server_actions.py | ||
| os_auth.py | ||
| os_client_config.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 | ||
| os_keystone_domain_facts.py | ||
| os_keystone_endpoint.py | ||
| os_keystone_role.py | ||
| os_keystone_service.py | ||
| os_network.py | ||
| os_networks_facts.py | ||
| os_nova_flavor.py | ||
| os_nova_host_aggregate.py | ||
| os_object.py | ||
| os_port.py | ||
| os_port_facts.py | ||
| os_project.py | ||
| os_project_facts.py | ||
| os_quota.py | ||
| os_recordset.py | ||
| os_router.py | ||
| os_security_group.py | ||
| os_security_group_rule.py | ||
| os_server.py | ||
| os_server_action.py | ||
| os_server_facts.py | ||
| os_server_group.py | ||
| os_server_volume.py | ||
| os_stack.py | ||
| os_subnet.py | ||
| os_subnets_facts.py | ||
| os_user.py | ||
| os_user_facts.py | ||
| os_user_group.py | ||
| os_user_role.py | ||
| os_volume.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 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 noticeable to ansible users.
Testing
- Integration testing is currently done in OpenStack's CI system in http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/tests/ansible
- Testing in shade produces an obvious chicken-and-egg scenario. Work is under way to trigger from and report on PRs directly.