<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 23/01/2014 18:17, Day, Phil a
écrit :<br>
</div>
<blockquote
cite="mid:BD26CCD58723F74AA8E6BCB31052A1F006F8EBD5@G6W2490.americas.hpqcorp.net"
type="cite"><br>
<pre wrap="">
Just to be clear I'm not advocating putting any form of automated instance life-cycle into Nova - I agree that belongs in an external system like Climate.
However for a reservations model to work efficiently it seems to be you need two complementary types of resource available - for every least you accept promising resource at a certain point you need to have some resource that you can free up, otherwise you have to allocate the resource now to be sure it will be available at the required time in the future (which kind of negates the point of a reservation). That is unless you're an airline operator, in which case you can of course sell an infinite number of seats on any plane ;-)</pre>
</blockquote>
<br>
I wish I would be an airline operator, but I'm not ;-)<br>
That said, we ensure that we can match the needs in the future
because we intentionally 'lock' a bunch of compute hosts for
Climate, which can't be serving for other purposes. The current
implementation is based on a dedicated aggregate (we call it
'freepool') plus a relation table in between the hosts and the
reservations (so we elect the hosts at the lease creation, but we
dedicate them to the useron the lease start).<br>
<br>
I agree, this is a first naïve implementation, which requires to
define a certain set of resources for managing dedication of compute
hosts. Please note that the current implementation for virtual
instances is really different, where instances are booted at lease
creation then shelved, and then unshelved at lease start.<br>
<br>
<br>
<blockquote
cite="mid:BD26CCD58723F74AA8E6BCB31052A1F006F8EBD5@G6W2490.americas.hpqcorp.net"
type="cite">
<pre wrap="">
So it feels like as well as users being able to say "This instance must be started on this date" you also need the other part of the set which is more like the spot instances which the user pays less for on the basis that they will be deleted if needed. Both types should be managed by Climate not Nova. Of course Climate would also I think need a way to manage when spot instances go away - it would be a problem to depend on X spot instance being there to match the capacity of a lease only to find they had been deleted by the user in Nova some time ago, and the capacity now used for something else.
</pre>
</blockquote>
<br>
Agreed, we could potentially implement spot instances as well, but
it occurs to me that's only another option when creating a lease
where you say that's you're OK if your hosts can be recycled for
other users before the end of the lease you ask.<br>
<br>
<br>
<br>
Anyway, I'm not fan of having aggregates for managing dedicated
hosts 'lock-in'. I'm wondering if we could tag in Nova the hosts
with a tenant_id so that it would be read by a scheduler filter.
That would require to extend the
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
ComputeNode model with a tenant_id IMHO.<br>
<br>
Any etherpad we could discuss on the future blueprint ?<br>
<br>
-Sylvain<br>
</body>
</html>