Bug 1041034

Summary: [RFE][nova]: Add pre-caching to nova image cache management
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: low Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/nova/+spec/nova-image-cache-management-2
Whiteboard: upstream_milestone_none upstream_status_started upstream_definition_obsolete
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:39:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 13:27:55 UTC 
Cloned from launchpad blueprint https://blueprints.launchpad.net/nova/+spec/nova-image-cache-management-2.

Description:

This blueprint continues on from https://blueprints.launchpad.net/nova/+spec/nova-image-cache-management and adds the pre-caching of popular images. That specification is found under the previous blueprint.

Features to implement:

Faster startup for instances
=================

This should consider the relative popularity of various images (which can be done now without a call to glance). The original specification also considers that cloud hosts might want to have their own images load as fast as possible, but not care so much about pre-caching user uploaded images.

Resiliance to glance failure
================

Some way of designating images as being "mission critical" so that they're pre-cached. This way, if glance is offline an instance can still be started. This designation needs to avoid calling into glance as much as possible.

Schedule new instances on nodes which already have the right image
===========================================

Instance startup will be faster if an instance is started on a node which already has the image cached. Its even better if there is already a resized COW target image of the right size on the node as well. Not only will startup be faster, but disk usage will be used across the cluster.

This needs to respect that users almost certainly don't want all instances of a given type on a single compute node, as if that node fails they'd lose all of the instances. There therefore needs to be some sanity checking applied to this code.

Specification URL (additional information):

None