2009/8/6 Gonçalo Borges <[log in to unmask]>:
> Hi Stephen and Steve...
>
> The CEs (i.e. the glue CEs, corresponding to the queues) have to point to
> different clusters and subclusters. See:
>
> http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_different_memory_limits_for_different_queues_on_the_same_CE
>
> http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_the_OS_name
>
> http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_my_machine_architecture
>
>
>
> Does yaim supports these GlueClusters? If not, this implementations are
> simply not feasible for us... At the rithm we have middleware updates (once
> a week), most of them with yaim reconfiguration, you would break everything
> you did by hand. I would not mind to set up such a mechanism if there is the
> guaranty that it is not destroyed by a yaim reconfiguration, otherwise it is
> just simpler to start a new CE, as Steve pointed out.
>
As I mentioned no.
https://twiki.cern.ch/twiki/bin/view/EGEE/WNWorkingGroup
has some cutting edge stuff to do it but it needs some testing... As
in don't use
it unless you want to test and provide feed back.
Steve
> The information system is presenting a
> "GlueCEStateFreeJobSlots" value
> (in the "dn: GlueVOViewLocalID" fields) representing the sum of
> resources for both queues,
>
>
>
>
> That sounds like you don't have the info provider configured correctly, but
> I have no idea how the sge provider works - do you know who supports it?
>
>
> This is presently a problem. It was supported by LeSC, but unfortunately the
> guy went away and no one is taking this job (it is just on a best effor
> basis). Indeed, the two clusters are not sharing WNs, and therefore, they
> should present proper values. I'll try to look to the script myself...
>
> Cheers
> Goncalo
>
>
--
Steve Traylen
|