[Go-essp-tech] DRS hierarchy on disk

Luca Cinquini luca at ucar.edu
Fri Nov 20 09:56:07 MST 2009


Hi Phil:

On Nov 20, 2009, at 9:29 AM, <philip.kershaw at stfc.ac.uk> wrote:

> I suppose my next question then is - probably to Luca :) -  is the  
> security policy in the Gateway determined by the DRS based URLs?
The security policy on the Gateway is totally independent on any  
physical path, it is established on logical identifiers. But, any URL  
can be resolved to its logical object, and thehrefore the access  
control attributes retrieved.
> For the ESG software stack have you looked at how the DRS structure  
> will map to the services exposed by the data node or the underlying  
> file system(s)?
Not yet... there is a general requirement of resolving a DRS URL to a  
page that lists all services for the corresponding dataset, or perhaps  
directly to a data stream, but we haven't talked about implementation  
yet. We touched briefly on this at the last telecon.
thanks, Luca
>
> Cheers,
> Phil
> -----Original Message-----
> From: Don Middleton [mailto:don at ucar.edu]
> Sent: 20 November 2009 16:12
> To: Dean N. Williams
> Cc: Don Middleton; Kershaw, Philip (STFC,RAL,SSTD); go-essp-tech at ucar.edu
> Subject: Re: [Go-essp-tech] DRS hierarchy on disk
>
> We discussed this topic (GridFTP on vfs) a fair bit several years  
> ago. We didn't end up pursuing it, however, and at this point I  
> don't recall all the reasons.
>
> don
>
>
> On Nov 20, 2009, at 8:43 AM, Dean N. Williams wrote:
>
>> Hi Phil,
>>
>> This is a good question. Perhaps Rachana or Frank can look into  
>> this and return a proper answer. My first thought is no, but I am  
>> not an expert on GridFTP.
>>
>> Best regards,
>> Dean
>>
>> On Nov 20, 2009, at 2:28 AM, <philip.kershaw at stfc.ac.uk> wrote:
>>
>>> This is a problem for something like GridFTP where you 'see' the  
>>> file system on the server not the DRS hierarchy.  It's a headache  
>>> for applying security policy as presumably this is based on the  
>>> DRS structure.  Some kind of mapping would need to be maintained.
>>>
>>> Is there a way of altering the GridFTP server side interface so  
>>> that it could see a virtual file system structure based on the DRS?
>>>
>>> Cheers,
>>> Phil
>>> -----Original Message-----
>>> From: go-essp-tech-bounces at ucar.edu [mailto:go-essp-tech-bounces at ucar.edu 
>>> ] On Behalf Of Dean N. Williams
>>> Sent: 19 November 2009 12:14
>>> To: Lawrence, Bryan (STFC,RAL,SSTD)
>>> Cc: go-essp-tech at ucar.edu
>>> Subject: Re: [Go-essp-tech] DRS hierarchy on disk
>>>
>>> This is a correct statement.
>>>
>>> -Dean
>>>
>>> On Nov 19, 2009, at 4:04 AM, <bryan.lawrence at stfc.ac.uk> wrote:
>>>
>>>> Hi Stephen
>>>> Bob or someone else can confirm, but  I think the issue is that  
>>>> ESG in general is aiming at supporting more than just the DRS, so  
>>>> while conforming to DRS is a given for CMIP5, it’s not a given  
>>>> for all the datasets that ESG may work with.
>>>> Bryan
>>>> From: go-essp-tech-bounces at ucar.edu [mailto:go-essp-tech-bounces at ucar.edu 
>>>> ] On Behalf Of stephen.pascoe at stfc.ac.uk
>>>> Sent: 19 November 2009 11:49
>>>> To: drach at llnl.gov
>>>> Cc: go-essp-tech at ucar.edu
>>>> Subject: [Go-essp-tech] DRS hierarchy on disk
>>>> At the telco this Tuesday I was slightly surprised when someone  
>>>> (I think Bob) asserted data is not likely to follow the DRS  
>>>> hierarchy on disk.  Although we know the disk layout can be  
>>>> mapped to DRS URLs in the web server I thought our default  
>>>> position was that we would lay out the data in the DRS hierarchy  
>>>> because it is the simplest solution.
>>>> This issue came up in a meeting with UKMO yesterday where they  
>>>> thought there was a strong reason for using the DRS on disk so  
>>>> that fallback positions like ftp follow a consistent structure.   
>>>> I also learnt that CMOR2 will output to the DRS hierarchy  
>>>> automatically.
>>>> Given this, why wouldn't we want to insist all datasets are  
>>>> stored on disk in the DRS hierarchy?
>>>> Thanks,
>>>> Stephen.
>>>> ---
>>>> Stephen Pascoe  +44 (0)1235 445980
>>>> British Atmospheric Data Centre
>>>> Rutherford Appleton Laboratory
>>>> -- 
>>>> Scanned by iCritical.
>>>>
>>>>
>>>> -- 
>>>> Scanned by iCritical.
>>>>
>>>>
>>>> _______________________________________________
>>>> GO-ESSP-TECH mailing list
>>>> GO-ESSP-TECH at ucar.edu
>>>> http://**mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>>
>>>
>>> -- 
>>> Scanned by iCritical.
>>>
>>>
>>> _______________________________________________
>>> GO-ESSP-TECH mailing list
>>> GO-ESSP-TECH at ucar.edu
>>> http://*mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>
>> _______________________________________________
>> GO-ESSP-TECH mailing list
>> GO-ESSP-TECH at ucar.edu
>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>
>
> -- 
> Scanned by iCritical.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20091120/438585c0/attachment-0001.html 


More information about the GO-ESSP-TECH mailing list