glance-specs/specs/kilo/create-glance-manage-conf.rst

189 lines
5.4 KiB
ReStructuredText

..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
============================================
Create and Use ``glance-manage`` config file
============================================
https://blueprints.launchpad.net/glance/+spec/create-glance-manage-conf
``glance-manage`` currently uses the configuration files meant for
``glance-registry`` and ``glance-api``. This was ostensibly done to reduce the
number of places that an operator may need to add, update, or remove settings.
I would like to create a ``glance-manage.conf`` file to allow
``glance-manage`` to be independently configured.
Problem description
===================
If ``glance-api`` is started by a user (or service) but a different user tries
to use ``glance-manage`` they can encounter permissions errors if
``/var/log/glance/api.log`` is not writable to by the user trying to use
``glance-manage``. While this is one symptom of the dependence on the registry
and api configuration files, more may soon appear. Further, having separate
configuration files will allow end users and deployers to configure the tools
separately as well as use ``glance-manage`` on a node without requiring the
presence of both ``glance-api.conf`` and ``glance-registry.conf``.
See also `bug 1391211`_.
Proposed change
===============
I am proposing that we add another configuration file, ``glance-manage.conf``
to side-step this and any other issues we have with depending on the registry
and api's configuration files.
For Kilo, we will add the ``glance-manage.conf`` file and continue to load the
``glance-registry.conf`` and ``glance-api.conf`` files in the
``glance-manage`` command setup step. Currently the load order of
configuration files (which causes ``glance-manage`` to use
``/var/log/glance/api.log``) is:
- ``glance-registry.conf``
- ``glance-api.conf``
We will preserve this order and then load ``glance-manage.conf``. We will only
default to setting ``log_file`` in ``glance-manage.conf`` to prevent
overriding settings from the other two files. We will also issue a deprecation
warning pointing to this specification so that operators and end users know to
configure ``glance-manage.conf`` for a later cycle. In that cycle, we
will stop depending on ``glance-registry.conf`` and ``glance-api.conf``. The
documentation should also immediately, starting in the K cycle, begin to
instruct users to configure settings for ``glance-manage`` in
``glance-manage.conf``.
Alternatives
------------
One way we could address this would be to remove the default ``log_file``
values in Glance's configuration files. If we did this, all log files would
then be named ``/var/log/{{service}}/{{ command }}.log``, e.g.,
``/var/log/glance/glance-api.log`` would be the file used by ``glance-api``.
Changing this would not only break current documentation but also end user
expectations. Due to the considerable difference in behaviour without prior
warning, we decided to take the approach outlined in this specification
instead of using the same conventions as other projects.
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
This would introduce another file that would need to be edited by end users.
Some settings configured in ``glance-manage.conf`` may also be present in
``glance-registry.conf`` and ``glance-api.conf``. Any potential security
problems caused by needing to copy and synchronize settings between three
files are applicable here. Alternatively, since ``glance-manage`` can be
configured separately now, there will be no need to have the full API and
registry configuration files on a node in order to run ``glance-manage``.
Notifications impact
--------------------
None
Other end user impact
---------------------
This introduces another file with configuration options. Common configuration
options for will need to be copied and pasted from file-to-file and will need
attention to keep synchronized. This will likely increase the complexity of
maintaining an installation of Glance.
Performance Impact
------------------
None
Other deployer impact
---------------------
Deployers will be able to run ``glance-manage`` from nodes without needing
``glance-registry.conf`` or ``glance-api.conf`` to be present. This
specification does introduce another file that deployers need to be aware of
and know how to configure.
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
icordasc
Other contributors:
None
Reviewers
---------
Core reviewer(s):
nikhil-komawar
Other reviewer(s):
kragniz
jokke\_
Work Items
----------
- Generate a default ``glance-manage.conf`` as described above
- Begin loading it in ``glance-manage``
- Add deprecation messages regarding ``glance-registry.conf`` and
``glance-api.conf``.
- Update the documentation to describe how to configure ``glance-manage`` with
``glance-manage.conf``.
Dependencies
============
None
Testing
=======
We can test this by ensuring that a separate log file is generated for
``glance-manage``, i.e., ``/var/log/glance/manage.log`` is present after
running the command.
Documentation Impact
====================
This will require the changes to describe how to configure ``glance-manage``
to continue working as it has in the past.
References
==========
* https://bugs.launchpad.net/glance/+bug/1391211
.. _bug 1391211: https://bugs.launchpad.net/glance/+bug/1391211