Open Stack

Thanks, that helps a lot.  At what point in the process is it decided (and 
by what) which host will run the VM instance?  Is that host picked from 
the same pool as is used for non-reserved instances?  How does the outline 
go if there is not enough capacity for the reserved instance?

Thanks,
Mike


Dina Belova <dbelova at mirantis.com> wrote on 10/09/2013 06:34:06 AM:

> Mike, I'll try to describe the reservation process for the virtual 
> reservations. I'll use Nova project as an example.
> 
> As I said, this Nova workflow is only the example that may and 
> certainly will be modified for other 'virtual' projects.
> 
> 1) User goes to Nova via CLI/Dashboard and commits all usual actions
> like he/she wants to boot instance. The only difference is that user
> passes reservation-connected hints to Nova. In the CLI this request 
> may look like the following:
> 
> nova  boot --flavor 1 --image bb3979c2-b2e1-4836-abbc-2ee510064718 
> --hint reserved=True --hint lease_params='{"name": "lease1", 
> "start": "now", "end": "2013-12-1 16:07"}' vm1
> 
> If scheduling process went OK, we'll see the following by 'nova list' 
command:
> 
> +--------------------------------------+------+----------
> +------------+-------------+------------------+
> | ID                                   | Name | Status   | Task 
> State | Power State | Networks         |
> +--------------------------------------+------+----------
> +------------+-------------+------------------+
> | a7ac3b2e-dca5-4d21-ab37-cd019a813636 | vm1  | RESERVED | None     
>   | NOSTATE     | private=10.0.0.3 |
> +--------------------------------------+------+----------
> +------------+-------------+------------------+
> 
> 2) Request passes up to the Compute Manager, where scheduling 
> process is already done. If Manager finds reservation related hints 
> it uses Climate client to create lease using passed to Nova params 
> and id of the VM to be reserved. Also Nova changes status of VM in 
> its DB to 'RESERVED'. If there are no reservation related hints 
> filter properties, Nova just spawns instance as usual.
> 
> 3) Lease creation request goes to Climate Lease API via Climate 
> Client. Climate Lease API will be mostly used by other services 
> (like Nova in this example) and by admin users to manage leases as 
> 'contracts'.
> 
> 4) Climate Lease API passes lease creation request to Climate 
> Manager service via RPC. Climate Manager is the service that 
> communicates with all resource plugins and Climate DB. Climate 
> Manager creates lease record in DB, all reservation records (for the
> instance in this case) and all events records. Even if user passes 
> no additional events (like notifications in future), at least two 
> events for lease are created - 'start' and 'end' events.
> 
> 5) One more function that Manager does is periodical DB polling to 
> find out if there are any 'UNDONE' event to be processed. If there 
> is such event (for example, start event for the lease just saved in 
> DB), manager begins to process it. That means manager sets event 
> status to 'IN_PROGRESS' and for every reservation in lease commits 
> 'on_start' actions for this reservation. Now there is one-to-one 
> relationship between lease and reservation, but we suppose there may
> be cases for one-to-many relationship. 'On_start' actions are 
> defined in resource plugin responsible for this resource type 
> ("virtual:instance") in this example. Plugins are loaded using 
> stevedore and needed ones are defined in climate.conf file.
> 
> 6) "virtual:instance" plugin commits on_start actions. For VM it may
> be 'wake_up' action, that wakes reserved instance up through Nova 
> API. This may be implemented using Nova extensions mechanism. Wake 
> up action really spawns this instance.
> 
> 7) If everything is ok, Manager sets event status to 'DONE' or 
'COMPLETED'.
> 
> 8) Almost the same process is done when Manager gets 'end' event for
> the lease from DB. 
> 
> Thank you for the attention.
> 
> Dina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131009/5b081890/attachment.html>