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