Choose timezone
Your profile timezone:
DPM white paper meeting
→
Europe/Zurich
Presents:
FC: F. Chollet
AD: A. Doria
FF: F. Furano
GP: G. Philippon
AS: A. Sartirana
PV: P. Vokac
## Introduction and document in general
FF: in the document much space is devoted to the status-quo, which is good, but it is still missing the main question (and answer): How the project sustainability can be guaranteed.
So far 99% of the dev activity was done by CERN and this part is going to decrease. "How" the project can continue in this conditions is a point that should be addressed.
The question to CERN (or to CERN/WLCG, "how can CERN/WLCG contribute to this?") should be very simple and direct.
FC/PV/FF: we can include EGI as possible contributors. EGI has probably no manpower to devote to support/development. But we can re-contact them to have a clear statement on the subject.
AS: there is a question proposed (between ??) in the draft of the introduction:
"""
?? More explicitly the question we would like to answer is: “under which conditions the community of DPM sites will consider the project sustainable and continue to invest on it.” ??
"""
this question implicitly (but it should be made explicitly) to the "how" question proposed by FF ("how these conditions can be fulfilled"). The "??" reflect the fact that this question as it is probably too direct.
This is also a question to us. in the sense that some of the minimal "conditions" may include the status of the community: how many sites will be around, which effort will they put in the community.
AD: A strong answer is impossible (for DPM as well as for any other component of the MW) but it would be good to have a statement.
The question to CERN/WLCG - rather than sound like an "ultimatum" - should positively express which are the points critical to us on we would like an agreed support.
AD: At some point we should explicitly state that DPM currently is a very reliable storage system.
FC: we also intent to speak about the impact of a technology change. Maybe experiment may comment on the operational cost for them
GP: experiment certainly do not care about the deployed technology but are of course sensible to the fact that each deployed technology is properly and reliably supported.
FC: We will rewrite the introduction. It should be more like an abstract including - besides the declaration of goals - a summary of the whole document and of the possible outcomes
## Infrastructure
First draft written.
PV: Taiwan people have been contacted we should add them in the loop for the future iterations.
FC: Also G. Sciacca has been contacted and should be added in the loop.
AD: we should probably add a list of VOs (added to the action ist).
AS: we will also add some plots with the status of the infrastructure.
## Tech current status
First draft written. FC would like some feedback on the statements.
AD: Are other storage technologies well supporting SRM-less operation (as DPM does).
PV: dcache still has no SRR and is not dropping SRM support but everything is ready (e.g. srm-less TPC)
AS: the statement about DPM being currently fine performance-wise can be confirmed by everyone? (in particular by huge sites like Tokyo)
TK: Tokyo has 10PB and in SRM-less mode everything is running smoothly. The DB is 100GB and running on a performing dedicated HW (100GB RAM, SSD). Tokyo is planning to grow to 15PB.
AS: is there a statement from developers about the maximal "size" currently supported by DPM? This is important to have an idea of the sustainability of this storage technology.
FF: the rule of thumb is x10 wrt today (so 100PB). Of course without SRM.
PV: this seems a reasonable estimate.
FF: on the performance p.o.v. sites are fine for few years. The problem may come from things we do not know (i.e. unexpected needed developments to cope with - e.g. - WLCG evolution). This goes with the main question addressed by the document.
AD: one of the expected new things to come is "token". Can devs make a statement about the token.
This is interesting for the IT sites as their activity in ESCAPE will be on distributed DPM and HTTP TCP.
FF: DPM is in the best position to be able to rapidly implement the required tokens solution when it will be made available.
But of course this depends on the manpower evolution. It is difficult to estimate the number of necessary FTEs.
AF/PV: Token should be listed as a critical point on which we need an agreed support.
AD: in ESCAPE we are trying to have some manpower to be able to contribute. But of course we cannot assure that this attempt will be successful.
FF: these attempts to get manpower for DPM should be explicitly included in the document.
## Collaboration
First draft written
AD: we should say explicitly that the collaboration is working well today and we would like this to go on.
PV: a lot of stress on the support was put by the DOME migration but we may expect operations to run more smoothly in the future
AD: in the coming year needed support may be more for developments than operations.
AS: we can make a statement about the sites contribution. That we will do what we can on a best-effort basis.
GP: we can mention the DOME migration task force as an example of how the best effort community managed to perform a difficult task
# Statements for the future
FC: make a list of requirements (and their cost). First draft of list done. We should define what is critical and what it is not
AD: for the list of evolutions to the HCLHC horizon we must say explicitly that DPM sites are participating to the working groups for the DL definition and that are willing to be actively part of the evolution.
Action list:
- Add Taiwan, G. Sciacca and Sean in the mail thread (AS)
- Get the list of VOs (AS)
- Add infrastructure plots (AS).
- Finalize "current status" part (FC and AS)
- Edit the "future view" part (FC and AS)
There are minutes attached to this event.
Show them.