- Compact style
- Indico style
- Indico style - inline minutes
- Indico style - numbered
- Indico style - numbered + minutes
- Indico Weeks View
To dial in to the conference:
a. Dial +41227676000
b. Enter access code 0148141
OR click HERE
(Please specify your name & affiliation in the web-interface)
In order to make easier the life of VOs that want to run either 32b application or 64b one, we would like to make sure that every french site is correctly publishing the GlueHostArchitecturePlatformType attribute of their lcg-CE GlueSubCluster.
According to the link http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_my_machine_architecture, the value is obtained by taking the result of "uname -m" command launched on the worker node (that is, the OS bits capability)
We are however wondering whether that value has to be adapted or not to the effective Glite-WN version (i686 or x86_64). In particular, if your WN OS is x86_64 and your Glite-WN version is i686, the job environment is set to i686. In such a case, do we really have to publish x86_64 as explained in the above link ? Isn t it a bit error-prone for the VOs ?
Job list match problems at DESY reported by user. Traced back to Top-level BDII. Switched back to a host running an older version. Same effect observed at FZK as well. Details are logged in GGUS:44201 [Might be presently assigned to the wrong support unit]
An example for a problematic jdl file:
<verbatim> VirtualOrganisation = "dteam"; Executable = "/bin/env"; StdError = "stderr.txt"; StdOutput = "stdout.txt"; OutputSandbox = { "stdout.txt", "stderr.txt" }; Requirements = Member("srm-dteam.cern.ch", other.GlueCESEBindGroupSEUniqueID) ; </verbatim>
Time at WLCG T0 and T1 sites.