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....
Hello, Thanks for nice feedback from first US timezome meeting. IMO, it's good to introduce limits or quota for Blazar's top level resources, Leases, Hosts, FloatingIP, and etc. It makes possible to handle any type of resource_type in reservations. The additional limitation for length of reservations the Chameleon cloud does looks good to me as an additional quota mechanism. best regards, Masahito On 2019/05/18 3:19, Pierre Riteau wrote:
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....
participants (2)
-
Masahito MUROI
-
Pierre Riteau