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] https://opendev.org/openstack/python-openstackclient/src/commit/e49ad1795b9dd57d5a82fb6f8f365fa20041cf29/openstackclient/compute/v2/server.py#L1070
[2] https://storyboard.openstack.org/#!/story/2007893
[3] https://opendev.org/openstack/openstacksdk/src/commit/9e9fc9879583943a08f854980cca5dfb3a5832f7/openstack/cloud/_compute.py#L1772
[4] https://opendev.org/openstack/openstacksdk/src/commit/9e9fc9879583943a08f854980cca5dfb3a5832f7/openstack/cloud/meta.py#L482
[5] https://github.com/ansible/ansible/commit/9bf33e56dd49e9478ba091a1ba12d17b7caeac24
[6] https://storyboard.openstack.org/#!/story/2007873



Signed-off-by: Jakob Meng <code@jakobmeng.de>
Change-Id: I2f955519a7e8c782b1dab8f94f7a019ed384b81d

Bifrost downgrades openstacksdk to a release <0.99.0 [1], which is
incompatible to our master branch of the Ansible OpenStack
collection. By adding openstacksdk to Zuul variable job.required-\
projects [2], Bifrost will install openstacksdk from its master
branch, overwriting any existing (older) openstacksdk releases.

[1] https://opendev.org/openstack/bifrost/commit/03ddd026567f7b61b89d83b0e7e7cb35ed466ae6
[2] https://review.opendev.org/c/openstack/bifrost/+/849563/5/playbooks/test-bifrost.yaml

Change-Id: I46dadc70338bb45d459e8176cc26e67c20c1d4ae

Make it compatible with new openstack sdk 1.0.0

Change-Id: I911eecd31ee69dbde1da02a74e152746c1e3edfa

No RDO release for CentOS8 will get a OpenStackSDK 1.x.x release.

Change-Id: I728f0f282717c11a782be30859f999008f3fc8cb

Build and install latest RPM for openstacksdk from its master branch
instead of using the (pinned) RPM from RDO. This is necessary because
openstacksdk in RDO is currently pinned to <0.99.0 for all RDO
releases. Variable artg_change_list is used to define what code is
being build from source. The RPM of the Ansible OpenStack collection
does not have build 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 other 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. It is also cleaner since our
CentOS9 job is 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

Added tripleo-ci-centos-8-standalone-osa to experimental jobs so that we
can actually run this job on demand easily.

[1] https://opendev.org/openstack/tripleo-quickstart/src/commit/cb1595223b09c991c3e8451c6d1b332a78f65a94/quickstart.sh#L123
[2] https://opendev.org/openstack/tripleo-quickstart/src/commit/cb1595223b09c991c3e8451c6d1b332a78f65a94/ansible.cfg#L19
[3] https://opendev.org/openstack/tripleo-quickstart/src/commit/cb1595223b09c991c3e8451c6d1b332a78f65a94/quickstart.sh#L595
[4] https://opendev.org/openstack/openstack-ansible-os_tempest.git

Change-Id: Ibde318678a3e44fdc297a6f29761eb0c7d77cbc9

Make routers_info module compatible with the new sdk 1.0.0

Change-Id: I43ea8ccc0d882ca63bc294dd99fb4f010f3806a5

Previously, all security_group{,_info} and security_group_rule{,_info}
modules were tested in the same Ansible role. This patch splits
tests into two separate Ansible roles to increase readibility and
prevent variable name conflicts, e.g. for expected_fields.

Change-Id: Ifc28435147b3bfe88d4ee5e176469a53b7395dc0

The solution is based on implementation of logging option
in Open Telekom Cloud collections.

Change-Id: Ie8b309d2aaa8da57794888848fc5414de207e54f

Change-Id: Iba1604ee9c0b922b8fb7c6a278acf90d080a63e7

Make project_info module compatible with the new sdk 1.0.0 and also add
ansible tests for project_info module

Change-Id: I413200cf6a9b8bada7e5d78087246b888d53fac2

Update endpoint to new openstack sdk

Change-Id: Ibd647d0c2cd2f90310f381e56088e7e8e93f76fc

Updating role_assignment module to use the new openstacksdk

Change-Id: I09258e18d50acb57501ea1b47d9422dad857607e

This patch do the following:

* Update catalog_service to use new openstacksdk
* Add catalog_service role to test catalog_service module

Change-Id: I6778f5e91cb0ead63cede28af0111d7ffbbf3ab1

Change-Id: I7625d696f6462a7a955008a5c7276f1548acbc2e

Keep jobs with devel branch of Ansible non-voting to prevent
Ansible from blocking our Zuul CI gates.

Change-Id: I92668b37d42db758e2bae8e791357b72c131a899

- Change the implementation to use the proxy layer
- Update the module to return an aggregate object
- Adds a role to test the module

Change-Id: I6a98ba8466863b41fc996855fd12cf9f3097abe0

- Change sdk calls to use proxy layer
- Convert sdk results to dict before returning
- General refactoring of module
- Move recordset specific tests from the dns role to new recordset role
- Adds additional tests to recordset role

Change-Id: If8fda40780050d271c9d869d8959ef569644fd88

A release candidate for the first major release of OpenStackSDK 1.x.x
has been published with version number 0.99.0. Release candidates will
be numbered using 0.99.x versions.

Ref.: https://meetings.opendev.org/irclogs/%23openstack-release/%23openstack-release.2022-05-19.log.html

Change-Id: I51a5b803f6646d3b1c5e198072cb3da19925fc3f

Commit bc27851617 [1] in opendev.org/openstack/tripleo-ci changed the
release filename for periodic jobs to promotion-testing-hash-*.yml [2]
instead of using e.g. train.yml for OpenStack Train based releases [3].
Due to this change, container images were not pulled from the local
image registry but from trunk.registry.rdoproject.org instead [2]. This
caused our periodic jobs to fail during container image build because
when using a local registry a different namespace prefix "openstack"
(instead of *-binary such as centos-binary) is used which is not valid
on trunk.registry.rdoproject.org.

As a workaround, we force TripleO jobs to run as check jobs, no matter
what pipeline they run in [4].

Thanks to Sandeep Yadav <sandyada@redhat.com> for discovering the root
cause of this issue and providing a workaround!

Ref.:
[1] https://opendev.org/openstack/tripleo-ci/commit/bc278516174cd1133ca910bb4978397499645a34
[2] https://github.com/openstack/tripleo-quickstart/blob/master/config/release/tripleo-ci/CentOS-8/promotion-testing-hash-train.yml#L7
[3] https://github.com/openstack/tripleo-quickstart/blob/master/config/release/tripleo-ci/CentOS-8/train.yml
[4] https://opendev.org/openstack/tripleo-ci/src/branch/master/roles/ci-common-vars/vars/main.yaml#L24

Change-Id: Ib7d8fc9e6781e43e04f0a9feee261b9f3f29e1fe

The following changes were made:

* Update identity_group_info to use the new openstacksdk
* Added identity_group_info role to test the module

Change-Id: I24e64c9455618952ee612d7413882f0ac022189f

This makes image_info compatible with new sdk version
- This patch changes get_image (which is a cloud object method) to image.get_image (proxy object method)
- image.images accepts **query which is a dict object. So this patch changes the args passed to a dict. If properties is not specified it passes an empty dict.
- updates the documentation to reflect the actual returned parameters
- adds a ci test to list all images without specifying image name or property and assert no field is missing
- changes openstack_image to image in ansible return value

Change-Id: Ibf934568f069c305747fc24fbb22ce3fc095286c

- Stop checking for to_dict, breaking compatibility with older sdk
  releases
- Updates RETURN doc string with all the returned fields
- Adds a new identity_role_info role to test the identity_role_info
  module.
- Change the name of the module return value to remove 'openstack_'
  prefix

Change-Id: If8a1145a31d685d41367383930e6fd08d64c6ae8

Switch to SDK's cloud layer function search_domains which allows
us to reduce our code. Added integration test for this module.

Change-Id: Ic7915fd3334266783ea5e9d442ef304fa734ca00

This patch changes the module to use the sdk proxy layer and does some
general refactoring to simplify the code. It will no longer fail if
no password is supplied since it is perfectly fine to create a user
with an password.

Renamed the test role from user to identity_user to match the module
name

Change-Id: I97ee9b626f269abde3be7b2b9211d2bb5b7b3c26

- Changes the module to get user through proxy layer
- Adds a role to test the module
- Renames the return value to drop openstack_ prefix

Change-Id: I99e98a529ce74ff2ca77a67d09f188228e6a0e37

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: Idb8720bd96843b7807dd5cb62b30c1edf3a7a37c

Also renames the test role to match the module name

Change-Id: Ie59da441d39fe2d0e49430662d853bc9628181e0

With merging the code for 1.0.0 of OpenStack SDK into the master branch
several of our modules and CI tests broke. To be able to merge patches
we had to set most of our jobs to non-voting, so atm we do not have a
good code coverage in Zuul CI.

This patch temporarily skips broken tests so that we can set our jobs
back to voting and get some basic code coverage from CI. Follow up
patches which fix modules are supposed to readd skipped tests on
occasion.

Change-Id: Ice42d0bdc12c24227a323ad9c5d3fd33870975c4

Our *-octavia jobs pull OpenStack SDK from PyPI and PyPI is still
serving the 0.x.x series of the SDK because 1.0.0 has not been
released yet. A recent commit bb25330d [1][2] broke compatibility
to older SDK releases prior to 1.0.0 and since then our *-octavia
job on our master branch is failing.

Ref.:
[1] https://review.opendev.org/c/openstack/ansible-collections-openstack/+/839033
[2] https://opendev.org/openstack/ansible-collections-openstack/commit/bb25330ddc07d9b433c9f8db7c52baed7020f0cf

Change-Id: I4bacc358cca08a71694c590202066c8565a96f02

The oldest branch in Heat repository is stable/rocky. Previously,
Zuul CI would use the master branch of Heat since it could not find
stable/queens branch but master branch has incompatibilities with
our Queens job.

Change-Id: Iaeca759cad641d4923fc63489fd65f57d9f1345a

Running older linter releases while we have a more up to date
Ansible 2.12 based linter does not provide value and thus wastes
ci resources. Our Ansible 2.9 based linter is broken atm and since
it is EOL soon anyway we drop this job. We still have a linter job
based on the last stable release and one based on Ansible's
devel branch.

Our tox environment for Ansible 2.9 will be dropped in a later
patch once all Ansible 2.9 based jobs have been removed.

Change-Id: I9cd3f729b06516bbd9a3c7985b65fcf294c8bdd7

Python module rstcheck which is used by ansible-test deprecated
Python versions prior 3.7 in version 3.5.0 and removed support
in 4.0.0 [1]. Ubuntu 18.04 LTS (Bionic Beaver) comes with Python
3.6 by default, so rstcheck prints a FutureWarning which confuses
ansible-test:

  Run command: ***/python -m rstcheck --report warning
  --ignore-substitutions _,br,release,today,version
  docs/openstack_guidelines.rst
  Traceback (most recent call last):
    File "***/ansible-test", line 28, in <module>
      main()
    File "***/ansible-test", line 24, in main
      cli_main()
    File "***/ansible_test/_internal/cli.py", line 130, in main
      args.func(config)
    File "***/ansible_test/_internal/sanity/__init__.py", line 193,
    in command_sanity
      result = test.test(args, sanity_targets, version)
    File "***/ansible_test/_internal/sanity/rstcheck.py", line 80,
    in test
      results = parse_to_list_of_dict(pattern, stderr)
    File "***/ansible_test/_internal/util.py", line 799, in
    parse_to_list_of_dict
      raise Exception('Pattern "%s" did not match values:\n%s' %
      (pattern, '\n'.join(unmatched)))
  Exception: Pattern "^(?P<path>[^:]*):(?P<line>[0-9]+):
  \((?P<level>INFO|WARNING|ERROR|SEVERE)/[0-4]\) (?P<message>.*)$"
  did not match values:
  ***/rstcheck.py:51: FutureWarning: Python versions prior 3.7 are
  deprecated. Please update your python version.
    FutureWarning
  ERROR: Command "/usr/bin/env ANSIBLE_TEST_CONTENT_ROOT=***/
  ansible_collections/openstack/cloud LC_ALL=en_US.UTF-8 ***/python3.6
  ***/ansible-test sanity -v --python 3.6 --skip-test
  metaclass-boilerplate --skip-test future-import-boilerplate plugins/
  docs/ meta/ scripts/ --metadata ***.json --truncate 0 --redact
  --color no --requirements" returned exit status 1.

We cannot constrain the version of rstcheck which ansible-test installs
into its Python virtual environment. This has to be fixed in Ansible
itself, a pull request against Ansible 2.9 has been opened [2].

Ref.:
[1] https://github.com/myint/rstcheck/blob/master/README.rst
[2] https://github.com/ansible/ansible/pull/77568

As a workaround we temporarily set our Ubuntu 18.04 based linter job
openstack-tox-linters-ansible-2.9 to non-voting and remove it from
check dependencies and as a gate job.

Thanks to Arx Cruz and Jesper Schmitz Mouridsen for pointing out this
issue and its root cause ☺️

Change-Id: Ic6f2febc5a40a29534ac4c7f41f714865099086a

Ansible's git repository has no master branch but a devel and several
stable-* branches instead.

Change-Id: I43844c8a1cefceb7337e5a6ff1e8b8df451efb26

Sorted pip requirements file to improve readability.

Moved pip requirements for tests into tests subdirectory and dropped
'pip-' prefix to shorten filenames and conform with common naming
scheme for pip requirements files.

Added constrains on OpenStack SDK 1.*.* to job ansible-collections-\
openstack-functional-devstack-releases on master branch because only
stable/1.0.0 branch is compatible to the OpenStack SDK 0.*.* series.

Changed job ansible-collections-openstack-functional-devstack-releases
on master branch to non-voting because OpenStack SDK 1.*.* has not
been released to PyPI yet, so tests on master branch are expected to
fail once we introduce breaking changes from stable/1.0.0 branch.

Change-Id: I6b6bb8c6900f7c8341bbf3f9a24999fbf693ba4b

Reverted commit 1f3417cd [1] which disabled check-import.sh script.
Python module galaxy_importer will return a non-zero return value on
errors since commit 4f5fd0f29c [2].

Use galaxy-importer 0.3.1 for Ansible 2.9 and galaxy-importer 0.3.2
for later Ansible releases because galaxy-importer moved from ansible
2.9 to ansible-core 2.11 in 0.3.2 [3].

Ref.:
[1] https://opendev.org/openstack/ansible-collections-openstack/commit/1f3417cdef4b55fa6cfb241815a2531358fa286f
[2] https://github.com/ansible/galaxy-importer/commit/4f5fd0f29c30c354cd92837ac71109abc0b48082
[3] https://github.com/ansible/galaxy-importer/commit/98933547831922c45243f39d85eefe150b55fc36

Change-Id: I898149727d80cd7effe6a04ca77a13ef1774e781

Releases of OpenStack SDK on PyPI will soon switch to the 1.*.* series
which our stable/1.0.0 branch is incompatible with. Previously, in
commit 0f532d10f3, several jobs have been changed to run on master
branch only.

This patch adds siblings jobs for our stable/1.0.0 branch which
pull the latest SDK releases of the 0.*.* series from PyPI instead.

Ref.: https://opendev.org/openstack/ansible-collections-openstack/commit/0f532d10f373a3c6cf26be09045da5a934214729

Change-Id: Iefc6acfa4c25eb5d9ab062a3bfa655be2188cb77

Job *-train-ansible-2.11 failed since commit 031475d4 because that
patch caused most jobs to install the latest Python packages of
OpenStack SDK and other requirements from PyPI to tox' virtualenv
instead of respecting the override-checkout keywords and using
releases of OpenStack Train. Commit 87858ab976 and its follow ups
has fixed this issue.

Ref.:
https://opendev.org/openstack/ansible-collections-openstack/commit/031475d42e306808fa1beefdaaf615fa540662a4
https://opendev.org/openstack/ansible-collections-openstack/commit/87858ab976160e08536b936bb7a3e1498d38c1d2

Change-Id: Ib12e6195db9bb232735ea5a785ccc88bc749ea17

Added a parent job *-functional-devstack-base which defines basic job
attributes such as job.required-projects. It does not restrict branches
because else Zuul would not find a matching parent job variant during
job freeze when child jobs are on other branches. It does not define
attributes job.override-checkout and job.required-projects.override-\
checkout because else Zuul would use this branch when matching variants
for parent jobs during job freeze.

Jobs *-devstack-{xena,wallaby,train}-ansible-2.{11,12} have been
changed to inherit from *-devstack-base instead of *-devstack-ansible-\
2.{11,12}. The latter do not run for branch stable/1.0.0 which caused
Zuul to dismiss the *-devstack-{xena,wallaby,train}-ansible-2.{11,12}
when collecting parent job variants during job freeze:
The previous parent jobs *-devstack-ansible-2.{11,12} set job.branches
to master so Zuul cannot match that job when it collects job variants
and thus would ignore the child jobs.

Likewise, jobs *-devstack-{xena,wallaby,train}-ansible-2.{11,12} cannot
inherit from any parent job which sets job.required-projects.override-\
checkout on openstack/devstack because Zuul would use that git ref
instead of stable branch defined below to checkout projects of parent
devstack jobs when collecting variants for parent jobs.

Added a warning to the beginning of .zuul.yaml to keep this file in
sync between branches to avoid issues e.g. with job scheduling. Zuul CI
will search in master branch first when collecting job variants during
job freeze which can have unwanted side effects. For example, when
parent job *-base has been changed in stable/1.0.0 branch, Zuul could
still use *-base variants from master branch during job freeze on child
jobs such as *-ussuri-ansible-2.11 etc.

Change-Id: I3ca4ed5795c45a5565a374f04a1ddb29816bf114

When a patch is submitted against a branch, Zuul CI will collect job
variants for each ci job and all its parent jobs. If both job.\
override-checkout and job.required-projects.override-checkout
attributes are not defined, then Zuul will for each (parent) job match
the current branch of the patch against all branches of the project in
which the job is defined. If no such branch exist in a project, then no
job variant matches and this job will be ignored [1].
For example, if a patch is submitted for our stable/1.0.0 branch, then
Zuul CI will try to match 'stable/1.0.0' against all branches in the
projects where job ansible-collections-openstack-functional-devstack
and its parent job openstacksdk-functional-devstack are defined. The
first is defined in openstack/ansible-collections-openstack/.zuul.yaml,
so a match for stable/1.0.0 will be found. But openstacksdk-functional-\
devstack is defined in openstack/openstacksdk/.zuul.yaml which has no
branch stable/1.0.0 defined. So Zuul will not schedule job ansible-\
collections-openstack-functional-devstack at all.

The solution is twofold. First, the base jobs such as ansible-\
collections-openstack-functional-devstack have to be changed to always
checkout existing branches in projects which define (parent) jobs.
Using job.override-checkout might have unintended sideeffects because
it will checkout the specified branch for all required projects which
also includes the project which the patch was submitted for. Instead
we set job.required-projects.override-checkout for all projects which
define parent jobs. For example, in ansible-collections-openstack-\
functional-devstack we set job.required-projects.override-checkout to
master for opendev.org/openstack/devstack which defines parent job
openstack-functional-devstack.

In child jobs which (re)define job.override-checkout, we have to change
job.required-projects.override-checkout for all projects which define
parent jobs to the value of job.override-checkout. If we fail to update
job.required-projects.override-checkout then Zuul will checkout the
branch which was defined in the base jobs because job.\
required-projects.override-checkout has higher precedence than job.\
override-checkout.

Setting attribute project.<pipeline>.debug to true helps with debugging
these job scheduling issues. "If this is set to true, Zuul will include
debugging information in reports it makes about items in the pipeline.
This should not normally be set, but in situations were it is difficult
to determine why Zuul did or did not run a certain job, the additional
information this provides may help" [2].

Note, once job scheduling has been completed, Zuul will use a different
algorithm to checkout projects which are listed in job.\
required-projects [3][4]. It will fallback to a default branch if no
matching branch can be found in projects [5].

Ref.:
[1] https://opendev.org/zuul/zuul/src/branch/master/zuul/model.py#L6996
[2] https://zuul-ci.org/docs/zuul/latest/config/project.html#attr-project.%3Cpipeline%3E.debug
[3] https://zuul-ci.org/docs/zuul/latest/job-content.html#git-repositories
[4] https://opendev.org/zuul/zuul/src/branch/master/zuul/executor/server.py#L1648
[5] https://zuul-ci.org/docs/zuul/latest/config/project.html#attr-project.default-branch

Change-Id: I31f9607ab7e2e2ae8534429da7f5e5f235560c56

OpenStack SDK 0.* releases, from OpenStack Zed and earlier, are only
supported by our stable/1.0.0 branch. Our master branch does not
support old SDK releases anymore, so we restrict Zuul CI jobs
which run older OpenStack releases to patches against our
stable/1.0.0 branch.

Change-Id: I45bf5f90ba2265ab3b9faab77b75babf693b52bb
(cherry picked from commit 8708167b5fc664ee893b4fbef64fcf25d7946e1b)