[GSM-WG] OGF issues for SRM (GSM-WG)

[Arie Shoshani]

Jensen, J (Jens) wrote:
> Hi,
>
> I attended the recent OGF in Manchester.  Here is a quick summary
> of the most important stuff:
>
> There was no dedicated GSM-WG session this time - 
Yes, we know, since Alex and/or I could not attend.  That's why it
is good to have you a co-chair from the European side.
> nevertheless,
> a number of issues arose that I will need to follow up on.
> I summarise them here, and will follow up separately with
> you lot later:
>
> There has been (also outside the OGF, from EGEE and others)
> talk about httpg being inappropriate for many SOAP clients,
> since it is incompatible with normal SSL.
>   
That's a big issue that needs to be discussed again.  It was brought up
in previous SRM meetings, but httpg prevailed for now.
> The GLUE stuff for 2.0 did not yet get to SEs, mostly CEs and
> jobs were discussed.  Nevertheless, the 2.0 work was kickstarted
> and there is time for us to provide use cases.  There are some
> WGs from EGA looking at the same, e.g. resource management,
> but their work is less mature than the GLUE stuff - but then
> they are looking at more detailed descriptions of resources.
>
> Interoperability was discussed again.  I talked to the AstroGrid
> folks and the SRB folks (Reagan and Arun).  In my current line
> of thinking, it will be easier to teach the data transfer tools
> to transfer files between different types of SEs, instead of
> developing interfaces between them.  Thus, instead of developing
> an SRM interface to SRB - and vice versa (and more complicated
> models have been discussed) - we teach FTS and friends to talk
> to both SRM and SRB (and other SEs).  Requires more thinking.
> I will follow up to GIN-DATA but have been informed the SRB
> folks have started discussing this.
>   
I think this is the wrong approach, since it will force all higher
level services to implement multiple (at least two mechanisms to
talk to storage systems.  There were plans to have SRM interface
on top of SRB, and we even offered to adapt our SRM implementation,
but so far no effort was put into that.
> I talked to a number of folks about SRM - for example, I have
> asked DEISA to discuss evaluating SRM as storage technology
> (they currently have GPFS on dedicated networks).  There were
> other opportunities for "spreading the word" - OGF is not just
> "blessing" the standard, it is also a good opportunity to
> "sell" storage protocols.
>   
Yes, I think so too.   OGF should be a good vehicle for spreading the word.
> One other question which regularly pops up in my mind
> (and did so this time as well) is that SRM implementations are
> used by non-HEP communities (and we are trying to sell it
> to wider communities), yet are driven by HEP users and use
> cases and service providers.  There should be a way for the
> non-HEP communities to feed in their use cases and priorities,
> and it seems to me that the right forum for this is also the
> OGF (in addition to EGEE for those who are in EGEE).  For
> example, astronomers do things Differently(tm) and are well
> represented in OGF.
>   
In the US, we are using SRMs in an climate modeling project, called 
Earth System Grid (ESG).  We are also planning to apply in other 
communities.  We find that security restriction (firewalls, 
one-time-passwords) make it difficult to have SRM daemons running.
Perhaps it is worth getting some port ranges blessed for SRMs so that 
security people can monitor these ports and allow them.
> In summary, I see three main uses of the OGF:
> * Standards body for blessing the standard (for example, the
>   EGEE NA5 reviewers have asked for this).
> * Opportunity to "spread the word."
> * Opportunity for others to feed back into the process.
>
> Anyway.  This was just the summaries; I will follow up later
> on the detailed issues.
>
> It was also proposed that I replace Peter Kunszt as co-chair of
> GSM-WG - Arie, of course, remains chair of the group.  Which I
> accepted, having discussed it with Arie and Erwin - if there
> are any objections, let us know.
>   
A small correction: Peter and I were both co-chairs.  That is possible in
OGF.  So, we should keep the same in your case.
> >From my own perspective, this will also help me persuade my
> bosses to let me put some more time and effort into this.
>   
I can understand the motivation here.  It is a community effort that 
should help publicize RAL as well.

Arie