Start using this to construct shade OpenStack Cloud objects in a
consistent manner. This will let us centralize things like dealing with
password arguments and whatnot. It also allows us to introduce the
ability to pass a fully formed config dict directly to the module.
Migrate all OpenStack modules to use openstack_cloud_from_module.
Have it return the shade library since it's responsible for
importing shade and shade is needed for the exceptions.
Only pull specific OpenStack arguments for the constructor
Rather than passing **module.params to the shade constructor, pull out
only the values that make sense. This should prevent the issues with
module parameters stepping on shade parameters.
Replace module.params.pop with module.params.get
We don't need to pop these anymore since the shade constructor is now
using opt-in values.
Using real urls is ungood. Use example.com domains. Also, get rid of the
antiquated port numbers.
Changes to the metadata format were approved here:
https://github.com/ansible/proposals/issues/54
* Update documentation to the new metadata format
* Changes to metadata-tool to account for new metadata
* Add GPL license header
* Add upgrade subcommand to upgrade metadata version
* Change default metadata to the new format
* Fix exclusion of non-modules from the metadata report
* Fix ansible-doc for new module metadata
* Exclude metadata version from ansible-doc output
* Fix website docs generation for the new metadata
* Update metadata schema in valiate-modules test
* Update the metadata in all modules to the new version
* fix module doc fields
* More module docs corrections
* More module docs corrections
* More module docs corrections
* More module docs corrections
* correct aliases
* Review comments
* Must quote ':'
* More authors
* Use suboptions:
* restore type: bool
* type should be in the same place
* More tidyups
* authors
* Use suboptions
* revert
* remove duplicate author
* More issues post rebase
* Move availability_zone docs to each OpenStack module
This argument is in the central list for hysterical raisins (mostly me
being a doofus) but is used in almost none of them. Document it
explicitly in each module to stop the confusion.
* Fix two docs formatting bugs
* Update validate-modules
* Validates ANSIBLE_METADATA
* Ensures imports happen after documentation vars
* Some pep8 cleanup
* Clean up some left over unneeded code
* Update modules for new module guidelines and validate-modules checks
* Update imports for ec2_vpc_route_table and ec2_vpc_nat_gateway
The password param conflicts with os-client-config's password grabbing.
The rest of the params really probably should also be popped - but
keeping this just to password for now. Will follow up with a change that
does an audit of all the os_ modules
This patch was previously contributed by @emonty to the former
ansible-modules-core repo however since the merge, it was closed
and not completed. This patch includes the necessary changes cleaned
up to work with the latest release of Ansible. This has been
tested to work internally
I broke backwards compat with the addition to define when a password
should be updated. It was requiring that a password value be passed when
deleting a user, which seems silly.
This moves the argument logic out of the argument spec and into when it
would be needed, when state is present.
There is a desire to not have this module always result in a change if a
password argument is supplied. The OpenStack API does not return a
password back when we get a user, so we've been assuming that if a
password argument was supplied, we should attempt to change the password
(even if nothing else is changing), and that results in a "changed"
state. Now we will only send along a password change attempt if the user
wants one (the default to match history).
Fixes#5217
The keys returned by user objects for default domain and
default project are respectively default_domain_id and
default_project_id.
We need to gather those IDs in case the user passed names, so we
can then compare with the user object on the needs_update helper
function.
The default_project is checked at the beginning of the module.
This raises an exception if the project passed does not exist.
This logic only makes sense on resource creation, if a user
puts state=absent the module fails, even though the default
project is not relevant
The exception message, when shade fails, will contain much more
specific information about the failure if the exception is treated
as a string. The 'message' attribute alone is usually not helpful.
Monty Taylor
Toshio Kuratomi
Abhijeet Kasurde
Guillaume Coré
Andrea Tartaglia
John R Barker
Brian Coca
Matt Martz
Mohammed Naser
Paulo Matias
Jesse Keating
Ricardo Carrillo Cruz
Arun prasath
Brian Coca
David Shrewsbury