 |
 |
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