This patch adds a detailed description for filesystem_store_file_perm option which
was added in https://review.openstack.org/#/c/119529.
Change-Id: Ia567b9d56891940a8170d67d95c1cb318545094e
- Rename resource_type to resource_type_
associations in namespace API input/output
- Add created_at/updated_at in resource_
type_associations block of namespace API
input/output.
- Fix minor nits
Closes-bug: 1367908
Change-Id: Ie74bfb36a7023abb346852f5b863f19d0d7bc4ff
A sample import script to successfully import image from http or https
location is introduced. This should work on a devstack installtion.
Also, the following changes are introduced:-
1. An interface for implementing any other type of executor.
2. Provides namespace for keeping Tasks scripts.
3. A config for choosing deployer specific executor.
4. An interface for writing Tasks scripts.
5. A module for common script related methods.
6. Logic for limiting number of simultaneous tasks execution on the
Glance API server.
partially implements bp async-glance-workers
DocImpact
Change-Id: I382472fffd0fdad43573e72b2e78a9a6ed1e1f1a
Implements: blueprint metadata-schema-catalog
A common API hosted by the Glance service for vendors, admins,
services, and users to meaningfully define available key / value
pair and tag metadata. The intent is to enable better metadata
collaboration across artifacts, services, and projects for
OpenStack users.
This is about the definition of the available metadata that can
be used on different types of resources (images, artifacts,
volumes, flavors, aggregates, etc). A definition includes the
properties type, its key, it's description, and it's constraints.
This catalogue will not store the values for specific instance
properties.
- REST API for CRUD on metadef namespace
- REST API for CRUD on metadef objects
- REST API for CRUD on metadef properites
- REST API for CRUD on metadef resource types
- REST API for JSON schemas on metadef API's
Change-Id: I8e6d88ffee9a9337bf82b1da85648ba638a154ab
DocImpact
Co-Authored-By: Lakshmi N Sampath <lakshmi.sampath@hp.com>
Co-Authored-By: Wayne Okuma <wayne.okuma@hp.com>
Co-Authored-By: Travis Tripp <travis.tripp@hp.com>
Co-Authored-By: Pawel Koniszewski <pawel.koniszewski@intel.com>
Co-Authored-By: Michal Jastrzebski <michal.jastrzebski@intel.com>
Co-Authored-By: Michal Dulko <michal.dulko@intel.com>
*) Add osprofiler wsgi middleware
This middleware is used for 2 things:
1) It checks that person who want to trace is trusted and knows
secret HMAC key.
2) It start tracing in case of proper trace headers
and add first wsgi trace point, with info about HTTP request
*) Add initialization of osprofiler at start of serivce
Set's olso.messaging notifer instance (to send notifications to
Ceilometer)
*) Add tracing support for sqlalchemy
*) Add profiler CONF group that has to options:
1) Enable or disable profiler
2) Enable or disable sqlalchemy tracing
(the reason why we put this in Conf options, is that usually
db requests create a lot of trace info)
*) Glance-registry wasn't setted properly to send notifications.
To test it you need 2 things:
1) Enable ceilometer in devstack:
http://paste.openstack.org/show/85724/
2) Initialize osprofiler and send out API request. You can use
one of follow approaches:
a. Run this script (pls provide proper credentials)
http://paste.openstack.org/show/85722/
b. Use the function https://review.openstack.org/#/c/111184/
added from glanceclient CLI directly.
DocImpact
Change-Id: I45a19f5eb5304c2b78a9e12cbc0744941a807304
Co-author: Zhi Yan Liu <zhiyanl@cn.ibm.com>#
The auth_token middleware in python-keystoneclient is now
deprecated and has been moved to keystonemiddleware.
Closes-Bug: #1342274
Change-Id: Ic8ba2d2f470ec052ba13c3b63b26d5e2270f7412
The config docs have historically recommended that the number of
glance workers should be set to the number of CPUs available for
best performance, so we should make this the default.
Commit 75c96a48fc7e5dfb59d8258142b01422f81b0253 did the same thing in
Nova in Icehouse and the plan is to do the same thing for Cinder
and Trove workers.
The config files are updated to match the help string in the code.
There is no upgrade impact since glance-api.conf previously
hard-coded the workers value to 1 so anyone upgrading to this
will still get whatever value was set in glance-api.conf prior
to this change.
DocImpact: glance workers will now be equal to the number of
CPUs available by default if not explicitly specified
in glance-api.conf and/or glance-registry.conf.
UpgradeImpact: There is no upgrade impact to glance-api workers
since glance-api.conf previously hard-coded the workers
value to 1 so anyone upgrading to tihs will still get
whatever value was set in glance-api.conf prior to
this change. There is an upgrade impact to the
glance-registry workers since glance-registry.conf
did not hard-code the workers value to 1 before change
I0cee0d284eef9ce5dcb26720499f2c4d31eaca0f, which is
overwritten here. So anyone upgrading to this change
that does not have workers specified in
glance-registry.conf will now be running multiple
workers by default when they restart the glance
registry service.
Closes-Bug: #1333325
Change-Id: I6795c6e22268bb3fb67331edc7af641aefa904cc
Currently the 'workers' option -- to increase the number of
service processes -- is only documented for the API.
This change adds the equivalent documentation for the registry.
DocImpact
Change-Id: I0cee0d284eef9ce5dcb26720499f2c4d31eaca0f
Closes-Bug: #1334711
Adding large images to glance now uses the S3 MultiPart Upload REST API.
Added a unit test to upload images of various sizes to trigger the usage
of the S3 Multipart Upload API and ensure that it is being exercised.
DocImpact: The following parameters are added in glance-api.conf
+# Size, in MB, should S3 start chunking image files
+# and do a multipart upload in S3. The default is 100MB.
+#s3_store_large_object_size = 100
+
+# Multipart upload part size, in MB, should S3 use when uploading
+# parts. The size must be greater than or equal to
+# 5MB. The default is 10MB.
+#s3_store_large_object_chunk_size = 10
+
+# The number of thread pools to perform a multipart upload
+# in S3. The default is 10.
+#s3_store_thread_pools = 10
Implements: blueprint s3-multi-part-upload
Change-Id: I36e28e7944e57cd7ac05e46afac461ec10245c68
The image locations table stores the swift url for images
which includes the user and key values. This if exposed,
can cause security risk. Hence this patch, santizies
that information out of the location before storing
and plugs it back in when it is required.
Introduced a new configuration file that supports
multiple swift account references. It has the credentials and
authurl for each store. It is specified using
'swift_store_config_file'.
In addition, this patch does the following things:
Differentiate user and system created swift locations
Currently we do not differentiate between user supplied
uri and system created locations that have the account
reference. This patch introduces new scheme:
'swift+config' for this purpose.
Image create in V1 should validate the uri in case where location isn't
specified.
This patch ensures that a store is not set while
creating an image or updating it.
Related to bp remove-sensitive-data-from-locations
Implements blueprint: support-multiple-swift-backends
Implements bp: v1-image-create-should-validate-the-location-uri
DocImpact
Co-authored by: sridevik <sridevi.koushik@rackspace.com>,
iccha-sethi <iccha.sethi@rackspace.com>,
amalabasha <amala.alungal@rackspace.com>
Change-Id: I75af34145521f533dcd6f5fd7690f5a68f3b44b3
The notifier_strategy option is deprecated since we merged commit
I8cd84772bc5867e06b2a50ed7e15b9e86f0b94ad during the Icehouse cycle.
Assuming the usual single cycle deprecation period, this can now be
removed.
DocImpact: the notifier_strategy has been removed in favor of the
notification_driver and related oslo.messaging options.
Change-Id: I3ab0133b697a820536e5da84e30b078915a29f6c
https://review.openstack.org/#/c/69187/ introduced SSL certificate checking
in python-swiftclient (released as v2.0). This patch ensures that the version
of swiftclient used will verify SSL certificates correctly.
This patch also documents the `swift_store_auth_insecure` configuration
option for bypassing the cert verification
DocImpact
SecurityImpact
Change-Id: I20ddab5c3359071daf7505268c72331e4c786987
user_storage_quota now accept value in B, KB, MB, GB
or TB. The unit is optional. If no unit is specified
Bytes is used as default.
DocImpact
Change-Id: Icc3f672869a5947cbcae38de92993c88ce0ef4e1
Closes-Bug: #1261747
The documentation in configuring.rst needs to be populated
for the VMware datastore storage backend.
docImpact
Change-Id: I2064292867e12e699ca0a8ebba6c11f9de3591a5
Closes-Bug: #1275040
This change will make possible to enable/disable both v1 and v2 Registry APIs
either individually or together from glance-registry.conf.
DocImpact
Closes bug: #1290432
Change-Id: Ib2458b3312bdb552975b1e42485086a1c3aa6d3f
This patch will add document about how to use the
API message localization.
Partially implements bp i18n-messages
Change-Id: I389103574fc52feed96c592cbafbb52faccda939
An OVA package is a tar archive usually containing an OVF directory
inside it. Nova needs to be able to differentiate OVF and OVA based on
the container format in order to extract the relevant information from
it.
This patch adds the OVA container format to the Glance configuration.
Closes-Bug: #1286375
Change-Id: I5034d2943907823a9296e7a5fb41a28f2d92ec5a
Customers using a VMware environment with OpenStack should be able to
store their Glance images in VMware datastores. This is a first step to solve
the problem where Nova needs to copy the bits over the network
from Glance to the datastore when spawning an instance.
Also, this give the ability to provide some optimizations for specific
image formats in the future (fast cloning for example).
This patch contains a 'glance/store/vmware/' folder with the code
to manage the connection with vCenter or an ESX(i) host.
This code will go away as soon as it is merged to Olso:
see review https://review.openstack.org/#/c/65075/
The current implementation give this ability to specify the vCenter or
ESX(i) IP. In case of a vCenter IP, there is no optimization to reduce
the datapath (no host selected).
Consequently, it is recommended to specify an ESX IP if the ESX host
API endpoint is accessible from Glance.
docImpact
Implements bp vmware-datastore-storage-backend
Change-Id: I3837912e0d1614b9c31a689f71c2e34d453e2dc3
Finish updating the glance manpages:
- Update and modernize all files and references
- Add a new manpage for glance-replicator
- Move the common configuration options to common files for
easier maintenance and less redundancy
Change-Id: If2cbcc30f2761b187038f39324c7698de4eb2ab9
Closes-Bug: #1238366
Currently to configure multiple nfs server as a backend
using filesystem store, you cannot mount all disks to a single directory.
Filesystem store allows administrator to configure only single directory with
filesystem_store_datadir parameter in the glance-api.conf.
With multifilesystem store, administrators can configure multiple directories
to store the glance image with help of filesystem_store_datadirs option.
Each directory can be coupled with its priority.
Format for filesystem_store_datadirs in glance-api.conf:
--------------------------------------------------------
filesystem_store_datadirs = </path/to/store>:<priority>
...
filesystem_store_datadirs = </path/to/store>:<priority>
Example:
filesystem_store_datadirs = /var/glance/store
filesystem_store_datadirs = /var/glance/store1:100
filesystem_store_datadirs = /var/glance/store2:200
Note:
-----
1. Either filesystem_store_datadir or filesystem_store_datadirs option
must be specified in glance-api.conf
2. Store with priority 200 has precedence over store with priority 100
3. If no priority is specified, default priority '0' is associated with it.
4. If two filesystem stores have same priority store with maximum free space
will be chosen to store the image.
5. If same store is specified multiple times then BadStoreConfiguration
exception will be raised.
blueprint: glance-multifilesystem-store
DocImpact: Multifilesystem support can be used by specifying multiple
directory paths to filesystem_store_datadirs param in glance-api.conf as
discussed above.
Change-Id: Ibb04ac14c472cd863c5e285b6dc6a08c69014fe8
If a request to Swift for an image fails before the full image is
downloaded, this will reconnect to Swift and download the remainder of
the image without having to start from scratch.
DocImpact
blueprint retry-swift-download
Change-Id: Ifde68415707506b56ffac1939c6750b216b87a87
In roles based property protection, if '@' and '!' are in the same rule then the
glance api will not start considering this an Invalid Configuration.
DocImpact
Closes-bug: #1260333
Change-Id: I1d304f5c505ae9e2486ff653dda205fc2d851c2b
The current policy.json file is missing the copy_from policy in order
to be exhaustive.
DocImpact
Change-Id: Ibc0d1fa7626629c28c514514a985a6b89db2ac69
Closes-bug: #1258999
Add documentation for some parameters which can
be present in glance-api.conf:
* use_user_token
* admin_user
* admin_password
* admin_tenant_name
* auth_url
* auth_region
* auth_strategy
Fix for bug 1256952.
DocImpact
Change-Id: Ia5b731cabaec961f3a4226d30abd3bca9bd87651
There was no policy to control data upload.
Up until today, the add_image policy was a all or nothing, from metadata
to the actual data. Now, with the combination of add_image and upload_image
an administrator will have finer control over the whole chain.
Change-Id: I1a7966ffb5c63dd8239a54fe2963b031d9fe1f9a
Closes-bug: #1254521
Related to bug 1250918
There currently exists no check in set_data function for glance
api v2 in the policy layer. This patch adds upload_image policy.
DocImpact
Change-Id: Ibccc78f8bccff3baa5aca574cf17bd14c5403ca2
Now there is no image status transition diagram in the dev
doc, this patch will add one and keep the image source as
a dot file so that it can be updated easily in the future.
See http://www.graphviz.org to get more info about .dot file.
Fixes bug 1244995
Change-Id: I076c461f688be93eab8d3d1fa541990d7b79da5e
