Open Stack

Hi Jay,

On 4 April 2017 at 00:20, Jay Pipes <jaypipes at gmail.com> wrote:
> However, implementing the above in any useful fashion requires that Blazar
> be placed *above* Nova and essentially that the cloud operator turns off
> access to Nova's  POST /servers API call for regular users. Because if not,
> the information that Blazar acts upon can be simply circumvented by any user
> at any time.

That's something of an oversimplification. A reservation system
outside of Nova could manipulate Nova host-aggregates to "cordon off"
infrastructure from on-demand access (I believe Blazar already uses
this approach), and it's not much of a jump to imagine operators being
able to twiddle the available reserved capacity in a finite cloud so
that reserved capacity can be offered to the subset of users/projects
that need (or perhaps have paid for) it. Such a reservation system
would even be able to backfill capacity between reservations. At the
end of the reservation the system cleans-up any remaining instances
and preps for the next reservation.

The are a couple of problems with putting this outside of Nova though.
The main issue is that pre-emptible/spot type instances can't be
accommodated within the on-demand cloud capacity. You could have the
reservation system implementing this feature, but that would then put
other scheduling constraints on the cloud in order to be effective
(e.g., there would need to be automation changing the size of the
on-demand capacity so that the maximum pre-emptible capacity was
always available). The other issue (admittedly minor, but still a
consideration) is that it's another service - personally I'd love to
see Nova support these advanced use-cases directly.

-- 
Cheers,
~Blairo