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: Ia53c2c34436c7a72080602f5699e82d20f677b8b
Tox>3,<4 does not support dots in generative envlists and tox>=4 changed
its behaviour when it detects hyphens in env names [1].
[1] 0580121601/src/tox/tox_env/python/api.py (L130)
Change-Id: I63ad716415755d2a140a6ade97d22bd18236a0df
(cherry picked from commit 7945d7f01a)
Module templates have little benefit because
* they are not documented anywhere,
* their structure is not suitable for our modules, hence not a
single module is written according to the templates,
* contributers better base their own modules on existing modules
because we have modules for most OpenStack components,
* they are outdated, e.g. normalizing is a relict of
openstacksdk<0.99.0 and results,
* they are bloated, e.g. *_info module is doing preliminary checks
and creating filters in separate functions which proved in other
modules to be much better readable when inlined,
* they are hard to understand, e.g. argument_spec definition is
a huge Jinja2 template which does nothing except for copying
arguments from one place to another,
* they are not tested.
Change-Id: I460b75c09a361e712bbfb002c1ad1d03b3dff8ee
(cherry picked from commit 133af96666)
The solution is based on implementation of logging option
in Open Telekom Cloud collections.
Change-Id: Ie8b309d2aaa8da57794888848fc5414de207e54f
(cherry picked from commit 19cd6262cf)
Previously, openstack.cloud.keypair would remove trailing spaces after
reading a public key from a file. The openstack cli tool, python-\
openstackclient, does not do so, i.e. it does not use rstrip to remove
spaces at the end [1]. This breaks idempotency when using openstack
cli tool and our keypair module at the same time.
The rstrip code was introduced to keypair when our modules were still
part of ansible (non-core) in a completely unrelated change [2].
Now, keypair module does no longer alter the public key and instead
uploads it unchanged to OpenStack API.
[1] 7df94c9f82/openstackclient/compute/v2/keypair.py (L103)
[2] 341efbf7ae
Story: 2008574
Task: 41726
Change-Id: Ia09658467d98516ca1ea612e7301629b2f69d2d1
(cherry picked from commit 73827a3d57)
Added a note that we do not have to build the RPM of the Ansible
OpenStack collection from source because TripleO Quickstart installs
the collection from job.required-projects [1]. The latter shadows the
RPM release which is installed later by TripleO because it has a
higher precedence in ansible.cfg [2][3].
Changed the job hierarchy to base jobs tripleo-ci-centos-8-\
standalone-build and tripleo-ci-centos-9-standalone-build. This reduces
the number of variables we have to define. In particular, variables
containers_base_image, build_container_images and featureset will be
inherited from parent jobs. The CentOS9 jobs are no longer based on
the CentOS8 job which prevents issues with job variant collections
due to our branched repository.
Added more Ansible modules to files which trigger TripleO jobs,
because Ansible role os_tempest [4] requires those modules and is
called in TripleO jobs. Modules which have been added include:
* openstack.cloud.compute_flavor
* openstack.cloud.image
* openstack.cloud.network
* openstack.cloud.router
* openstack.cloud.subnet
Dropped tripleo-ci-centos-9-standalone-osa from check jobs because the
master branch of TripleO C9 will have the OpenStack SDK 1.x.x release
series only which requires the master branch of the Ansible OpenStack
collection. The only RDO branches with openstacksdk <0.99.0 which will
be maintained longterm are C8 Train, C8 Wallaby and C9 Wallaby.
Dropped TripleO job based on C8 Train from check and periodic and moved
it to experimental. It is unlikely that C8 Train will receive updates
for Ansible OpenStack collection.
[1] cb1595223b/quickstart.sh (L123)
[2] cb1595223b/ansible.cfg (L19)
[3] cb1595223b/quickstart.sh (L595)
[4] https://opendev.org/openstack/openstack-ansible-os_tempest.git
Change-Id: Ibde318678a3e44fdc297a6f29761eb0c7d77cbc9
(cherry picked from commit fc2dda1d86)
- Adds tests
- Update docs
- Add option aliases
This patch do the following:
* Update catalog_service to use new openstacksdk
* Add catalog_service role to test catalog_service module
Change-Id: I6778f5e91cb0ead63cede28af0111d7ffbbf3ab1
(cherry picked from commit 7c7e61d36b)
With this change we replace zuul.projects with zuul.project that will
imply any project which will run the job. Also we read galaxy.yml as
vars file to predict packed collection naming for futher upload.
Change-Id: I66e27f3026689ad719384203fe66d65f5bca46ce
Needed-By: https://review.opendev.org/c/openstack/ansible-config_template/+/846391
(cherry picked from commit 8f27184f30)
- General refactoring of module
- Move recordset specific tests from the dns role to new recordset role
- Adds additional tests to recordset role
Note that this is not a clean cherry pick due to sdk changes
Change-Id: If8fda40780050d271c9d869d8959ef569644fd88
(cherry picked from commit 97b05533f1)
- Update the module to return an aggregate object
- Adds a role to test the module
Note that this is not a clean cherry pick as it excludes changes related
to new sdk compatibility.
Change-Id: I6a98ba8466863b41fc996855fd12cf9f3097abe0
(cherry picked from commit 4ea2c5b50d)
Keep jobs with devel branch of Ansible non-voting to prevent
Ansible from blocking our Zuul CI gates.
Change-Id: Iba427d1852e56aaafc394c8265d3d1f28ca9574b
Bifrost's master branch installs the latest OpenStack SDK from PyPI
which currently is the first release candidate (0.99.0) of the
upcoming first major release of OpenStack SDK 1.0.0. Jobs on our
stable/1.0.0 branch are compatible with older releases of OpenStack SDK
only. This patch does checkout stable/yoga branch of Bifrost which
installs a sufficiently old release of OpenStack SDK due to
opendev.org/openstack/requirements/upper-constraints.txt.
Change-Id: I49a7b50aee45197d9309d959ff49e763f370619b
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 caps the maximum required SDK versions to 0.98.999, 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 stable/1.0.0 branch
with a OpenStack SDK 0.99.x or 1.x.x release.
Change-Id: Ic077f7a906698025edf20acf22c7a5c6caa8734a
Added ci integration tests and updated return value documentation.
Reverted function calls which would break backward compatibility
with previous collection releases.
Change-Id: I24e64c9455618952ee612d7413882f0ac022189f
(cherry picked from commit a6805cd019)
Previously the owner field was not set by module
`cloud.openstack.image`, although it is specified as a module parameter.
The usual approach in `ansible-collections-openstack` is to accept both
names and IDs when referencing openstack resources.
Therefore this commit follows the approach taken by
`python-openstackclient` in [1] and introduces a `project` and a
`project_domain` parameter to identify projects by name or ID and
assign the ID to the `owner` attribute of the image.
The `owner` parameter is left as an alias to `project` in the module.
Story: 2009983
Task: 45012
[1]
cf2de9af79
Change-Id: I3654587df8e40d554aac5126df307961f335332c
Added ci integration tests, updated return value documentation and
refactored to simplify code. Reverted changes such as function calls
and return values which would break backward compatibility with
previous collection releases.
Change-Id: Ibf934568f069c305747fc24fbb22ce3fc095286c
(cherry picked from commit c1a9794207)
Added ci integration tests, updated return value documentation and
refactored to simplify code.
Change-Id: If8a1145a31d685d41367383930e6fd08d64c6ae8
(cherry picked from commit 1d22a94a90)
Added ci integration tests and updated return value documentation.
Reverted function calls which would break backward compatibility
with previous collection releases.
Change-Id: Ic7915fd3334266783ea5e9d442ef304fa734ca00
(cherry picked from commit b31fdf8320)
Renamed ci integration tests to match module name, updated return
value documentation and refactored to simplify code. The module will
no longer fail if no password is supplied since it is perfectly fine
to create a user with an password. Reverted function calls which
would break backward compatibility with previous collection
releases.
Change-Id: I97ee9b626f269abde3be7b2b9211d2bb5b7b3c26
(cherry picked from commit fd1b9fc0d2)
Added ci integration tests and updated return value documentation.
Reverted function calls which would break backward compatibility
with previous collection releases.
Change-Id: I99e98a529ce74ff2ca77a67d09f188228e6a0e37
(cherry picked from commit 2df07f3523)
Previously, all job definitions where shared across each .zuul.yaml in
both branches. When a job definition was changed in one branch, Zuul CI
could pick the job definition from the other branch, which was not
intended.
The problem arises when mixing explicit job.branches matchers with
implicit branch matching, when defining same jobs on multiple branches.
Zuul CI expects that jobs to be defined in one or the other branch, not
both at the same time. One should only use job.branches matchers from
single-branched projects, e.g. trusted config repos. When defining jobs
in branched repositories one selects which job definition to use by the
branch associated with the triggering event instead.
Each trigger has a branch associated with it, whether it is the branch
targeted by the change being proposed, the branch to which a commit
merged, a branch attached to a timer trigger etc. This branch name is
searched across involved projects in order to determine what job
definition should be used.
The job.branches directive is rarely applied to a job which will be
copied to multiple branches. When you have multiple copies of a job
with the job.branches attribute, Zuul CI could pick any of the job
definitions which might not be the one you expected.
The job.branches attribute is useful in single branch config
repositories where a specific job definition has to be applied to a
specific branch of the repository. Another definition of the job
will exist in another branch of the config repository.
This patch removes job definitions which are specific to other
branches, except for parent jobs which are shared across branches.
Signed-off-by: Jakob Meng <code@jakobmeng.de>
Change-Id: Idb12d9eef9116a19b1323b2ce45ef672ae4a4f5e
Rename ci role to match the module name. Reverted function calls
which would break backward compatibility with previous collection
releases.
Change-Id: Ie59da441d39fe2d0e49430662d853bc9628181e0
(cherry picked from commit cc1b5ecae8)
