Minutes of the GSSD face-to-face meeting: 5th June, 2007
Minutes by: Flavia Donno
We report here only the conclusions regarding VOMS ACLs, QUOTA
and Monitoring. At the end of these minutes we also report some
notes about the SRM v2.2 rollout planning in production.
VOMS ACLs
Jean-Philippe Baud reported on the VOMS ACLs as implemented at the moment
in DPM. They are based on virtual UIDs and GIDs which are created on the
fly when a new DN appears to the system. In particular, UIDs are
associated to DNs and GIDs are associated to VOMS groups/roles.
Therefore, a user at a given time is associated to one internal DPM
virtual UID and several virtual GIDs that define the user privileges.
In DPM, VOMS ACLs can be set on directories and files.
VOMS ACLs can be also set on pools (set of file systems).
It was requested to be able to fall back on a default VO specific pool
if a DN match (with the VOMS ACLs) could not be found or if the assigned
pool is full. This should be a configurable option left to the site
administrator to decide.
Also, it should be possible to allow for negative ACLs.
The same functionalities guaranteed by DPM can be also made available
by CASTOR. However, this feature is not expected before middle of 2008.
dCache implements similar functionalities that will be made available
by the end of 2007.
StoRM allows for Just-in-Time (JIT) and for Ahead-of-time (AOT) ACLs.
The JIT ACLs are automatically and dynamically created and deleted by
the system when a request arrives and finishes respectively, consulting
an external authorization service. Instead the AOT ACLs are created
in advance or the first time a request for a given file/directory
arrives. In StoRM a Storage Area corresponds to a directory. Therefore
setting ACLs on a directory implies the same ACLs to be set in the
Storage Area.
The question raised was if the model followed by the various SE
implementations satisfies the use-cases and the requests by the
experiments. Nick Brook from LHCb stated that LHCb is well in contact
with Jean-Philippe and at the moment they feel OK with the proposed
solution. We had no input from the other experiments.
Action: We proposed to come up with a small document that describes the
functionalities made available by the current SE implementations and
submit it to the experiments and site administrators for comments.
Quota
Jean-Philippe Baud presented his study for implementing QUOTA in DPM.
Please, check the presentation in the agenda page.
It was noted that here we do not have a common interface for allowing
a VO manager to control quotas. We should therefore try to identify
a possible common interface for the implementations.
Also in this case a general document should be created and submitted
for comments to the experiments and site administrators communities.
Action:During the July 2-3 Storage Workshop we would like to come to an agreement
between experiments, developers and sites, about the functionality that
can be made available in the medium and long term.
Monitoring
Giacinto Donvito from INFN-Bari presented the tool that has been
developed in Italy to monitor SE activities (please, check presentation).
The tool uses whatever interfaces are available for info retrieval
and dCache billing files. For CASTOR log files are used instead, because
of the absence of similar billing files.
It was noted that it was not a good practice to use log files since their
format can change and it is not standardized. It should be made clear
there is a need for interfaces or billing files for monitoring purposes.
The probes created by the people in Italy for monitoring will adhere to
the standard for outputting the results proposed by the
WLCG monitoring
group.
However, a question raised by the dashboard people (Julia Andreeva) was
how to gather all info collected by the probes and make them available
to the dashboard.
Action: Giacinto and his group will investigate
on how to aggregate the info and make it available to the experiments dashboard.
Action: Mirco is collecting comments on the document circulated some time ago
containing a proposal on the metrics to monitor. Experiments and sites
are invited to provide input.
SRM v2.2 Rollout plan
The experiments expressed their concerns on the usage of the PPS. It is
not considered as an adequate platform to validate new middleware for
various reasons. In particular, the test instances in PPS are quite
small and not adequate for real tests.
However, ATLAS and LHCb have agreed to put the PPS SRM v2.2 endpoints
in their "production" chain tests.
It was noted that sites need to be notified well in advance about
upgrades necessary for the experiments. On the other hand,
experiments are not willing to request an upgrade without a good
testing phase.
Sites are also concerned about the level of support given during
an upgrade.
Experiments are short in human resources to perform tests. It was
stressed that for these tests experiments can rely on GSSD and EIS human
resources. It was proposed as well that a test suite provided by the
experiments can be run by CERN GSSD people to "validate" an installation.
Action: All these concerns need to be brought up at the GDB and MB level and
find there a suitable way to proceed.
For the moment, the plan is to continue testing with the involvement
of the experiments as foreseen. Test first dCache 1.8 sites and
data transfers from CASTOR-2 @ CERN to SRM v2.2 at BNL, FZK and IN2P3
and data access patterns from various SRM v2.2 (dCache, DPM, StoRM).
Include CASTOR SRM v2.2 as soon as ready.
There are minutes attached to this event.
Show them.
