General information

Middleware

UMD/CMD

  • UMD3 deprecation
    • WMS dismission plan presented at December OMB
    • sites have started broadcasting WMS decommissioning deadlines
    • in parallel, UMD team will test upgrading the umd-release package from UMD3/SL6 to UMD4/SL6 to make usre everything works properly
    • plan will be arranged and agreed with PTs in January/February (next meeting scheduled next monday Jan 22nd)
    • at some point UMD3 will be "freezed" (no more updates of any kind, either security ones)
      • probably we will establish a period of 2-4 weeks during which sites get progressively aware that the old repos won't work anymore and switch to UMD4/SL6
      • if any security issue comes out during that period, we can always ask to shut down the repository

Preview repository

Operations

ARGO/SAM


FedCloud

Feedback from Helpdesk

Monthly Availability/Reliability

suspended sites: T3_HU_Debrecen

New weights for the NGIs average A/R values, based on Computation Power

Since Dec 1st it has been used the CE's "computation power" for computing the weights for the NGIs average A/R values:

computation power = hep-spec * LogicalCPUs

This is a quantity that can be addable up over the CEs of a site (and over the sites). Until now it has been simply added up the CEs hep-spec values for getting a site global value, but this is not correct, because the hep-spec refers to a particular CE (to the cluster behind that particular CE) and it is not addable up. That is why, first of all, we asked VAPOR to implement the "computation power" as well as the site/NGI "average hep-spec". Have a look for example at the "figures" section: http://operations-portal.egi.eu/vapor/resources/GL2ResSummary

Several sites are still missing the necessary information for computing the weights: check on VAPOR the values published by your sites in order to properly publishing in the GLUE2 schema the number of logical CPUs and the Hep-Spec06 benchmark.

  • Example of ldap query for checking if a site is publishing the HepSpec-06 benchmark:
$ ldapsearch -x -LLL -H ldap://egee-bdii.cnaf.infn.it:2170 -b "GLUE2DomainID=pic,GLUE2GroupID=grid,o=glue" '(&(objectClass=GLUE2Benchmark)(GLUE2BenchmarkType=hep-spec06))'

dn: GLUE2BenchmarkID=ce07.pic.es_hep-spec06,GLUE2ResourceID=ce07.pic.es,GLUE2ServiceID=ce07.pic.es_ComputingElement,GLUE2GroupID=resource,GLUE2DomainID=pic,GLUE2GroupID=grid,o=glue
GLUE2BenchmarkExecutionEnvironmentForeignKey: ce07.pic.es
GLUE2BenchmarkID: ce07.pic.es_hep-spec06
GLUE2BenchmarkType: hep-spec06
objectClass: GLUE2Entity
objectClass: GLUE2Benchmark
GLUE2BenchmarkValue: 12.1205
GLUE2EntityOtherInfo: InfoProviderName=glite-ce-glue2-benchmark-static
GLUE2EntityOtherInfo: InfoProviderVersion=1.1
GLUE2EntityOtherInfo: InfoProviderHost=ce07.pic.es
GLUE2BenchmarkComputingManagerForeignKey: ce07.pic.es_ComputingElement_Manager
GLUE2EntityName: Benchmark hep-spec06
GLUE2EntityCreationTime: 2017-06-20T16:50:48Z

dn: GLUE2BenchmarkID=ce01.pic.es_hep-spec06,GLUE2ResourceID=ce01.pic.es,GLUE2ServiceID=ce01.pic.es_ComputingElement,GLUE2GroupID=resource,GLUE2DomainID=pic,GLUE2GroupID=grid,o=glue
GLUE2BenchmarkExecutionEnvironmentForeignKey: ce01.pic.es
GLUE2BenchmarkID: ce01.pic.es_hep-spec06
GLUE2BenchmarkType: hep-spec06
objectClass: GLUE2Entity
objectClass: GLUE2Benchmark
GLUE2BenchmarkValue: 13.4856
GLUE2EntityOtherInfo: InfoProviderName=glite-ce-glue2-benchmark-static
GLUE2EntityOtherInfo: InfoProviderVersion=1.1
GLUE2EntityOtherInfo: InfoProviderHost=ce01.pic.es
GLUE2BenchmarkComputingManagerForeignKey: ce01.pic.es_ComputingElement_Manager
GLUE2EntityName: Benchmark hep-spec06
GLUE2EntityCreationTime: 2017-09-05T07:34:26Z
  • Example of ldap query for getting the number of LogicalCPUs published by an ARC-CE (due to a bug in te info-provider, CREAM-CE publish the total number under the ExecutionEnvironment class):
$ ldapsearch -x -LLL -H ldap://egee-bdii.cnaf.infn.it:2170 -b "GLUE2DomainID=UA_ILTPE_ARC,GLUE2GroupID=grid,o=glue" 'objectClass=GLUE2ComputingManager' GLUE2ComputingManagerTotalLogicalCPUs

dn: GLUE2ManagerID=urn:ogf:ComputingManager:ds4.ilt.kharkov.ua:pbs,GLUE2ServiceID=urn:ogf:ComputingService:ds4.ilt.kharkov.ua:arex,GLUE2GroupID=services,GLUE2DomainID=UA_ILTPE_ARC,GLUE2GroupID=grid,o=glue
GLUE2ComputingManagerTotalLogicalCPUs: 168
  • Example of ldap query for getting the number of LogicalCPUs published by a CREAM-CE:
$ ldapsearch -x -LLL -H ldap://egee-bdii.cnaf.infn.it:2170 -b "GLUE2DomainID=UKI-SOUTHGRID-SUSX,GLUE2GroupID=grid,o=glue" 'objectClass=GLUE2ExecutionEnvironment' GLUE2ExecutionEnvironmentLogicalCPUs 
GLUE2ExecutionEnvironmentPhysicalCPUs GLUE2ExecutionEnvironmentTotalInstances

dn: GLUE2ResourceID=grid-cream-02.hpc.susx.ac.uk,GLUE2ServiceID=grid-cream-02.hpc.susx.ac.uk_ComputingElement,GLUE2GroupID=resource,GLUE2DomainID=UKI-SOUTHGRID-SUSX,GLUE2GroupID=grid,o=glue
GLUE2ExecutionEnvironmentTotalInstances: 71
GLUE2ExecutionEnvironmentLogicalCPUs: 568
GLUE2ExecutionEnvironmentPhysicalCPUs: 71

Next year we are going to open tickets for making the sites either publish or fixing the necessary information.

Decommissioning EMI WMS

WMS servers can be decommissioned. Please follow the procedure PROC12. The plan is:

  • Starting from January 2018, put the WMS servers in draining: this will block the submission of new jobs and will allow the jobs previously submitted to finish
    • inform in advance your users that you are going to put in draining and then dismiss the WMS servers (as per PROC12)
    • there might be several VOs enabled on your WMS servers: in case only few of them need to use the service for few weeks more, you might disable the other VOs
  • On Dec 14th EGI Operations sent a new broadcast to the VOs reminding the users the forthcoming WMS decommission
  • After the end of February, EGI Operations will open a ticket to the sites that haven't started the decommission process yet

WMS servers in downtime on GOC-DB

VOs have to find alternatives or migrate to DIRAC:

  • the HOWTO22 explains how a VO can request the access to DIRAC4EGI and how interact with it by CLI

IPv6 readiness plans

webdav probes in production

The webdav probes have been deployed in production. Several sites publish the webdav protocol in the BDII: they have been asked to register the endpoint on GOC-DB and to enable the monitoring, if it wasn't already done.

List of sites that not have completed the configuration yet:

List of sites that disabled webdav: UNIGE-DPNC, GR-01-AUTH, HG-03-AUTH, CETA-GRID, WUT

For registering on GOC-DB the webdav service endpoint, follow the HOWTO21 in order to filling in the proper information. In particular:

During the January OMB we are going to discuss the inclusion of the probes in the operators and in the critical profile:

  • after the OMB, the webdav probes will be added to the ARGO_MON_OPERATORS profile: in this way the failures will generate an alarm on the dashboard, and the ROD teams can open a ticket;
  • after (at least) one month, if no particular issue occurs, and if at least 75% of webdav endpoint are passing the tests, the probes will be added in the ARGO_MON_CRITICAL profile, so the results of these probes will be taken into account for the A/R figures.

Storage accounting deployment

During the September meeting, OMB has approved the full-scale deployment of storage accounting. The APEL team has tested it with a group of early adopters sites, and the results prove that storage accounting is now production-ready.

Storage accounting is currently supported only for the DPM and dCache storage elements therefore only the resource centres deploying these kind of storage elements are requested to publish storage accounting data.

In order to properly install and configure the storage accounting scripts, please follow the instructions reported in the wiki: https://wiki.egi.eu/wiki/APEL/Storage

IMPORTANT: be sure to have installed the star-accounting.py script v1.0.4 (http://svnweb.cern.ch/world/wsvn/lcgdm/lcg-dm/trunk/scripts/StAR-accounting/star-accounting.py)

After setting up a daily cron job and running the accounting software, look for your data in the Accounting Portal: http://goc-accounting.grid-support.ac.uk/storagetest/storagesitesystems.html. If it does not appear within 24 hours, or there are other errors, please open a GGUS ticket to APEL who will help debug the process.

List of sites already publishing and of tickets opened is reported here.

PROBLEM: several (DPM) sites are using an old version of the star-accounting.py script. This leads to records having an EndTime 30 days in the future. The star-accounting.py script version to use is v1.0.4 (http://svnweb.cern.ch/world/wsvn/lcgdm/lcg-dm/trunk/scripts/StAR-accounting/star-accounting.py).

The APEL team opened tickets for this issue:

PROBLEM number 2: the APEL repository is receiving an increasing number of storage records that have been encrypted with something that isn’t the APEL certificate, so the records can’t be read them (and so the sender is unknown). If your site isn’t successfully publishing, please comment out the “server_cert” variable in sender.cfg

AOB

Next meeting

  • No labels