openstack
/
glance
Code Issues Proposed changes

Merge "[Doc] Remove description about v1 api and glance-registry"

This commit is contained in:
Zuul 2020-12-17 17:42:57 +00:00 committed by Gerrit Code Review
parent 8027d90710 81c6d4d678
commit e2cbac36f1
9 changed files with 39 additions and 343 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
doc/source/admin/authentication.rst
View File

@ -33,16 +33,13 @@ Configuring the Glance servers to use Keystone
----------------------------------------------
Keystone is integrated with Glance through the use of middleware. The
default configuration files for both the Glance API and the Glance
Registry use a single piece of middleware called ``unauthenticated-context``,
which generates a request context containing blank authentication
information. In order to configure Glance to use Keystone, the
``authtoken`` and ``context`` middlewares must be deployed in place of the
``unauthenticated-context`` middleware. The ``authtoken`` middleware performs
the authentication token validation and retrieves actual user authentication
information. It can be found in the Keystone distribution.
.. include:: ../deprecate-registry.inc
default configuration file for the Glance API uses a single piece of middleware
called ``unauthenticated-context``, which generates a request context
containing blank authentication information. In order to configure Glance to
use Keystone, the ``authtoken`` and ``context`` middlewares must be deployed in
place of the ``unauthenticated-context`` middleware. The ``authtoken``
middleware performs the authentication token validation and retrieves actual
user authentication information. It can be found in the Keystone distribution.
Configuring Glance API to use Keystone
@ -90,27 +87,3 @@ with ``authtoken`` and ``context``::
[pipeline:glance-api]
pipeline = versionnegotiation authtoken context apiv1app
Configuring Glance Registry to use Keystone
-------------------------------------------
.. include:: ../deprecate-registry.inc
Configuring Glance Registry to use Keystone is also relatively
straight forward. The same middleware needs to be added
to ``glance-registry-paste.ini`` as was needed by Glance API;
see above for an example of the ``authtoken`` configuration.
Again, to enable using Keystone authentication, the appropriate
application pipeline must be selected. By default, it looks like::
[pipeline:glance-registry-keystone]
pipeline = authtoken context registryapp
To enable the above application pipeline, in your main ``glance-registry.conf``
configuration file, select the appropriate deployment flavor by adding a
``flavor`` attribute in the ``paste_deploy`` group::
[paste_deploy]
flavor = keystone

1
doc/source/admin/cache.rst
View File

@ -74,7 +74,6 @@ correctly.
store, points to where the data is kept.
- ``filesystem_store_datadirs`` This is used to point to multiple
filesystem stores.
- ``registry_host`` The URL to the Glance registry.
- ``cache_prefetcher_interval`` The interval in seconds to run periodic
job 'cache_images'.

5
doc/source/admin/controllingservers.rst
View File

@ -22,9 +22,6 @@ Controlling Glance Servers
This section describes the ways to start, stop, and reload Glance's server
programs.
.. include:: ../deprecate-registry.inc
Starting a server
-----------------
@ -80,8 +77,6 @@ in a shell.::
2011-04-13 14:50:12 DEBUG [glance-api] debug True
2011-04-13 14:50:12 DEBUG [glance-api] default_store file
2011-04-13 14:50:12 DEBUG [glance-api] filesystem_store_datadir /home/jsuh/images/
2011-04-13 14:50:12 DEBUG [glance-api] registry_host 65.114.169.29
2011-04-13 14:50:12 DEBUG [glance-api] registry_port 9191
2011-04-13 14:50:12 DEBUG [glance-api] ********************************************************************************
2011-04-13 14:50:12 DEBUG [routes.middleware] Initialized with method overriding = True, and path info altering = True
2011-04-13 14:50:12 DEBUG [eventlet.wsgi.server] (21354) wsgi starting up on http://65.114.169.29:9292/

54
doc/source/admin/property-protections.rst
View File

@ -98,57 +98,3 @@ operations.
A successful HTTP request will return status ``200 OK``. If the user is not
permitted to perform the requested action, ``403 Forbidden`` will be returned.
V1 API X-glance-registry-Purge-props
------------------------------------
.. include:: ../deprecate-registry.inc
Property protections will still be honoured if
``X-glance-registry-Purge-props`` is set to ``True``. That is, if you request
to modify properties with this header set to ``True``, you will not be able to
delete or update properties for which you do not have the relevant permissions.
Properties which are not included in the request and for which you do have
delete permissions will still be removed.
Examples
--------
**Example 1**. Limit all property interactions to admin only.
::
[.*]
create = admin
read = admin
update = admin
delete = admin
**Example 2**. Allow both admins and users with the billing role to read
and modify properties prefixed with ``x_billing_code_``. Allow admins to
read and modify any properties.
::
[^x_billing_code_.*]
create = admin,billing
read = admin, billing
update = admin,billing
delete = admin,billing
[.*]
create = admin
read = admin
update = admin
delete = admin
**Example 3**. Limit all property interactions to admin only using policy
rule context_is_admin defined in policy.json.
::
[.*]
create = context_is_admin
read = context_is_admin
update = context_is_admin
delete = context_is_admin

255
doc/source/configuration/configuring.rst
View File

@ -20,13 +20,9 @@ Basic Configuration
===================
Glance has a number of options that you can use to configure the Glance API
server, the Glance Registry server, and the various storage backends that
Glance can use to store images.
server and the various storage backends that Glance can use to store images.
.. include:: ../deprecate-registry.inc
Most configuration is done via configuration files, with the Glance API
server and Glance Registry server using separate configuration files.
Most configuration is done via configuration files.
When starting up a Glance server, you can specify the configuration file to
use (see :ref:`the documentation on controller Glance servers
@ -40,12 +36,10 @@ in order:
* ``/etc``
The Glance API server configuration file should be named ``glance-api.conf``.
Similarly, the Glance Registry server configuration file should be named
``glance-registry.conf``. There are many other configuration files also
since Glance maintains a configuration file for each of its services. If you
installed Glance via your operating system's package management system, it
is likely that you will have sample configuration files installed in
``/etc/glance``.
There are many other configuration files also since Glance maintains a
configuration file for each of its services. If you installed Glance via your
operating system's package management system, it is likely that you will have
sample configuration files installed in ``/etc/glance``.
In addition, sample configuration files for each server application with
detailed comments are available in the :ref:`Glance Sample Configuration
@ -98,8 +92,7 @@ Glance has a few command-line options that are common to all Glance programs:
* ``/etc``
The filename that is searched for depends on the server application name. So,
if you are starting up the API server, ``glance-api.conf`` is searched for,
otherwise ``glance-registry.conf``.
if you are starting up the API server, ``glance-api.conf`` is searched for.
``--config-dir=DIR``
Optional. Default: ``None``
@ -130,7 +123,6 @@ Glance has a few command-line options that are common to all Glance programs:
Note that ``glance-manage`` currently loads configuration from three files:
* ``glance-registry.conf``
* ``glance-api.conf``
* ``glance-manage.conf``
@ -138,19 +130,14 @@ Glance has a few command-line options that are common to all Glance programs:
other configuration options for ``glance-manage`` should be migrated
in there.
**Warning**: Options set in ``glance-manage.conf`` will override options of
the same section and name set in the other two. Similarly, options in
``glance-api.conf`` will override options set in ``glance-registry.conf``.
This tool is planning to stop loading ``glance-registry.conf`` and
``glance-api.conf`` in a future cycle.
the same section and name set in ``glance-api.conf``
Configuring Server Startup Options
----------------------------------
You can put the following options in the ``glance-api.conf`` and
``glance-registry.conf`` files, under the ``[DEFAULT]`` section. They enable
startup and binding behaviour for the API and registry servers, respectively.
.. include:: ../deprecate-registry.inc
You can put the following options in the ``glance-api.conf`` file, under
the ``[DEFAULT]`` section. They enable startup and binding behaviour for
the API servers, respectively.
``bind_host=ADDRESS``
The address of the host to bind to.
@ -160,8 +147,7 @@ startup and binding behaviour for the API and registry servers, respectively.
``bind_port=PORT``
The port the server should bind to.
Optional. Default: ``9191`` for the registry server, ``9292`` for
the API server
Optional. Default: ``9292`` for the API server
``backlog=REQUESTS``
Number of backlog requests to configure the socket with.
@ -182,13 +168,12 @@ startup and binding behaviour for the API and registry servers, respectively.
Optional. Default: ``900``
``workers=PROCESSES``
Number of Glance API or Registry worker processes to start. Each worker
process will listen on the same port. Increasing this value may increase
performance (especially if using SSL with compression enabled). Typically
it is recommended to have one worker process per CPU. The value `0`
will prevent any new worker processes from being created. When ``data_api``
is set to ``glance.db.simple.api``, ``workers`` MUST be set to either ``0``
or ``1``.
Number of Glance API worker processes to start. Each worker process will
listen on the same port. Increasing this value may increase performance
(especially if using SSL with compression enabled). Typically it is
recommended to have one worker process per CPU. The value `0` will prevent
any new worker processes from being created. When ``data_api`` is set to
``glance.db.simple.api``, ``workers`` MUST be set to either ``0`` or ``1``.
Optional. Default: The number of CPUs available will be used by default.
@ -220,125 +205,6 @@ Configuring SSL Support
Optional. Default: not enabled.
Configuring Registry Access
~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are a number of configuration options in Glance that control how
the API server accesses the registry server.
.. include:: ../deprecate-registry.inc
``registry_client_protocol=PROTOCOL``
If you run a secure Registry server, you need to set this value to ``https``
and also set ``registry_client_key_file`` and optionally
``registry_client_cert_file``.
Optional. Default: http
``registry_client_key_file=PATH``
The path to the key file to use in SSL connections to the
registry server, if any. Alternately, you may set the
``GLANCE_CLIENT_KEY_FILE`` environ variable to a filepath of the key file
Optional. Default: Not set.
``registry_client_cert_file=PATH``
Optional. Default: Not set.
The path to the cert file to use in SSL connections to the
registry server, if any. Alternately, you may set the
``GLANCE_CLIENT_CERT_FILE`` environ variable to a filepath of the cert file
``registry_client_ca_file=PATH``
Optional. Default: Not set.
The path to a Certifying Authority's cert file to use in SSL connections
to the registry server, if any. Alternately, you may set the
``GLANCE_CLIENT_CA_FILE`` environ variable to a filepath of the CA cert file
``registry_client_insecure=False``
Optional. Default: False.
When using SSL in connections to the registry server, do not require
validation via a certifying authority. This is the registry's equivalent of
specifying --insecure on the command line using glanceclient for the API
``registry_client_timeout=SECONDS``
Optional. Default: ``600``.
The period of time, in seconds, that the API server will wait for a registry
request to complete. A value of '0' implies no timeout.
.. note::
``use_user_token``, ``admin_user``, ``admin_password``,
``admin_tenant_name``, ``auth_url``, ``auth_strategy`` and ``auth_region``
options were considered harmful and have been deprecated in M release.
They will be removed in O release. For more information read
`OSSN-0060 <https://wiki.openstack.org/wiki/OSSN/OSSN-0060>`_.
Related functionality with uploading big images has been implemented with
Keystone trusts support.
``use_user_token=True``
Optional. Default: True
DEPRECATED. This option will be removed in O release.
Pass the user token through for API requests to the registry.
If 'use_user_token' is not in effect then admin credentials can be
specified (see below). If admin credentials are specified then they are
used to generate a token; this token rather than the original user's
token is used for requests to the registry.
``admin_user=USER``
DEPRECATED. This option will be removed in O release.
If 'use_user_token' is not in effect then admin credentials can be
specified. Use this parameter to specify the username.
Optional. Default: None
``admin_password=PASSWORD``
DEPRECATED. This option will be removed in O release.
If 'use_user_token' is not in effect then admin credentials can be
specified. Use this parameter to specify the password.
Optional. Default: None
``admin_tenant_name=TENANTNAME``
DEPRECATED. This option will be removed in O release.
If 'use_user_token' is not in effect then admin credentials can be
specified. Use this parameter to specify the tenant name.
Optional. Default: None
``auth_url=URL``
DEPRECATED. This option will be removed in O release.
If 'use_user_token' is not in effect then admin credentials can be
specified. Use this parameter to specify the Keystone endpoint.
Optional. Default: None
``auth_strategy=STRATEGY``
DEPRECATED. This option will be removed in O release.
If 'use_user_token' is not in effect then admin credentials can be
specified. Use this parameter to specify the auth strategy.
Optional. Default: noauth
``auth_region=REGION``
DEPRECATED. This option will be removed in O release.
If 'use_user_token' is not in effect then admin credentials can be
specified. Use this parameter to specify the region.
Optional. Default: None
Configuring Logging in Glance
-----------------------------
@ -1598,56 +1464,6 @@ One main configuration file option affects the image cache.
designed to be run via cron on a regular basis. See more about this
executable in :ref:`Controlling the Growth of the Image Cache <image-cache>`
.. _configuring-the-glance-registry:
Configuring the Glance Registry
-------------------------------
There are a number of configuration options in Glance that control how
this registry server operates. These configuration options are specified in the
``glance-registry.conf`` configuration file in the section ``[DEFAULT]``.
**IMPORTANT NOTE**: The glance-registry service is only used in conjunction
with the glance-api service when clients are using the v1 REST API. See
`Configuring Glance APIs`_ for more info.
``sql_connection=CONNECTION_STRING``
Optional. Default: ``None``
Can be specified in configuration files. Can also be specified on the
command-line for the ``glance-manage`` program.
Sets the SQLAlchemy connection string to use when connecting to the registry
database. Please see the documentation for
`SQLAlchemy connection strings <http://docs.sqlalchemy.org/en/latest/core/connections.html>`_
online. You must urlencode any special characters in CONNECTION_STRING.
Use ``--sql-connection`` when specified on command line.
``sql_timeout=SECONDS``
Optional. Default: ``3600``
Can only be specified in configuration files.
Sets the number of seconds after which SQLAlchemy should reconnect to the
datastore if no activity has been made on the connection.
``enable_v1_registry=<True|False>``
Optional and DEPRECATED. Default: ``True``
``enable_v2_registry=<True|False>``
Optional and DEPRECATED. Default: ``True``
.. include:: ../deprecate-registry.inc
Defines which version(s) of the Registry API will be enabled.
If the Glance API server parameter ``enable_v1_api`` has been set to ``True``
the ``enable_v1_registry`` has to be ``True`` as well.
If the Glance API server parameter ``enable_v2_api`` has been
set to ``True`` and the parameter ``data_api`` has been set to
``glance.db.registry.api`` the ``enable_v2_registry`` has to be
set to ``True``
Configuring Notifications
-------------------------
@ -1701,18 +1517,8 @@ specified, glance API service will not start.**
Configuring Glance APIs
-----------------------
The glance-api service implements versions 1 and 2 of
the OpenStack Images API. Disable any version of
the Images API using the following options:
``enable_v1_api=<True|False>``
Optional. Default: ``True``
``enable_v2_api=<True|False>``
Optional. Default: ``True``
**IMPORTANT NOTE**: To use v2 registry in v2 API, you must set
``data_api`` to glance.db.registry.api in glance-api.conf.
The glance-api service implements versions 2 of the OpenStack Images API.
Currently there are no options to enable or disable specific API versions.
Configuring Glance Tasks
------------------------
@ -1757,7 +1563,7 @@ execution profiling at wsgi main entry and SQL execution profiling at DB
module, the more fine-grained trace point is being worked on.
The config value ``enabled`` is used to determine whether fully enable
profiling feature for glance-api and glance-registry service.
profiling feature for glance-api service.
``enabled=<True|False>``
Optional. Default: ``False``
@ -1775,15 +1581,14 @@ profiling feature for glance-api and glance-registry service.
even profiling feature is enabled.
**IMPORTANT NOTE**: previously HMAC keys (as well as enabled parameter) were
placed at `/etc/glance/api-paste.ini` and `/etc/glance/registry-paste.ini`
files for Glance API and Glance Registry services respectively. Starting with
osprofiler 0.3.1 release there is no need to set these arguments in the
`*-paste.ini` files. This functionality is still supported, although the
config values are having larger priority.
placed at `/etc/glance/api-paste.ini` file for Glance API service
respectively. Starting with osprofiler 0.3.1 release there is no need to set
these arguments in the `*-paste.ini` files. This functionality is still
supported, although the config values are having larger priority.
The config value ``trace_sqlalchemy`` is used to determine whether fully
enable sqlalchemy engine based SQL execution profiling feature for glance-api
and glance-registry services.
service.
``trace_sqlalchemy=<True|False>``
Optional. Default: ``False``
@ -1834,15 +1639,15 @@ Configuring the Health Check
This setting allows an operator to configure the endpoint URL that will
provide information to load balancer if given API endpoint at the node should
be available or not. Both Glance API and Glance Registry servers can be
configured to expose a health check URL.
be available or not. Glance API server can be configured to expose a health
check URL.
To enable the health check middleware, it must occur in the beginning of the
application pipeline.
The health check middleware should be placed in your
``glance-api-paste.ini`` / ``glance-registry-paste.ini`` in a section
titled ``[filter:healthcheck]``. It should look like this::
``glance-api-paste.ini`` in a section titled ``[filter:healthcheck]``.
It should look like this::
[filter:healthcheck]
paste.filter_factory = oslo_middleware:Healthcheck.factory

2
doc/source/contributor/architecture.rst
View File

@ -81,5 +81,3 @@ Following components are present in the Glance architecture:
* **Registry Layer** - optional layer that is used to organise secure
communication between the domain and the DAL by using a separate service.
.. include:: ../deprecate-registry.inc

5
doc/source/contributor/domain_implementation.rst
View File

@ -41,8 +41,8 @@ their locations:
which are above the domain implementation. The Auth, Property
Protection (optional), Notifier, Policy, Quota,
Location, and Database represent the domain implementation.
The Registry (optional) and Data Access sit below the domain
implementation. Further, the Client block calls the Router;
The Data Access sit below the domain implementation. Further,
the Client block calls the Router;
the Location block calls the Glance Store, and the Data Access
layer calls the DBMS.
Additional information conveyed in the image is the location in
@ -56,7 +56,6 @@ their locations:
Quota: quota/__init__.py
Location: location.py
DB: db/__init__.py
Registry: registry/v2/*
Data Access: db/sqlalchemy/api.py
.. _authorization:

8
doc/source/deprecate-registry.inc
View File

@ -1,8 +0,0 @@
.. note:: The Glance Registry Service and its APIs have been DEPRECATED in
the Queens release and are subject to removal at the beginning of the
'S' development cycle, following the `OpenStack standard deprecation policy
<https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html>`_.
For more information, see the Glance specification document `Actually
Deprecate the Glance Registry
<http://specs.openstack.org/openstack/glance-specs/specs/queens/approved/glance/deprecate-registry.html>`_.

11
doc/source/install/get-started.rst
View File

@ -53,17 +53,6 @@ glance-api
.. _`Control Plane API endpoints deployment via WSGI`: https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
.. _`Glance Release Notes`: https://docs.openstack.org/releasenotes/glance/index.html
glance-registry
Stores, processes, and retrieves metadata about images. Metadata
includes items such as size and type.
.. warning::
The registry is a private internal service meant for use by
OpenStack Image service. Do not expose this service to users.
.. include:: ../deprecate-registry.inc
Database
Stores image metadata and you can choose your database depending on
your preference. Most deployments use MySQL or SQLite.