Jump to: navigation, search

Difference between revisions of "Scheduled-images-service"

Line 9: Line 9:
  
 
Service responsibilities include:
 
Service responsibilities include:
* Allow creation, deletion, and listing of tasks
+
* Allow creation, deletion, and listing of schedules
 
* Determine specific schedules with regards to load balancing
 
* Determine specific schedules with regards to load balancing
* Handle rescheduling failed tasks
+
* Handle rescheduling failed jobs
 
* Maintain persistant schedules
 
* Maintain persistant schedules
* Removal of images outside of retention period
+
* Removal of images outside of rotation count
  
 
== Release Note ==
 
== Release Note ==
 
This section should include a paragraph describing the end-user impact of this change.  It is meant to be included in the release notes of the first release in which it is implemented.  (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)
 
 
It is mandatory.
 
  
 
== Rationale ==
 
== Rationale ==
Line 66: Line 62:
 
The service shall consist of a set of apis, worker nodes, and a DB.
 
The service shall consist of a set of apis, worker nodes, and a DB.
  
API - Provides a RESTful interface for adding tasks to the DB
+
API - Provides a RESTful interface for adding schedules to the DB
  
Worker - References tasks in the DB to schedule and perform periodic jobs
+
Worker - References schedules in the DB to schedule and perform jobs
  
DB - Tracks task schedules and currently executing tasks
+
DB - Tracks schedules and currently executing jobs
  
 
== Implementation ==
 
== Implementation ==
Line 100: Line 96:
  
 
=== Migration ===
 
=== Migration ===
 
Include:
 
* data migration, if any
 
* redirects from old URLs to new ones, if any
 
* how users will be pointed to the new way of doing things, if necessary.
 
  
 
== Test/Demo Plan ==
 
== Test/Demo Plan ==
 
This need not be added or completed until the specification is nearing beta.
 
  
 
== Unresolved issues ==
 
== Unresolved issues ==
 
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
 
  
 
== BoF agenda and discussion ==
 
== BoF agenda and discussion ==
 
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
 
  
 
----
 
----
 
[[Category:Spec]]
 
[[Category:Spec]]

Revision as of 19:19, 30 October 2012

  • Launchpad Entry: GlanceSpec:scheduled-iamges-service
  • Created: 29 Oct 2012
  • Contributors: Alex Meade, Eddie Sheffield

Summary

This blueprint introduces a new service and Nova API extension for scheduling daily snapshots of an instance.

Service responsibilities include:

  • Allow creation, deletion, and listing of schedules
  • Determine specific schedules with regards to load balancing
  • Handle rescheduling failed jobs
  • Maintain persistant schedules
  • Removal of images outside of rotation count

Release Note

Rationale

User stories

Assumptions

Design

API Extension

Create Backup Schedule POST /servers/<id>/backup_schedule

{ "rotation": INT }

Rotation: Specifies the number of recent backups to keep for an instance. If a schedule already exists for an instance, it is overridden.

Delete Backup Schedule DELETE /servers/<id>/backup_schedule

Show Backup Schedule GET /servers/<id>/backup_schedule

Response Body: {

"instance": <UUID>,
"rotation": INT,

}

List All Backup Schedules of a Tenant GET /servers/backup_schedules

Response Body: [ {

"instance": <UUID>,
"rotation": INT,

}, ]

Service

The service shall consist of a set of apis, worker nodes, and a DB.

API - Provides a RESTful interface for adding schedules to the DB

Worker - References schedules in the DB to schedule and perform jobs

DB - Tracks schedules and currently executing jobs

Implementation

Typical flow of the system is as follows.

  1. User makes request to Nova extension
  2. Nova extension passes request to API
  3. API picks time of day to schedule
  4. Adds schedule entry to DB
  5. Worker polls DB for schedules needing action
  6. Worker creates job entry in DB
  7. Worker initiates image snapshot
  8. Worker waits for completion while updating 'last_touched' field in the job table (to indicate the Worker has not died)
  9. Worker updates DB to show the job has been completed
  10. Worker polls until a schedule needs action

Edge cases:

Worker dies in middle of job:

  • A different worker will see the job has not been updated in awhile and take over, performing any cleanup it can.
  • Jobs contain information of where they left off and what image they were working on (this allows a job whose worker died in the middle of an upload to be resumed)

Image upload fails

  • Retry a certain number of times, afterwards leave image in error state

Instance no longer exists

  • Remove schedule for instance

Migration

Test/Demo Plan

Unresolved issues

BoF agenda and discussion