Jump to: navigation, search

Difference between revisions of "Persistent resource claim"

(Data Structure)
Line 7: Line 7:
  
 
==== Data Structure ====
 
==== Data Structure ====
claim object:
+
* claim object:
uuid: ID of the claim
+
* Bulleted list item
host: the host that support this claims
+
* uuid: ID of the claim
owner_type: The utility type of the resource claim owner, support 'server' only now..
+
* host: the host that support this claims
owner_id: The ID of the resource claim owner. Support only insance_uuid now.
+
* owner_type: The utility type of the resource claim owner, support 'server' only now..
vcpu: the vcpu number
+
* owner_id: The ID of the resource claim owner. Support only insance_uuid now.
memory: the MB of memory claimed
+
* vcpu: the vcpu number
disk: the GB of disk claimed.
+
* memory: the MB of memory claimed
pci: A json blob of the PCI devices claimed (Nullable)
+
* disk: the GB of disk claimed.
extra_resource: A json blob for other resource types (Nullable)
+
* pci: A json blob of the PCI devices claimed (Nullable)
tag: A tag provided by the caller and will be utilized/interpreted by the caller.
+
* extra_resource: A json blob for other resource types (Nullable)
 +
* tag: A tag provided by the caller and will be utilized/interpreted by the caller.
  
DB:
+
==== DB ====
A claims table will be created to keep all claims for an instance.  
+
* A claims table will be created to keep all claims for an instance.  
It's an option to keep the claim information in the instance table (like through system metadata), but I'd prefer a separated table.
+
:It's an option to keep the claim information in the instance table (like through system metadata), but I'd prefer a separated table.
  
 
==== API ====
 
==== API ====

Revision as of 06:56, 15 February 2014

Summary

When a resource claim happens through instance_claim() or resize_claim() request, the compute resource tracker will get the COMPUTE_RESOURCE_SEMAPHORE, allocate the resource, persistent the allocation result, or claim, in the DB, then return the ID of the claims.

When a resource is put back to compute resource tracker through drop_resize_claim() or abort_instance_claim(), the claim (or simply claim ID) will be passed into the resource tracker, to free the resource.

Implementation Plan

Data Structure

  • claim object:
  • Bulleted list item
  • uuid: ID of the claim
  • host: the host that support this claims
  • owner_type: The utility type of the resource claim owner, support 'server' only now..
  • owner_id: The ID of the resource claim owner. Support only insance_uuid now.
  • vcpu: the vcpu number
  • memory: the MB of memory claimed
  • disk: the GB of disk claimed.
  • pci: A json blob of the PCI devices claimed (Nullable)
  • extra_resource: A json blob for other resource types (Nullable)
  • tag: A tag provided by the caller and will be utilized/interpreted by the caller.

DB

  • A claims table will be created to keep all claims for an instance.
It's an option to keep the claim information in the instance table (like through system metadata), but I'd prefer a separated table.

API

claim operation:

get_claims_for_instance(instance_uuid): return the claims for instance. get_claims_for_host(host): return the claims for the host.


Changes to resource tracker API

instance_claim/resize_claim:

   Add a step to sync the claim information to DB
   Consideration:  Does it matter of the sequence of sync claims and sync compute node? Seems should not matter because we are in lock.

update_available_resource:

   This function may changes a lot.  Resource tracker get resource information from hypervisor, and then get all claims from DB, and update the available resource by deduct the claims from the resource information from hypervisor, and deduct the information from orphan insance.
   Question: Should we create the claims in DB for the orphan instance? I assume should not.

Benefit

Persistent the resource claim enables several potential benefit:

  • It will be easy to check the resource usage for all instance, all host, etc.
  • We can move the migration object creation out of the resource tracker, by having the conductor to claim the resource in source/target host and then create the conductor.
  • We can move the _set_instance_host_and_node out of the resource tracker, by having the conductor to claim the resource and then set the host node.
  • After move migration objection creation out of the resource tracker, resource tracker don't need understand the migration process anymore and we can combine the instance_claim/resize_claim.
  • Now we can support resource claim through rpcapi. The caller send rpcapi to the compute node, and the compute node will invocate the resource tracker, get the COMPUTE_RESOURCE_SEMAPHORE, allocate the resource, persistent the claims, and then return back the id of the claim (or the whole claim object). With this changes, we can move the prep_resize etc out of compute manager to conductor.


Details

The claim fields: uuid: the identification for this claim. instance_uuid: the owner instance of the