Stephen, the dependencies between the torque utils and server should at least be documented. This sounds like either a bug or an omission from the documentation. If it isn't documented, raise a GGUS ticket. Leave the developers to work out which one it is.
John
> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of Stephen Jones
> Sent: 30 September 2011 13:19
> To: [log in to unmask]
> Subject: emi-cream adoption
>
> Hi,
>
> If everyone an early adopter, is anyone an early adopter? While we
> ponder that, I've got something to say/ask about emi-cream and
> emi-torque. Maybe an early-adopter could enlighten me?
>
> The plan was to fix a new new emi-cream onto our existing (separate)
> glite_TORQUE_server cluster. But I discovered that emi-torque (server
> and utils) is built to use MUNGE to safety transmit the login details.
> This is a new thing.
>
> Unfortunately, due to MUNGE, the emi-cream can't qsub from a system
> using emi-torque-utils to a batch cluster headnode that uses
> glite_TORQUE_server (job array syntax is also new). This would mean
> that, by design, emi-cream cannot work with a standalone
> glite_TORQUE_server cluster -- the whole lot has to be updated at once.
>
> This could deserve a GGUS ticket, but I'm not sure of the facts -- is
> it
> possible to run emi-cream/emi-torque-utils with an existing
> glite_TORQUE_server? Does any early adopter know of any lawful
> impediment to this GGUS ticket? Should it be possible to qsub from a
> system using emi-torque-utils to a batch cluster headnode that uses
> glite_TORQUE_server?
>
> Cheers, Steve
|