With "extends_documentation_fragment: ['openstack.cloud.openstack']"
it is not necessary to list required Python libraries in section
'requirements' of DOCUMENTATION docstring in modules. Ansible will
merge requirements from doc fragments and DOCUMENTATION docstring
which previously resulted in duplicates such as in server module [0]:
* openstacksdk
* openstacksdk >= 0.36, < 0.99.0
* python >= 3.6
When removing the 'requirements' section from server module, then
Ansible will list openstacksdk once only:
* openstacksdk >= 0.36, < 0.99.0
* python >= 3.6
To see what documentation Ansible will produce for server module run:
ansible-doc --type module openstack.cloud.server
[0] https://docs.ansible.com/ansible/latest/collections/openstack/\
cloud/server_module.html
Change-Id: I727ed95ee480bb644b5a533f6a9526973677064c
Allow to update server attributes such as its description.
Changed default value of server attribute 'security_groups' from
['default'] to [] because the latter is the default in
python-openstackclient [1] and the former behavior causes issues
with existing servers [2]: Previously, when no 'security_groups'
parameter was given, the server module would change existing
servers to use the default security group, dropping all other
security groups assigned to the server.
Our (undocumented) guideline when writing modules is to only
add or change what has been requested by the user and to stick to
defaults from openstacksdk and python-openstackclient whenever
possible. Since we have to break backward compatibility with the
next release anyway, we take this opportunity to clean up this odd
behavior. Now, when no security groups are given, then security
groups of an existing server will not be touched.
Closes story #2007893 [2].
Note, Nova will create a server in the default security group,
if the security_groups parameter is omitted.
Dropped 'openstack' field from server module's results. This
variable expanded to additional server information which might
be useful for Ansible inventories and was filled from
openstacksdk's get_openstack_vars() function [3]. Variables in
this function can make additional cloud queries to retrieve
additional data, so calling this function can be expensive [4].
Users can use *_info modules to retrieve this data on-demand.
Dropped 'availabity_zone' attribute from generic OpenStackModule
arguments and inserted it into server and volume modules because
it is relevant to those two modules only. This is completes what
was started years ago [5] and is possible now since we have
breaking changes anyway.
Switched attribute name 'userdata' with its alias 'user_data' to
match openstacksdk's attribute names which are used e.g. in module
results. The previous attribute name 'userdata' is now used as an
alias and 'user_data' is used as the attribute name to keep backward
compatibility.
Wait for server to get into 'ACTIVE' state when creating a server
and attribute 'wait' has been set to true.
Sorted argument specs and documentation of the server module and
marked attributes which are not updatable. Changed unstable bash
script example in server module documentation.
Renamed server's module attribute 'delete_fip' to 'delete_ips' to
match openstacksdk and clarify that it includes all floating ip
addresses of the server.
Renamed server_info's module attribute 'server' to 'name' and added
the former as an alias to be consistent with other *_info modules.
Added RETURN fields documentation for the module results of both
server and server_info modules.
Added description and examples of how to use the 'filters' attribute
of the server_info module. Closes story #2007873 [6].
Removed 'openstack_' prefix from module results because the prefix is
not consistently used across modules, is more to type without any
benefit and removal of the prefix allows us to signal to users that
their code for handling module results has to be updated. Many modules
have different return values with openstacksdk >= 0.99.0 because it
consistently uses resource proxies now.
Added assertions for module results to catch future changes in the
openstacksdk and our Ansible modules.
Added integration tests to check the update mechanism of the server
module.
Fixed indentation in integration tests.
Ensure proper creation and deletion of resources such as networks,
subnets and servers in integration tests of server_action module.
Renamed ci/roles/server/defaults/main.yaml to main.yml, removing the
'a' in the file extension to be consistent with other filenames.
Dropped deprecated function openstack_find_nova_addresses() and
incorporated its code directly into the server module because it
is not used anywhere else.
[1] e49ad1795b/openstackclient/compute/v2/server.py (L1070)
[2] https://storyboard.openstack.org/#!/story/2007893
[3] 9e9fc98795/openstack/cloud/_compute.py (L1772)
[4] 9e9fc98795/openstack/cloud/meta.py (L482)
[5] 9bf33e56dd
[6] https://storyboard.openstack.org/#!/story/2007873
Signed-off-by: Jakob Meng <code@jakobmeng.de>
Change-Id: I2f955519a7e8c782b1dab8f94f7a019ed384b81d
With Ansible OpenStack collection 2.0.0 we break backward
compatibility to older releases, mainly due to breaking changes
coming with openstacksdk >=0.99.0. For example, results will change
for most Ansible modules in this collection.
We take this opportunity to drop the symbolic links with prefix
os_ in plugins/modules and the plugin routing in meta/runtime.yml.
This means users have to call modules of the Ansible OpenStack
collection using their FQCN (Fully Qualified Collection Name) such
as openstack.cloud.server. Short module names such as os_server
will now raise an Ansible error. This also decreases the likelihood
of incompatible Ansible code going undetected.
Symbolic links were introduced to keep our collection backward
compatible to user code which was written for old(er) Ansible releases
which did not have support for collections and where OpenStack modules
where named with a prefix os_ such as os_server which is nowadays
known and stored as openstack.cloud.server.
In Ansible aka ansible-base 2.10, a internal routing table
lib/ansible/config/ansible_builtin_runtime.yml [1] was introduced which
Ansible uses to resolve deprecated module names missing the FQCN (Fully
Qualified Collection Name). Additionally, collections can define their
own plugin routing table in meta/runtime.yml [2] which we did.
In ansible-base 2.10 and ansible-core 2.11 or later, if a user uses a
short module name and the collections keyword is not used, Ansible
will first look in the internal routing table, get an FQCN, and then
looks in the collection for that FQCN. If there is another routing
entry for that new name in that collection's meta/runtime.yml,
Ansible will continue with that redirect. If it does not find another
redirect, Ansible will look for the plugin itself, so it will not
find a redirect in the collection before looking at its internal
redirects. Except if the user uses a FQCN, then it looks directly in
that collection.
Ansible 2.9 and 2.8 do not have any notion of these redirects with a
plugin routing table, backward compatibility with deprecated os_*
module names is solely achieved with symbolic links. Ansible releases
older than 2.11 are EOL [3], so usage of os_* symlinks should reduce
soon.
[1] https://github.com/ansible/ansible/blob/devel/lib/ansible/config/ansible_builtin_runtime.yml
[2] https://github.com/openstack/ansible-collections-openstack/blob/master/meta/runtime.yml
[3] https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html
Change-Id: I28cc05c95419b72552899c926721eb87fb6f0868
We don't use github, so having @ mentions of specific humans is
not valuable. Also, we are a team and own the modules as a team,
so calling out individual authors is philosophically contrary.
We landed a patch upstream to special-case this author string.
Change-Id: I38b4e68f14bbba6e13e8a50e2b202874ab74e3bc
don't inherit OpenstackModule class from AnsibleModule class to
prevent occasional overriding Ansible methods or vars and failing
module.
Change-Id: Ic34fff0c938eb87cc0d2c5e98fbafed64bf349f6
This is separate from the previous patch - it's just the results
of running the script so we can review the two a little independently.
We should probably squash them.
Change-Id: I838f15cf4a32455a5be20033c8ddc27db6ca15c0
