From 092f61e9f40e862885ba3ff590a28b057706fef7 Mon Sep 17 00:00:00 2001 From: Brian Rosmaita Date: Wed, 31 May 2017 20:50:44 -0400 Subject: [PATCH] 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 --- specs/pike/approved/glance/lite-specs.rst | 61 ------------------- .../glance/lite-spec-db-sync-check.rst | 26 ++++++++ .../glance/lite-spec-task-stopfile.rst | 28 +++++++++ specs/untargeted/index.rst | 10 +-- 4 files changed, 59 insertions(+), 66 deletions(-) create mode 100644 specs/untargeted/glance/lite-spec-db-sync-check.rst create mode 100644 specs/untargeted/glance/lite-spec-task-stopfile.rst diff --git a/specs/pike/approved/glance/lite-specs.rst b/specs/pike/approved/glance/lite-specs.rst index 7b494ac1..09a4e215 100644 --- a/specs/pike/approved/glance/lite-specs.rst +++ b/specs/pike/approved/glance/lite-specs.rst @@ -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 =================================== diff --git a/specs/untargeted/glance/lite-spec-db-sync-check.rst b/specs/untargeted/glance/lite-spec-db-sync-check.rst new file mode 100644 index 00000000..eff9c9a5 --- /dev/null +++ b/specs/untargeted/glance/lite-spec-db-sync-check.rst @@ -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 diff --git a/specs/untargeted/glance/lite-spec-task-stopfile.rst b/specs/untargeted/glance/lite-spec-task-stopfile.rst new file mode 100644 index 00000000..3cc0c272 --- /dev/null +++ b/specs/untargeted/glance/lite-spec-task-stopfile.rst @@ -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 diff --git a/specs/untargeted/index.rst b/specs/untargeted/index.rst index 53c5b57f..6f61f136 100644 --- a/specs/untargeted/index.rst +++ b/specs/untargeted/index.rst @@ -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: