Move non-prioritized Pike specs to 'untargeted'
Following discussion at the Glance virtual midcycle meeting, specs that were approved for Pike but whose owners are no longer available to work on them are to be moved to an 'untargeted' directory. Change-Id: I6da5d9ec49e60609173456456bb8635ada6dbdd2
This commit is contained in:
parent
77a7519479
commit
092f61e9f4
@ -65,67 +65,6 @@ Community Goal: Control Plane API endpoints deployment via WSGI
|
||||
End of `Community Goal: Control Plane API endpoints deployment via WSGI`
|
||||
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Introduce db sync --check feature
|
||||
---------------------------------
|
||||
|
||||
:problem: It is very hard for automation of deploy and upgrade operations to
|
||||
know if there are db migrations pending. It requires the automation
|
||||
to know what the latest version is, and compare that to the output
|
||||
of a command to check the current version, then interpret the
|
||||
potential difference somehow.
|
||||
|
||||
:solution: Similar to the linked feature added to Keystone's manage command,
|
||||
Glance should support an operation which enumerates any outstanding
|
||||
db upgrade operations and provide a distinct return code based on
|
||||
that status. Each expand, migrate, and contract operation required
|
||||
to upgrade the db should be listed in the proper order of execution
|
||||
in the response. For consistency with Keystone, this may be
|
||||
implemented by using a ``--check`` option. When this option is
|
||||
present no db upgrades would be performed but potential operations
|
||||
would be reported, acting similar to the pattern of a dry-run.
|
||||
|
||||
:impacts: Introduces new option to the db sync operation in glance-manage.
|
||||
|
||||
:timeline: Expected to be merged within the Pike time frame.
|
||||
|
||||
:link: https://bugs.launchpad.net/keystone/+bug/1642212
|
||||
|
||||
:assignee: Open
|
||||
|
||||
End of `Introduce db sync --check feature`
|
||||
++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Introduce Glance Taskflow stopfile feature
|
||||
------------------------------------------
|
||||
|
||||
:problem: When preparing to take a Glance node down for maintenance or upgrade
|
||||
it is necessary to allow long-running operations to complete without
|
||||
allowing new operations to begin. The Taskflow engine does not have
|
||||
the capability to prevent individual executors from starting new
|
||||
jobs, and so attempting to take a Glance node out of the Taskflow
|
||||
processing pool risks a race condition with that executor starting a
|
||||
job just before the service is terminated which could cause the Task
|
||||
processing to fail.
|
||||
|
||||
:solution: Introduce a disable_by_file_path feature to Glance Taskflow which
|
||||
will prevent the node from picking up new jobs. This allows an
|
||||
operator or automation engine to ``touch`` the appropriate file
|
||||
before terminating the service. This feature should depend on the
|
||||
oslo healthcheck middleware configuration to disable the taskflow
|
||||
engine. As an additional impact, this work will require Glance to
|
||||
instantiate a single taskflow engine as a singleton and reuse that
|
||||
engine instance on all subsequent taskflow operations.
|
||||
|
||||
:impacts: None
|
||||
|
||||
:timeline: Expected to have a fix merged in the Pike cycle before milestone 2.
|
||||
|
||||
:link: https://docs.openstack.org/developer/oslo.middleware/healthcheck_plugins.html
|
||||
|
||||
:assignee: Open
|
||||
|
||||
End of `Introduce Glance Taskflow stopfile feature`
|
||||
+++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Add your Spec Lite before this line
|
||||
===================================
|
||||
|
26
specs/untargeted/glance/lite-spec-db-sync-check.rst
Normal file
26
specs/untargeted/glance/lite-spec-db-sync-check.rst
Normal file
@ -0,0 +1,26 @@
|
||||
Lite Spec: Introduce db sync --check feature
|
||||
--------------------------------------------
|
||||
|
||||
:problem: It is very hard for automation of deploy and upgrade operations to
|
||||
know if there are db migrations pending. It requires the automation
|
||||
to know what the latest version is, and compare that to the output
|
||||
of a command to check the current version, then interpret the
|
||||
potential difference somehow.
|
||||
|
||||
:solution: Similar to the linked feature added to Keystone's manage command,
|
||||
Glance should support an operation which enumerates any outstanding
|
||||
db upgrade operations and provide a distinct return code based on
|
||||
that status. Each expand, migrate, and contract operation required
|
||||
to upgrade the db should be listed in the proper order of execution
|
||||
in the response. For consistency with Keystone, this may be
|
||||
implemented by using a ``--check`` option. When this option is
|
||||
present no db upgrades would be performed but potential operations
|
||||
would be reported, acting similar to the pattern of a dry-run.
|
||||
|
||||
:impacts: Introduces new option to the db sync operation in glance-manage.
|
||||
|
||||
:timeline: Expected to be merged within the Pike time frame.
|
||||
|
||||
:link: https://bugs.launchpad.net/keystone/+bug/1642212
|
||||
|
||||
:assignee: Open
|
28
specs/untargeted/glance/lite-spec-task-stopfile.rst
Normal file
28
specs/untargeted/glance/lite-spec-task-stopfile.rst
Normal file
@ -0,0 +1,28 @@
|
||||
Lite Spec: Introduce Glance Taskflow stopfile feature
|
||||
-----------------------------------------------------
|
||||
|
||||
:problem: When preparing to take a Glance node down for maintenance or upgrade
|
||||
it is necessary to allow long-running operations to complete without
|
||||
allowing new operations to begin. The Taskflow engine does not have
|
||||
the capability to prevent individual executors from starting new
|
||||
jobs, and so attempting to take a Glance node out of the Taskflow
|
||||
processing pool risks a race condition with that executor starting a
|
||||
job just before the service is terminated which could cause the Task
|
||||
processing to fail.
|
||||
|
||||
:solution: Introduce a disable_by_file_path feature to Glance Taskflow which
|
||||
will prevent the node from picking up new jobs. This allows an
|
||||
operator or automation engine to ``touch`` the appropriate file
|
||||
before terminating the service. This feature should depend on the
|
||||
oslo healthcheck middleware configuration to disable the taskflow
|
||||
engine. As an additional impact, this work will require Glance to
|
||||
instantiate a single taskflow engine as a singleton and reuse that
|
||||
engine instance on all subsequent taskflow operations.
|
||||
|
||||
:impacts: None
|
||||
|
||||
:timeline: Expected to have a fix merged in the Pike cycle before milestone 2.
|
||||
|
||||
:link: https://docs.openstack.org/developer/oslo.middleware/healthcheck_plugins.html
|
||||
|
||||
:assignee: Open
|
@ -18,13 +18,13 @@ on implementing one of these specs.
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
.. Approved untargeted specs for Glance:
|
||||
Approved untargeted specs for Glance:
|
||||
|
||||
.. .. toctree::
|
||||
.. :glob:
|
||||
.. :maxdepth: 1
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
.. glance/*
|
||||
glance/*
|
||||
|
||||
.. Approved untargeted specs for glance_store:
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user