When using the glance v2 API the glance-registry service is
optional, and the intention is to remove the glance-registry
service in the S cycle.
The glance v1 API is scheduled to be removed in Queens.
This patch therefore disables the v1 API by default to give
us as much time as possible to identify the impact of that
and to get the issues resolved before it is removed from
the code-base.
The patch also cleans up the glance-registry init files
to handle the transition in an existing environment.
Tests are added to validate that enabling the v1 API still
works, and enabling the v2 registry still works.
Change-Id: I4c27aa0ca5b649e4fa76cfd0f326d80f50074db1
The glance v1 API is deprecated and intended to be removed
from the glance code within the Queens or Rocky cycles.
When using the glance v2 API the glance-registry service is
optional, and the intention is to remove the glance-registry
service in the S cycle. The glance-registry service is required
when using the v1 API though.
Furthermore, when using the glance-registry service it is not
possible to execute a rolling upgrade without losing API
transactions.
Given the above information, this patch enables the deployment
of glance with only the v2 API enabled, and without the
glance-registry service. It adds a per-commit test to validate
that this configuration works.
This patch also corrects a previous misconfiguration which
enabled the v2 registry service, but did not set the data_api
correctly for the API service to inform it that the registry
was operating.
The glance_enable_v1_registry variable is also removed as it
is meaningless. The v1 API *requires* the registry to be
enabled, so we just enable it if glance_enable_v1_api is
enabled.
Change-Id: Ie95daed286798d139f0a35ffdd2a4dd1cdda6ff9
Release notes are version independent, so remove version/release
values. We've found that projects now require the service package
to be installed in order to build release notes, and this is entirely
due to the current convention of pulling in the version information.
Release notes should not need installation in order to build, so this
unnecessary version setting needs to be removed.
This is needed for new release notes publishing, see
I56909152975f731a9d2c21b2825b972195e48ee8 and the discussion starting
at
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124480.html
.
Change-Id: I967a2e5c2a014894198a908dc2d38ec0b2cb185e
Initially the intent for adding this was to better test
any patches for roles together before they merge, but it
has had the unintended side-effect of causing patches to
take much longer to merge (because they all get lined up
in a single queue, rather than independent queues) and
a lot more infra resources are used (because a patch
that fails at the top of the queue will result in all
subsequent patches restarting all their tests).
As discussed in the channel, we'd prefer to revert back
to the previous independent queue method of testing. It
has served us well.
Change-Id: I8b9146f9b4ca895d9d22e280c4a029ccfecd64ec
Currently the linters test is in the project-config
repository, but those are meant to be used for standard
jobs which do not require any repository other than the
one given. Our lint tests use the 'openstack-ansible-tests'
repository, so we should rather use our own job definition.
Change-Id: I2f28cdbb62b033f48db909c59c5036b34a5bfc5d
Depends-On: I0391ec310c4eede436011a48490e3c524c8ddf4d
This changes the a-r-r with the proper version, and fixes
the repo path for role upgrades:
The role will, during test-upgrade-pre, have its current branch
checked out, and will deploy the current branch infrastructure,
including the generation of the constraints.
Then, the installation of previous branch of the role will use
the constraints for its previous version, but will have no
constraints for it, and fail.
We need to generate the constraints for the previous version too.
This should do it.
On top of that, we needed to update the work for Zuul v3:
This implements the initial OSA zuul v3 role jobs.
This patch implements an initial set of jobs intended to match
the current job execution method. It does not intend to improve
how the jobs are executed - only to replicate what is currently
in openstack-infra/openstack-zuul-jobs and provide the platform
to iterate on.
Change-Id: I8710e7b9bb6010ba98279f61a63274ace56f6e8d
Co-Authored-By: Jesse Pretorius <jesse.pretorius@rackspace.co.uk>
We need to add openstack ansible information in the role
metadata to be able to track role maturity. With it,
we can create a role maturity table and take decisions about
role deprecations.
Change-Id: I5196403b4c63fe965ad566c9b19d921bb11e0891
Glare was separated into its own project some time ago and this file
doesn't appear to have ever been deployed by the role anyway.
Change-Id: I6eaa0fef8f3877c0b4093b2a8d7adb5cbcdff583
As part of the Pike goals we are moving api services to run as WSGI
apps. glance-api service is set up as a wsgi app, and this patch moves
it over.
Since this is just a drop in replacement for the existing eventlet
service operators and deployers should notice no difference.
Implements: blueprint goal-deploy-api-in-wsgi
Change-Id: Ie5fbf437031be01682534c466b3737d090a81c57
Moves the ceph_client role execution inside the os_glance role
instead of executing it at the playbook level.
Change-Id: I1d24a82f22663150f0db5bbfcb4d957d600db5c2
The current major upgrade detection compares
the same variable against itself. It also takes
place after the new venv tag has been placed
and the local facts are refreshed so there's
no good way to figure out the origin version.
Additionally, the version_compare filter only
works with semver version strings which is
unnecessarily strict.
Additionally, there does not appear to be any
evidence in the glance documentation that
the db sync action requires services to be
shut down or any other orchestration, so the
previously implemented action of doing a db
sync on every playbook execution should be
just fine. If there is nothing for it to do (which
will be the case for a minor upgrade) then it
will do nothing. If there is something for it to
do (which will be the case for a major upgrade)
then it will do what needs to be done.
As such, there appears to be no point in
implementing this extra set of tasks and
conditionals.
This reverts commit 647c4e33f1fcba771f23f7aabf0dc061b22f79ab.
Change-Id: I3b5afae3b7abf58de0b71ec2e67df2c38b6da5e3
When using Ansible with python3, the result of
the intersect filter is a set, not a list. This
causes a failure when trying to access item 0
in the list.
In this patch we cast the set to a list before
accessing item 0. This will work for both
python2 and python3.
Change-Id: I9b03c57a5b1f675a8ca6e42dd5aae6c1e4742603
When executing the playbook with limits set, the scoping
currently does not work quite as well as one would hope.
This tightens it a bit more to ensure that it operates
as expected.
Change-Id: Ie043fca77d98ce55edb84547b06be0001d7311ea
Add support for the openSUSE Leap distributions. Nothing special is
required for this except for adding the appropriate distro variables
file and also update the zypper cache before package installation.
Change-Id: Ia3fe5fedbbc2781cf2e7ae4d82c09e0960c6744b
As it turns out, run_once executes a task
once per batch when executed from a serialised
playbook instead of once per set of play hosts
as previously thought.
In this patch we implement a combination of
dynamic inclusion, inventory scoping and
play host scoping to achieve the required
goal of only running it once, even when the
playbook is executed using limits.
We also remove the unnecessary extra local
fact refresh.
Change-Id: Ib864bf2c0603e8281aa0ba3979ae020e90fd0adc
Some deployers make use of the new role without
implementing a change in the software, resulting
in the correct local facts not being deployed.
To hedge against this, we add some more conditionals
to ensure that the facts are deployed.
Change-Id: I1e783c5a791ab66fbb693f672d87cbf092cf8112
From Ansible 2.2 onwards, listen can be used for
handlers instead of chaining notifiers. The
handlers are then executed in the sequence
present in the handler file.
Change-Id: Ia185ab830005f311f37d4eb7dfab1ae116419e3b
