[GE users] Runtime Design Automation?
Andreas.Haas at Sun.COM
Andreas.Haas at Sun.COM
Wed Jul 18 11:44:29 BST 2007
On Tue, 17 Jul 2007, Olesen, Mark wrote:
>> Sounds reasonable, but juggler_remote does more than only adjusting.
>> It's current tasks are
>> * changing number of available licenses based on decision made by
>> license juggler
>> * retrieving per cluster information about current license demand
>> * retrieving per cluster information about current license
> For the integration, I would collapse juggler_remote utilized+required
> together. They would pull back a block either similar to what is already
> being cached:
> rc_limit gtpower=4,starcd=26,stars=2
> Adding a rc_wait entry would provide the last bit of information.
> For translation purposes:
> rc_limit => max
the local max.
> rc_intern => utilized
I'm not clear about meaning of extern/intern.
Utilized is simply the amount licenses in-use according "qstat -s rs -r -xml"
> rc_wait => demand?
Probably. License juggler "demand" is the amount of missing licenses
according to "qstat -s p -r -xml" output.
> The juggler_remote could even just pull back the entire license.cache,
> without any processing, and let the juggler/schedule parse out what it
> # query
> [rs]sh $MACHINE cat MYPATH/license.cache
Should be fine. Data volume is hardly an issue.
> For sending the adjustments back, the jugger_remote could simply write a
> resource limits file.
> # assign
> echo limits | "[rs]sh $MACHINE cat > MYPATH/license.limits"
Writing it into a file means it can not be guaranteed that the adjustment
really is in effect. Ideally the "assign" should be synchronuous to rule
out race conditions, but it no tragedy if an synchronuous "assign" operation
doesn't fit in the overall picture. License juggler can life with it as long
as knows in the next interval how many licenses are configured in each cluster.
For dealing with clusters out of reach during network outages it keeps already
track of the recent license amount that could successfully be assigned. In
schedule.c this information is used to adjust the utilized amount I explained
above based on the assigned amount from the last interval.
> At the moment, the limits are hard-coded, but a future version of qlicserver
> will then consult the values in license.limits when adjusting the licenses.
Keeping things in configuration files is always somewhat more convenient.
Whether that convenience is critical I can not judge.
> I think it should work quite well. The juggler and juggler_remote would be
> greatly simplified. A bit of work is adjusting the scheduler for parsing new
> input. But the juggler could address this or I could have a go at rewriting
> the scheduler.c in Perl.
A qlicserver super-component at all events were an ideal harbour for the
actual logic inside schedule.c, but it is a SW license question.
> Is it safe to assume that you'll be at the workshop too?
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net
More information about the gridengine-users