Definition of "system"/discovery in getDrmSystem?
Another question for the DRMAA gods... There's no clear definition for what a "DRM system" is in the 1.0 specification. I understand that it could be implementation- dependent, but my assumption is that the generally accepted meaning is "something you can submit jobs to." On SGE, for example, then, it seems then that a system is the same as a cell. On Xgrid, they're called, simply enough, grids. The SGE implementation seems to eliminate this concept altogether, and just require that SGE_ROOT and SGE_CELL be set, so when I call getDrmaaImplementation and getDrmSystem (via Java) on SGE before initialization, I get: getDrmaaImplementation: DRMAA 1.0 Java language binding 0.5 -- GE 6.0u7 getDrmSystem: GE 6.0u7 SGE seems to displace the need for multiple "DRM systems" within DRMAA by shifting the selection to the SGE_CELL environment variable. Is that an accurate understanding? I could certainly do something similar with Xgrid--let the user select a default grid elsewhere--but, since Xgrid natively supports Zeroconf/"Bonjour" discovery of grids, it would be nice to expose this discovery in DRMAA. So, the question is: does it make sense to expose Zeroconf grid discovery via getDrmSystem? --Ed
There's no clear definition for what a "DRM system" is in the 1.0 specification. I understand that it could be implementation- dependent, but my assumption is that the generally accepted meaning is "something you can submit jobs to." On SGE, for example, then, it seems then that a system is the same as a cell. On Xgrid, they're called, simply enough, grids.
Basically, this is something we already discussed and solved for the upcoming final 1.0 spec: http://forge.gridforum.org/sf/go/artf2822?nav=1
The SGE implementation seems to eliminate this concept altogether, and just require that SGE_ROOT and SGE_CELL be set, so when I call getDrmaaImplementation and getDrmSystem (via Java) on SGE before initialization, I get:
getDrmaaImplementation: DRMAA 1.0 Java language binding 0.5 -- GE 6.0u7 getDrmSystem: GE 6.0u7
SGE seems to displace the need for multiple "DRM systems" within DRMAA by shifting the selection to the SGE_CELL environment variable. Is that an accurate understanding?
Citing myself from the tracker: -- snip "contact string" is a resource identifier that allows to contact a DRM system instance (e.g. Condor central manager machine at 123.123.123.123:4444) "DRM system" denotes a type of DRM software (e.g. Condor, SGE) "implementation" denotes a specific version of a DRM system (e.g. Condor v6.6) -- snip So for SGE your impression seems to be right - but I am not the SGE guy ;-)
I could certainly do something similar with Xgrid--let the user select a default grid elsewhere--but, since Xgrid natively supports Zeroconf/"Bonjour" discovery of grids, it would be nice to expose this discovery in DRMAA.
From a DRMAA perspective, it would be better to state all possible DRM instances (== XGrid grids == SGE Cells ???) as the result list of drmaa_get_contact() before drmaa_init().
So, the question is: does it make sense to expose Zeroconf grid discovery via getDrmSystem?
If you take the proposed definition above, getDrmSystem() is not the right one. You would use this with a DRMAA library supporting multiple DRM systems, like Condor and XGrid, in one implementation. Regards, Peter.
Great, that clears everything up. Thanks, Ed On Jun 6, 2006, at 11:53 PM, Peter Troeger wrote:
There's no clear definition for what a "DRM system" is in the 1.0 specification. I understand that it could be implementation- dependent, but my assumption is that the generally accepted meaning is "something you can submit jobs to." On SGE, for example, then, it seems then that a system is the same as a cell. On Xgrid, they're called, simply enough, grids.
Basically, this is something we already discussed and solved for the upcoming final 1.0 spec:
http://forge.gridforum.org/sf/go/artf2822?nav=1
The SGE implementation seems to eliminate this concept altogether, and just require that SGE_ROOT and SGE_CELL be set, so when I call getDrmaaImplementation and getDrmSystem (via Java) on SGE before initialization, I get:
getDrmaaImplementation: DRMAA 1.0 Java language binding 0.5 -- GE 6.0u7 getDrmSystem: GE 6.0u7
SGE seems to displace the need for multiple "DRM systems" within DRMAA by shifting the selection to the SGE_CELL environment variable. Is that an accurate understanding?
Citing myself from the tracker:
-- snip
"contact string" is a resource identifier that allows to contact a DRM system instance (e.g. Condor central manager machine at 123.123.123.123:4444) "DRM system" denotes a type of DRM software (e.g. Condor, SGE) "implementation" denotes a specific version of a DRM system (e.g. Condor v6.6)
-- snip
So for SGE your impression seems to be right - but I am not the SGE guy ;-)
I could certainly do something similar with Xgrid--let the user select a default grid elsewhere--but, since Xgrid natively supports Zeroconf/"Bonjour" discovery of grids, it would be nice to expose this discovery in DRMAA.
From a DRMAA perspective, it would be better to state all possible DRM instances (== XGrid grids == SGE Cells ???) as the result list of drmaa_get_contact() before drmaa_init().
So, the question is: does it make sense to expose Zeroconf grid discovery via getDrmSystem?
If you take the proposed definition above, getDrmSystem() is not the right one. You would use this with a DRMAA library supporting multiple DRM systems, like Condor and XGrid, in one implementation.
Regards, Peter.
participants (2)
-
Ed Baskerville -
Peter Troeger