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
This reapplies commit 4bfa135b20caeb6d6c2717049059ac52fd08e0e1 [1]
which got reverted in commit 1b59c19a24c55aa236d80552dcbf70c9c7b5088e
[2] due to issues in how TripleO Quickstart installed the Ansible
OpenStack collection. TripleO Quickstart has now been fixed and
will install code from our stable/1.0.0 branch instead of master for
all RDO branches which have openstacksdk <0.99.0 [3][4].
[1] 4bfa135b20
[2] 1b59c19a24
[3] https://review.opendev.org/c/openstack/tripleo-ci/+/849500
[4] https://review.opendev.org/c/openstack/tripleo-quickstart/+/849620/
Change-Id: I918d776c1560f03a4a84df371feb013d47043aa0
This reverts commit 4bfa135b20caeb6d6c2717049059ac52fd08e0e1 [1] because
it broke TripleO [2] and possibly other users which were using code from
master branch with incompatible SDK releases. We will reapply this
safety check later once dust has settled.
Ref.:
[1] 4bfa135b20
[2] https://bugs.launchpad.net/tripleo/+bug/1975646
Change-Id: I637f1b7c1b792adf6d3d17a27ccb42179f56a83b
Alongside OpenStack SDK 1.0.0 we will release a new collection version
2.0.0 which is compatible to OpenStack SDK 1.x.x series only. Code in
branch stable/1.0.0 will remain compatible to OpenStack SDK 0.x.x
series only. Release candidates for the first major release of
OpenStackSDK 1.x.x will be numbered using 0.99.x versions.
At Ansible OpenStack modules PTG on 2022-04-07 it was decided to raise
an error if one is using a incompatible releases of the OpenStack SDK
with our collection. We decided against showing warnings only because
they can be missed easily and functionality will be broken but
probably hardly detectable when using the wrong SDK.
This patch bumps the minimum required SDK versions to 0.99.0, so that
an error will be raised when users try to use our collection with an
incompatible SDK release, e.g. use code from our master branch with
a OpenStack SDK 0.x.x release.
Change-Id: I3974deabc516379745794806886352279dc4f4a7
Alongside OpenStack SDK 1.0.0 we will release a new collection version
2.0.0 which is compatible to OpenStack SDK 1.x.x series only. Code in
branch stable/1.0.0 will remain compatible to OpenStack SDK 0.x.x
series only.
At Ansible OpenStack modules PTG on 2022-04-07 it was decided to raise
an error if one is using a incompatible releases of the OpenStack SDK
with our collection. We decided against showing warnings only because
they can be missed easily and functionality will be broken but
probably hardly detectable when using the wrong SDK.
This patch implements the code to raise errors when users are trying
to use our collection with an incompatible SDK release, e.g. use code
from our stable/1.0.0 branch with a OpenStack SDK 1.x.x release.
It does not yet change the minimum and maximum required SDK versions
because OpenStack SDK 1.0.0 has not yet been released to PyPI and
SDK's master branch still does not return a 1.x.x version number.
Change-Id: I1052d21cf8f108dbc99619cd4c4072488645b855
Commit 879270aa47 [1] bumped the required minimum SDK release
but missed to update two locations in code and docs.
Ref.:
[1] 879270aa47
Change-Id: I725a26b07484619f6f2c460e974821f81d60b153
Change I51105f11565c5ff33b04add36259c8703af11240 moved validate_certs default from None to False.
This causes checks to fail in openstack_cloud_from_module as validate_certs is never None anymore.
This patch changes reverts the default back to None, and reflects this in the documentation.
Task: 41776
Story: 2008600
Change-Id: Ic79510f863cf3a39c3f5c6d99f61d335f92f9388
While it's currently possible to set min_ver and max_ver for specific
parameter, there are times when the whole module needs to specify a
minimum version:
- When the object isn't supported at all prior to a version
- When major features are missing from the SDK prior to a version
Change-Id: I94bbff7c54621e8a4786ebc7eb030103255dcb17
When the module faces API exception we can give much more useful
information to the user. Let us do this for the modules inheriting from
the base class, since all modules should do this at some point in time
Change-Id: I5f1ef01765829900334aa2ecae5dab3ba96f1a49
don't inherit OpenstackModule class from AnsibleModule class to
prevent occasional overriding Ansible methods or vars and failing
module.
Change-Id: Ic34fff0c938eb87cc0d2c5e98fbafed64bf349f6
In module_utils we have a bunch of factory functions that we expect
people to use in a certain combination to build a module, then we
pass around a reference to the SDK and to the connection we created.
That's largely just due to how this stuff grew organically.
Instead, create a base class to be used in the modules. For now it
allows us to clean things up a bit. But as a follow on - it should
maybe help us put in things like richer logging collection which
would otherwise need to be done with helper methods and whatnot.
Change-Id: I487e79fe18c0b9a75df7dacd224ab40ed7f4e1ab
