Open Stack

Hello,

We had a very interesting first Blazar IRC meeting for the Americas
last week [1].

One of the topics discussed was enforcing limits to reservation usage.
Currently, upstream Blazar doesn't provide ways to limit reservations
per user or project. It is technically possible for users to reserve
more resources than what their quotas allows them to use.

The Chameleon project, which has been running Blazar in production for
several years, has extended it to:

a) enforce operator-defined limits to reservation length (e.g. 7 days)
b) when creating or updating reservations, check whether the project
has enough available Service Units (SU) in their allocation, which is
stored in a custom external database

George Turner from Indiana University Bloomington explained how
Jetstream, if it were to use Blazar to share GPU resources, would have
a similar requirement to check reservation usage against XSEDE
allocations (which are again stored in a custom database).

I am starting this thread to discuss how Blazar can support enforcing
these kinds of limits, making sure that it is generic enough to be
plugged with the various custom allocation backends in use.

1) Blazar should check Nova limits as a guide for limiting reservation
usage at any point in time: if number of instances quota is 8, we
shouldn't allow the user to reserve more than 8 instances at any point
in time.

2) In addition, Blazar could use a quota to limit how much resources
can be allocated in advance. Operators may be happy for projects to
reserve 8 instances for a month, but not for a century. This could be
expressed as a time dimension that would apply to the instance / cores
/ ram quotas.

3) If Blazar was making REST requests to a customisable endpoint on
reservation creation / update, expecting to get a simple yes/no answer
(with a human-friendly error message, like how much SUs are left
compared to how much would be used), would people be motivated to
write a small REST service making the link between Blazar and any
custom allocation backend?

Feel free to reply to this message or join our next meeting on
Thursday May 23 at 1600 UTC.

Cheers,
Pierre

[1] http://eavesdrop.openstack.org/meetings/blazar/2019/blazar.2019-05-09-16.01.log.html