On 10/01/2013 05:48 AM, George Beshers wrote:
Food for thought.
I've been following this thread with some interest because
I had been wondering how best to handle SGI's machines
in a remote beaker lab.
There are a few fundamental problems:
1) The machines are sometimes unique -- only one exists, period.
The result is that at certain times the machines must be available
to particular users -- customer/trade show demos for example.
2) They often require hours of continuous time which, particularly
during bring up and major OS releases means scheduling
evenings and weekends --- engineers are arranging their sleep
schedules to take advantage of certain time slots. Random
start times for reservations won't work.
What seems to be lacking in beaker is *Hard Start Times* which
implies hard-end-times.
So for example, if we put a 4 rack UV system (2048 cores, 16Tb of
memory) in beaker it is not just going to stay there; it will be pulled
back inside SGI's firewall on a regular basis.
I was hoping that reservations would address this issue.
Thoughts?
I think handling scheduled availability windows inside Beaker itself is
a separate problem from the one I'm trying to tackle with this proposal
(which is mostly about auto-returning systems after a set period of time
so we're not so reliant on users remembering to return them).
However, we *do* plan to finally add the remote API support for loan
management in 0.16, which (in conjunction with the custom access
policies added in 0.15) will make it more feasible to script this kind
of thing externally. For example:
1. Give a service account the "loan-any" permission for the system(s) of
interest.
2. At the start of the user's allocated window, the external service
(which could be as simple as a cron job) loans it to them for the
designated time period. Since the user won't have the "loan self" or
"loan any" permission, they won't be allowed to extend their loan.
3. When the system is unavailable, the service account locks out
everyone else (include the system owner unless they override the loan)
by loaning it to itself.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (
http://beaker-project.org/)