By default, the config generator wraps the text in configuration files
at 70. This destroys the formatting of our help text strings.
To preserve the formatting, we wrap it at 80 just like we do for code.
Change-Id: I1a9aff4a4c7ea09a8136b3a26d9c22fb270d6226
Now when generating the config samples of Glance, glance-api.conf,
glance-glare.conf and glance-registry.conf will include duplicated
config options for osprofiler. It's because we're collecting
osprofiler's options at two places: etc/oslo-config-generator and
glance/opts.py. So to remove the duplication and keep consistenty
with the other options format, the patch removes the collecting
from etc/oslo-config-generator.
Change-Id: I45ef0bc8453cb8894dc245b8acf390b9ee0f6bfd
From: https://review.openstack.org/#/c/309346/
"
I investigated the behaviour of the policy file when various policies
are removed.
A completely empty policy file will return a 403 Forbidden. As the user
will not match with any of the policies.
However, because glance has the policy ``default: ""``. It means that
any policy that is not explicitly stated in the the policy.json, is
by default usable by any member. I think that the ``default`` option
is a potentially bad thing to have in the policy.json file, due to the
ability to give permissions without explicitly stating it.
"
Therefore we should change ``"default": "",`` to ``"default":
"role:admin",``. To make sure that members don't inherit policies that
they shouldn't in the future. From a operators perspective it should be
more secure to have an opt-in rather than opt-out.
Change-Id: I57f9d4791126360079a941c1ff4cb2bbb86298d5
Closes-Bug: 1593177
The HTTP_X_FORWARDED_PROTO handling fails to handle the case of
redirecting the /v1 request to /v1/ because it is handled purely by
routes and does not enter the glance wsgi code. This means a https
request is redirect to http and fails.
oslo.middleware has middleware for handling the X-Forwarded-Proto header
in a standard way so that services don't have to and so we should use
that instead of our own mechanism.
Leaving the existing header handling around until removal should not be
a problem as the worst that will happen is it overwrites an existing
'https' header value set by the middleware.
Closes-Bug: #1558683
Closes-Bug: #1590608
Change-Id: I481d88020b6e8420ce4b9072dd30ec82fe3fb4f7
Currently, the oslo config generator takes glance_store configs in
consideration while generating sample configs for the registry. Registry
doesn't really need these configs.
This patch removes the store config namespace from the oslo
config generator's setup to avoid regeneration of store section in
registry sample.
Sample configs have been regenerated using `tox -e genconfig` command to
make sure they reflect the change proposed. Only the
glance-registry.conf file has been refreshed as a part of this commit.
Closes-Bug: 1584350
Change-Id: I27c53d281dcd97a30c22a27c4833b24e1ca84f83
Starting with 1.0.0 osprofiler release options needed for
its workability are consolidated inside osprofiler itself.
Let's use them.
Change-Id: Ib0266e0a6e9bfa99c4bacbdca623ab1211a822eb
The option was used to enable experimental Artifacts API
that was moved to glance-glare service. This config option
does not do anything and is removed to avoid confusion.
Removed apropriate sections from example config files as well.
Change-Id: Ie84f3f65ec88fd30197758ac319ef5b2f4c313e2
Closes-bug: 1556050
This should be the last time reordering happening by the
configgenerator. In future we should see only actual changes but to get
there we need to do this massive change once more.
Closes-Bug: 1553330
Change-Id: Icca0a94a40ba640ca75e01b5cd0d061dacd334ff
Parameter 'use_user_token' in glance-api.conf
was considered as harmful and not acceptable
for real deployments, because if it's disabled,
it changes system behaviour and allows any regular
user to perform requests with admin credentials.
In functional tests the default value was set
to True to prevent possible failures in the future.
Besides, several admin authN parameters were
deprecated as well, because they are useless without
'use_user_token'.
All required information was added to related
documentation sections, sample config file was
updated as well.
https://wiki.openstack.org/wiki/OSSN/OSSN-0060
Change-Id: Icfef49d787fa58e2af2e60e4fdc96633c5f0c010
Related-bug: #1493448
The default values needed for glance's implementation of cors
middleware have been moved from paste.ini into the configuration
hooks provided by oslo.config. Furthermore, these values have been
added to glance's default configuration parsing. This ensures
that if a value remains unset in glance-api.conf, it will be set to use
sane defaults, and that an operator modifying the configuration
file will be presented with a default set of necessary sane headers.
Change-Id: I3c9d267b6224d6c7e5cc2c41cb51fb7e363c4955
Closes-Bug: 1551836
Adds into the Glance metadata definitions items from the Common
Information Model (CIM) schema, include setting data for processor
allocation, resource allocation, storage allocation and virtual
system, which can be associated with several OpenStack resources
to make them interoperable from a end-user specific perspective.
Implements: blueprint cim-namespace-metadata-definitions
Change-Id: If769bae8fcf1803bb2432537228f9633ad789e58
Supports import of OVA/OVF package to Glance by adding a new task to
the existing Glance import workflow. Automatically extracts single disk
image from OVA tarball and saves it to the Glance image store. It also
parses the included OVF file for interested metadata. Extracted
metadata is included as uploaded image's properties.
To kick off this flow, specify 'ova' as 'container_format' in the
task-create request. Specify interested metadata in the
'ovf-metadata.json' conf file, generally located at /etc/glance. Any
other additional metadata found in the OVF file will be ignored.
Currently this is an admin only feature and only supports upload of
single disk images. Also currently we will only be supporting extracting
properties from CIM_ProcessorAllocationSettingData.
Co-Authored-By: Jakub Jasek <jakubx.jasek@intel.com>
Co-Authored-By: Deepti Ramakrishna <deepti.ramakrishna@intel.com>
Change-Id: I4c9c9566895c2426f26d2750c8e2a23b39468fb1
Implements: blueprint ovf-lite
EXPERIMENTAL Glance v3 API has been removed in favor of standalone API
(EXPERIMENTAL Artifacts API of v0.1).
This patch introduces a new process entry point to run on a different
port (9494 by default), with its own configuration file and a paste
config.
A controller stub for old /v3 api remains in the glnace.api package for
the compatibility with existing paste configuration which may reference
it. This stub returns a 301 redirects to glare endpoint if it is present
or 410 errors otherwise.
To reuse the existing version_negotiation middleware some refactoring
has been made.
Implements blueprint: move-v3-to-glare
Change-Id: I5b7bd4cdcc5f2a40fc4a5f74bcc422fd700c4fb0
The metadata definitions in etc/metadefs allow each namespace to be associated
with a resource type in OpenStack. Now that Horizon is supporting adding
metadata to instances (just got in during the mitaka cycle - so unrealeased),
I realized that we used OS::Nova::Instance instead of OS::Nova::Server in
Glance. This doesn’t align with Heat [0] or Searchlight [1].
There are a couple of metadef files that have OS::Nova::Instance that need to
change to OS::Nova::Server. I see also that OS::Nova:Instance is in one of
the db scripts. That script simply adds some initial "resource types" to the
database. [3]. It should be noted that there is no hard dependency on that
resource type to be in the DB script. You can add new resource types at any
time via API or JSON files and they are automatically added.
I'm not sure if the change to the db script needs to be done in a different
patch or not, but that can easily be accommodated.
See bug for additional links.
Change-Id: I196ce1d9a62a61027ccd444b17a30b2c018d9c84
Closes-Bug: 1537903
One of the goals of this spec is to improve the image import process and
allow for other background operations to be executed when the image data
is added. This supersedes the need of the task endpoint that we'll
slowly deprecate. As part of this spec, we should make it admin only and
warn deployers that this API is going to be deprecated.
MitakaPriority
DocImpact: Tasks API is now admin only. Deployments depending on this
API need to make sure they make it accessible for non-admins.
Closes-bug: #1527716
Partially-blueprint: image-import-refactor
Change-Id: I28cb69ea730ae58b9aed1dd43b68305dbbf132c1
https://review.openstack.org/#/c/68421/ added support for
storage_policy in flavor extra_specs. This patch adds missing property
in glance metadef for VMware driver options for flavors.
Change-Id: I2f42e51676701d1427a62d5765141e4e586f52f1
There are several metadata definitions for software that are
associated with Nova instances (OS::Nova::Instance) which should
have their properties target set to "metadata".
The ability to add metadata to an instance leveraging these
definitions at launch time was recently added to horizon. In
a follow up discussion, somebody asked about using the metadata
definitions to also choose nova scheduler hints at launch time,
without confusing the two intended purposes of the metadata.
This raised our awareness that we don't have properties_target
set to "metadata" (rather than "scheduler hints") for
OS::Nova::Instance on the software metadata definition files.
This patch adds "properties_target": "metadata" to those files.
Change-Id: I247226ad78762d1d2add3bb39b1e780b93f36370
Closes-Bug: 1536849
The following Cinder patch adds support to specify Cinder volume type
via cinder_img_volume_type parameter in glance properties on image
metadata. The property should be added in the Metadata Definitions
catalog.
https://review.openstack.org/#/c/258649/
DocImpact: Add cinder_img_volume_type to Image service property
keys list at CLI reference.
http://docs.openstack.org/cli-reference/glance.html
Change-Id: I3bbb20fdf153e12b7461fa9ea9fa172a8d603093
Depends-On: I62f02d817d84d3a7b651db36d7297299b1af2fe3
Current description of instance-uuid may confuse users because
they may think that instance-uuid can serve as basis for image
but it just stores instance-uuid as image-metadata. So we need
to enhance the description in glanceclient.
Change-Id: I534709bdce588806178912fdd57fdf25bcca0449
Closes-Bug: #1496822
OSprofiler arguments do not have "profiler" group which makes
these config files wrong.
However they are used by DevStack, so this patch updates them
using:
tox -e genconfig
Change-Id: Ia18ec3e7b2e94d0a0ba6cb8562a0b457fb5ef406
Starting with opsrofiler 0.3.1 release there is no need to set HMAC_KEYS
and ENABLED arguments in the glance-api-paste.ini and
glance-registry-paste.ini files, this can be set in glance-api.conf and
glance-registry.conf configuration files.
DocImpact
Change-Id: I068504913c93be0f506262930eadc2e40879ce0f
This patch adds missing CPU features to Glance Metadata Catalog.
CPU features based on linux v4.4-rc4 kernel source code in
arch/x86/include/asm/cpufeature.h and picked up Intel&AMD vender.
Change-Id: I8c622172dbc1f7d80e606278064bea6f5bcb4c8f
Closes-Bug: #1409071
This adds the CORS support middleware to Glance, allowing a deployer
to optionally configure rules under which a javascript client may
break the single-origin policy and access the API directly.
For Glance, the paste.ini method of deploying the middleware was
chosen, because it needs to be able to annotate responses created
by keystonemiddleware. If the middleware were explicitly included
as in the previous patch, keystone would reject the request before
the cross-domain headers could be annotated, resulting in an
error response that was unreadable by the user agent.
A special consideration has been made to accomodate Glance's
nonstandard configuration files, by using 'glance-api' as the
value of oslo_config_project in paste.ini. This is to trigger
automatic oslo configuration loading for paste-loaded middleware,
in order to ensure that it finds glance-api.conf rather than
glance.conf.
DocImpact: Add link to CORS configuration in Admin Guide
OpenStack CrossProject Spec:
http://specs.openstack.org/openstack/openstack-specs/specs/cors-support.html
Oslo_Middleware Docs:
http://docs.openstack.org/developer/oslo.middleware/cors.html
OpenStack Cloud Admin Guide:
http://docs.openstack.org/admin-guide-cloud/cross_project_cors.html
Change-Id: Icf5fb91a0b9e6736e70314c72c1c99c5f170ba53
A Docker image is a tar archive typically containing a container
filesystem. In order to use the nova-docker compute driver nova and boot
docker instances glance support of the docker container format is
required.
This patch adds the Docker container format to the Glance configuration.
DocImpact: Docs will need to be updated to indicate that the docker
container_format is now one of the default container formats supported
by Glance.
UpgradeImpact: Adds 'docker' to the default list of container_formats.
Operators will no longer need to configure specifically to use docker
containers.
Closes-Bug: #1519402
Change-Id: Ifa206686086232a5599e7bc27a852bc5f3186ebc
For each image, when user clicks on Edit Image --> Update Metadata, the list
of various available metadata categories and properties is displayed in a
pop-up window. For each category and property, a user-friendly description is
displayed at the bottom of the pop-up.
The description for "Common Operating System Properties" category says - "When
adding an image to Glance, you may specify some common image properties that
may prove useful to consumers of your image." This is too generic and seems
like a copy-paste of the description from glance-common-image-props.json that
the author later failed to update.
Fixing this to show a more meaningful message.
Change-Id: I5477b1702932e07ab1fd499204d3ff1348abba3b
Closes-Bug: #1483063
Example configs were missing keystone_authtoken section after moving
to generated config files. This change returns that to generation.
Closes-Bug: #1500361
Change-Id: I6ee82c38061d483cea7254d155d9a72436880e84
Adding taskflow_executor_opts into the opts so they will be included.
Closes-bug: #1496012
Depends-On: I52ebf810f4699826baa2bdf91d28e24d902cf950
Change-Id: I9c0988a70f691482258f5f3ba9a5cf5601a81ddf
Prior to this change, images were being scrubbed serially while
the image locations, if multiple, were being scrubbed parallely.
For the general case, this may not achieve much performance gain as
the number of images is likely to be more than the number of image
locations per image. Hence, this change attempts to parallelize
image scrubbing while leaving image locations to be scrubbed
serially.
Also, though eventlet greenpool was being used, greening the world
wasn't done. As is, it's unlikely to achieve the intended gains. So,
this change also monkey patches essential python modules.
Finally, this change also makes the pool size configurable. This
offers the flexibility to choose between serial or parallel
scrubbing. Also, parallel scrubbing can be regulated to a desired
level by altering the pool size.
DocImpact
Implements: blueprint scrub-images-in-parallel
Change-Id: I5f18a70cd427e2c1e19a6bddeff317a46396eecc
The present default role of Keystone is _member_.
This change add _member_ to sample conf.
DocImpact
Change-Id: I4dbbbe53c491288a8596d828799a0dac253a1552
