Now there is no way to revert the pending-delete images. Once the
admin operators want to revert the delete action, Glance should
give them this kind of ability.
This patch will enhance the glance-scrubber tool to support restoring
the image from pending-delete to active.
Change-Id: I11fe58403e3af102b63d15b3cc702e567e526bad
blueprint: pending-delete-rollback
Mark the owner_is_tenant configuration option as deprecated.
Includes a release note and regenerated configuration file.
Change-Id: I10c354aa82d269136eb743195d07411da231bfda
Implements: blueprint spec-lite-deprecate-owner-is-tenant
Includes information about the minor version bump and the new
import-method (web-download) introduced in this release.
Change-Id: Ib59d5cdae03f1ba146930abd48af4a5537d00fe5
This patch adds a new "glance-manage db check" command
which will check the current state of the users upgrade
repos and relay info back to the user if the user has any
outstanding db upgrades left to run with appropriate exit code.
Co-Authored-By: Bhagyashri Shewale <bhagyashri.shewale@nttdata.com>
Implements: Ie1e2fec2361765ddf23da897abcf0e12e682612e
Change-Id: I1e0b02d615690f65a17b4ccfe4e4a72cc9e15ada
Revise the releasenote from I98be97c42f23b60a72d520aad5f6078a96372c59
by reducing the release note to a summary and moving the details to
the documentation (Glance Admin Guide).
Co-authored-by: Bhagyashri Shewale <bhagyashri.shewale@nttdata.com>
Co-authored-by: Brian Rosmaita <rosmaita.fossdev@gmail.com>
Closes-bug: #1745124
Change-Id: Iaa3139fade75f1e3708dce8525f3571aba997589
Implements the spec Inject metadata properties automatically
to non-admin images
This commit adds new task '_InjectImageMetadata' to inject
the metadata properties automatically to non-admin images
at the time of creation of images using newly introduce
'image-import' api in v2.
DocImpact
Implements: I6a7ed31d5fae677cbbc9a6f6053f79d3e9326561
Change-Id: I98be97c42f23b60a72d520aad5f6078a96372c59
The glance-scrubber utility is used by administrators
for the offline deletion of images when the Glance
option `delayed_delete` is enabled. The refactoring in
this patch eliminates a dependency on the Glance
Registry v1 client. Further, after this change, the
glance-scrubber does not use the deprecated Glance
Registry at all. Instead, like the glance-manage tool,
it now visits the Glance database directly.
bp: scrubber-refactor
Change-Id: I26f570b85617200880543b7114730a1ac76d3fb1
Following apis are returning 500 error if user passes name with more
than 80 characters:
* md-tag-create
* md-tag-update
* md-object-create
* md-object-update
* md-property-create
* md-property-update
This happens because there is a discrepancy in db column length and
glance-api length check in schema validation. In database the 'name'
field for these API's is defined as of maximum 80 characters and in
schema it is defined as of maximum 255 characters. So if user passes
name with more than 80 characters and less than 255 characters
database fails to store that value and shouts with following error
which leads to 500 error to API user:
(pymysql.err.DataError) (1406, u"Data too long for column 'name' at
row 1")
Fixed this issue by changing the maximum allowed length for 'name'
from 255 to 80 in schema validation.
APIImpact
DocImpact
Closes-Bug: #1719252
Change-Id: I4ae67457c3e4f5a6bfc3c1db2d305a9b7587395f
Adds an overall release note for RC-1 and updates the metadefs
release note to reflect all Pike metadefs changes.
Change-Id: I466463e1f921d1d07227b987b7d80274fcdd5f42
The MVP of image import functionality will be introduced as an
EXPERIMENTAL 2.6 version of the Images API. The current version
will remain at 2.5.
This patch:
* Updates the version response
* Updates version negotiation code
* Updates unit and functional tests
* Updates the api-ref
* Adds a releasenote
Change-Id: Ied573897157e05f7b0438baeb1553326fb06613a
Metadefs changes for Pike will be described in a single release note.
This patch introduces the file and the first change. Other metadefs
changes in Pike should include a change to this file.
Change-Id: Id71acaf54e2fa623e1af247d5ddcafc27f55ee75
Partial-bug: #1699549
This commit adds an external lock to sqlite when launching multiple
worker processes (using uwsgi) the db init will fail for one since the 2
workers will race for initializing the DB. The method is idempotent so
we can safely run it twice in succession, but the lock is necessary to
provides us protection against running it at the same time.
Depends-On: I9a66a8636d12037ff9aa4fb73cc3f9b9343dd7e9
Change-Id: I654c3a5604a89402ba94d9cea44699a48583a7e0
The store values 'filesystem' and 'vmware_datastore' were
deprecated for 'store_type_preference' as per [1] in Newton.
This was to maintain uniformity with the values accepted for
'store' opt and 'store_type_preference' opt.
This patch removes acceptance for the old store values
and ensures uniformity between store names used in glance
and glance_store.
[1] I3d8593cdae6780ae721afedcf47dd45afa684f25
Change-Id: Id225275f7aad308bde450bef8bc6fd6ad7e3c6d2
Bug 1670409 affected the experimental zero-downtime database
migration process introduced in Ocata. It's worth pointing
out that there was a bug and that it was fixed for those deployers
who tried the experimental upgrade and were uncertain about why
exactly it failed.
Change-Id: I4f6d246d0cf860bc7e6b0588db0b3295a4f54e16
Currently glance v2 API incorrectly accepts ‘Content-Range’ header
for random image access and does not set response headers.
As per rfc7233, ‘Range’ requests should be accepted and ‘Content-Range’
must be returned in the response headers.
This patch enables Glance v2 API to accept the more appropriate ‘Range’
requests and sets ‘Content-Range’ response header.
For backward compatibility with pre-Pike Glance clients, the incorrect
'Content-Range' header will be accepted silently in perpetuity.
Thus this patch contains tests for 'Content-Range' in requests to
prevent regressions.
DocImpact
Implements lite-spec I5bdadde682a0c50836bd95e2a6651d6e7e18f172
Closes-Bug: #1677391
Co-Authored-By: Hemanth Makkapati <hemanth.makkapati@rackspace.com>
Change-Id: Ib7ebc792c32995751744be3f36cbc9a0c1eead2a
Glare became a separate project during Newton. The code was copied
out of the Glance tree, but remained in the Glance repository. It
is no longer being maintained, and that has begun to cause some
problems, for example, blocking a recent stevedore upper constraints
change; see I141b17f9dd2acebe2b23f8fc93206e23bc70b568
This patch removes the Glare code from the Glance repository. It
includes Alembic database migration scripts, in both the all-in-one
and E-M-C format. It also includes release notes.
Implements: blueprint glare-ectomy
Change-Id: I3026ca6287a65ab5287bf3843f2a9d756ce15139
This releasenote describes the effect of the following changes:
* Ie8594ff339a13bf190aefa308f54e97ee20ecfa2
* I77921366a05ba6f9841143af89c1f4059d8454c6
* Ie839e0f240436dce7b151de5b464373516ff5a64
* I34f5623d6804e9fe594e6b5b196ea4a162578196
Change-Id: Iaa411c3f3bbe5397da239409f504dcb4d769b08b
Currently, Scrubber exits with a status code of zero
upon job fetching errors both in daemon and non daemon
mode. It is more appropriate to have scrubber exit with
status code 1 if it is not in daemon mode.
This patch causes scrubber to exit with status code 1
(RuntimeError)if the scrubber is not running in daemon
mode, facilitating accurate exits.
Co-Authored-By: Steve Lewis <steve.lewis@rackspace.com>
Co-Authored-By: Dharini Chandrasekar <dharini.chandrasekar@intel.com>
Closes-Bug: #1548289
Change-Id: Ib75676dc90349f008395fb118978f4e37fa876ea
Current release note says adding a member to a private image will
result in a 409, but it actually results in a 403. Changing the text
to say the more neutral "4xx response" without specifying a return
code, because there are several errors that could happen here, for
example, 401, 404, 403. Interested parties will know to look in the
api-ref, where the error codes can be listed with more context than
is appropriate for a release note.
Change-Id: If513e5a0441b2c110c9339544a47ad33d77afaaf
This option will be mentioned in an upcoming OSSN. I think it will
be confusing to operators if the option is removed now, and it will
also be confusing if the text says "will be removed in the Ocata
release". This patch changes the text to say "will be removed in
the Pike release or later".
Corresponding release note has been added.
Co-Authored-By: Brian Rosmaita <brian.rosmaita@rackspace.com>
Co-Authored-By: Nikhil Komawar <nik.komawar@gmail.com>
Change-Id: Ib599afaee8f48f141be125a4016aece1e40e36cf
This is the release note for "Implement and Enable Community Images",
whose change identifier is I94bc7708b291ce37319539e27b3e88c9a17e1a9f.
Change-Id: I3502de58b1d2460f8a79500b033dd58f7de28f5e
Change-Id I94bc7708b291ce37319539e27b3e88c9a17e1a9f (Community
Images) entails a minor version bump in the v2 API.
Change-Id: I2b7cd5ec9b974ebc738feb89ef22c428fbe3be06
Depends-On: I94bc7708b291ce37319539e27b3e88c9a17e1a9f
Virtuozzo hypervisor reports itself as 'vz' hypervisor, and it
was supported as libvirt virt type since Kilo. Let's expand
image metadata so that it will possible to filter out compute nodes,
which don't support images requiring hypervisor_type=vz
Lite-Spec-Id: I6ba0fcf670aecddde95cfdc6850cdb751dec2058
Change-Id: I51afacf83655107a6c4e4c226623fa360bdafca2
This is a Follow-up patch for the review [1]. This patch fixes
a minor nit on the release note of the same.
[1] Ic24cf8234599a32add1cb9f294f902e497d885e0
Change-Id: I546ddcfb9b6d62fd3fbaa5aa8a76624211dfdab5
Currently image location updates (removing, replacing) are permitted for
images even if their state is not ``active``.
This need is to:
* Prevent the replacement of image locations of images that are not
``active`` or ``queued`` by returning a Conflict Error
(409 response code).
* Prevent removal of image locations of images that are not ``active``
by returning a Conflict Error (409 response code).
Changing of image locations when the image state is not ``active`` can
result in bad experiences for the users.
* If one tries to change or remove the location for an image while it
is in ``saving`` state, Glance would be trying to write data to a
previously saved location while the user updates the custom
location. This results in a race condition.
* For images that are in ``queued`` state and no image data has been
uploaded yet, there is no need for an image location to be
removed and permitting users to remove the image
location can result in a bad experience. However users can be
allowed to replace the image location to maintain backward
compatibility and also because replacing could mean replacing an
empty location by a non-empty image location.
* For images in ``deactivated`` state, it is essential that image
locations are not updated as it does not abide with the purpose of
the image state being set to ``deactivated`` and may cause security
concerns.
This commit introduces the following change in behavior:
* If an image is in ``active`` state, removing/replacing the custom
locations on that image will be allowed so there is no change in
behavior for this case.
* If an image is in ``saving`` or ``deactivated``, the status of
that image will be checked while trying to replace/remove the custom
location and a HTTP 409 Conflict status will be returned in response
to the user.
* If an image is in ``queued`` state, removing the custom
image location will not be permitted as an image in queued status
should not have any location associated with it. Replacing of location
may be permitted here though.
* If an image is in ``deleted`` or ``pending_delete`` state, a HTTP
409 Conflict status will be returned, if that image is visible to
the user (in case of admins). Otherwise, the location cannot be
removed/replaced anyway. Please note ``pending_delete`` is another
form of the ``deleted`` status and behavior in either case should be
expected to be same.
* If an image is in ``killed`` status, a HTTP 409 Conflict status will
be returned.
TODO:
Atomicity is required such that glance permits removal/replacement of
image locations on certain permissible image transition states handling
the race conditions like:
* In case where the status of the image is ``saving`` and it
has just moved to ```active`` status, ideally removing/replacing
custom location should be allowed. However, due to lack of
atomicity in setting image status glance will ignore setting the
location and a 409 will be returned.
* In case where the status of the image is ``deactivated`` and it
has just been moved to ``active`` status, ideally
removing/replacing custom location should be allowed. Again, due
to lack of atomicity in setting image status glance will ignore
the request and a 409 will be returned.
* In case where the status of the image is ``active`` and it has
just been moved to ``deactivated`` status, due to lack of
atomicity in setting image status, glance may remove/replace
the location on that image.
* In case where the status of the image is ``queued`` and it has
just been moved to ``saving`` status, due to lack of atomicity
in setting image status, glance may replace the location for
that image.
* In case where the status of the image is ``active`` and location
is attempted to be set on it, and at that point if the image goes
into ``deleted``, ``pending_delete`` or ``killed`` status, then the
user must get a HTTP 409 Conflict status. However due to lack of
atomicity in setting the image status, the location may get updated.
NOTE:
This commit ensures that removal of image locations
is not allowed for an image in any state except ``active`` and
replacement of an image location is not allowed except for ``active``
and ``queued`` images.
Further work is required on the atomicity of glance to accommodate
location updates in cases where the images would be undergoing state
changes.
Impacts:
APIImpact
DocImpact
Credits:
This commit message contains text and information from the commit
message for: https://review.openstack.org/#/c/324012/
co authored by Nikhil Komawar <nik.komawar@gmail.com>.
Co-Authored-By: Nikhil Komawar <nik.komawar@gmail.com>
Co-Authored-By: Dharini Chandrasekar <dharini.chandrasekar@intel.com>
Lite-Spec: https://review.openstack.org/#/c/368192/
Closes-Bug: 1622016
Change-Id: Ic24cf8234599a32add1cb9f294f902e497d885e0
The releasenote for change Ia054f8f637c826280722c0d2a6811fdbc0cf54ed
says a default value is changed in order to produce duplication of
logs, whereas the purpose of the change is to prevent duplication of
logs. This patch corrects the release note.
Change-Id: I1bb8d6f234f483824b1e9eb67b96aeefb43a7885
The 3.17.0 release of oslo.log changes the default value of "use_stderr"
to False (from True). We had tests that asserted that our glance-*
commands used stderr to provide information to administrators. This
works to preserve that default value for operators by overriding the
default to True when we're running in one of those commands.
We deliberately excluded glance-api, glance-glare, and glance-registry
because glance-api and glance-registry are usually not run manually and
they don't need to log to stderr by default and glance-glare is
deprecated.
Change-Id: Ia054f8f637c826280722c0d2a6811fdbc0cf54ed
The releasenote for change Ib900bbc05cb9ccd90c6f56ccb4bf2006e30cdc80
says that tasks were made admin-only in Liberty. They were actually
made admin-only in Mitaka. This patch s/Liberty/Mitaka/.
Change-Id: I38bb312e5a92434aa50f9dbb9673ec3628d8001b
* All "qemu-img info" calls are now run under resource limitations
that limit CPU time to 2 seconds and address space usage to 1 GB.
This helps avoid any DoS attacks via malicious images.
* All "qemu-img convert" calls now specify the import format so that
it does not have to be inferred by qemu-img.
SecurityImpact
Change-Id: Ib900bbc05cb9ccd90c6f56ccb4bf2006e30cdc80
Closes-Bug: #1449062
The store names used in glance and glance_store are not in sync with
each other.
This can confuse operators who have to use different names to refer to
the same store while setting values for configuration options such as
``store_type_preference`` in glance and configuration option like
``store`` in glance_store. This inconsistency may also confuse
developers during code changes, complicating future code changes with
respect to this.
Mapping store names: ``vmware_datastore`` and ``filesystem``
to ``vmware`` and ``file`` respectively to be in sync with glance_store
entry point names and at the same time accommodate backward
compatibility for old configuration files that might still be using
``filesystem`` and ``vmware_datastore``.
Note: This change applies only when multiple image locations are being
used and ``location_strategy`` configuration option is set to
``store_type``.
Note: This change does not require a config refresh change.
Impact:
UpgradeImpact
Credit:
This patch has a release note authored by Brian Rosmaita
Change-Id: I3d8593cdae6780ae721afedcf47dd45afa684f25
Closes-Bug: #1615852
* This commit updates any formatting, grammatical or other issues
in the release notes for Newton
* It also adds any missing yet important release notes to be part of
the release
Also, this commit standardizes release note page ordering:
* In order to support automatically updating the release notes when we
create stable branches, we want the pages to be in a standard order.
This patch updates the order to be reverse chronological, so the
most recent notes appear at the top. ( Inspired by Change
Ib364dcc8eb31275a31c83b68d7914263b183e393 )
Co-Authored-By: Nikhil Komawar <nik.komawar@gmail.com>
Co-Authored-By: Brian Rosmaita <brian.rosmaita@rackspace.com>
Co-Authored-By: Steve Lewis <stevelle@gmail.com>
Change-Id: I9247feb75d2b1b63eecfc4a750fd2aa070ea874b