[dmis-bof] Vote for submission of Charter

Michel Drescher Michel.Drescher at uk.fujitsu.com
Wed Mar 22 01:12:10 CST 2006


Hi Arie,

see comments inline below:

On 21 Mar 2006, at 23:35, Arie Shoshani wrote:

> [...]
>
> You say:
> "When requesting a data movement, I have certain expectations that  
> I would like to be met. It is simply not always true that a service  
> can meet these expectations; for example if I request a data  
> transfer to be carried out using GridFTP but the service supports  
> only MTOM, then the request would fail."
>
> Now, suppose that the expectation is that the data will be moved to  
> some storage system and that the entire volume is 1 TB.  Which  
> component will take care of making sure that the user is allowed to  
> move a TB, and that there is enough space allocated?  I don't think  
> the DMIS should do that.

Ack, that would not be the DMIS.

> It seems from what you suggested below (the "hierarchical model"),  
> that in this case the data movement call could be made to an SRM  
> (which will allocate the space) and it will call the DMIS for the  
> actual transfer.  Is this how you envision this working?

Again, ack.

> Another expectation could be that the TB movement should happen in  
> 24 hours.  Would the DMIS try to estimate whether this can be  
> achieved?

In case you mean that the movement should *start* in 24 hours, the  
DMIS can estimate if this is feasible by assessing its current  
movement queue and schedule, and available resources. In case you  
meant that the movement has to be finished within the next 24 hours,  
yes, the algorithm to assess whether this is feasible or not won't be  
much different.

> It seems that in order to provide DMIS with "the parameters that  
> directly affect the data movement itself sorted out before the data  
> movement will actually take place" (to quote what you said below),  
> another fairly complex service would be needed to set it up.  Maybe  
> in simple use cases, one can assume certain parameters, so they do  
> not have to be setup.

I must admit, I am lacking rhetoric skills here. I really didn't know  
how to express myself better. So let's just see in practical work how  
and where we will end up with this.

> Finally, I agree with your comment on what resources the DMIS could  
> report on (resources it has consumed to fulfil a data movement  
> request, e.g. bandwidth usage, CPU cycles(?), total bytes moved,  
> etc.).  While this may not be easy to implement, it will be of  
> great value to the component that invokes it, especially if that  
> was an SRM.

Yes I agree here, though some I expect to be easy to implement, some  
rather difficult or impossible (e.g. CPU cycles in Java based WS). So  
I expect that we will end up so that a DMIS MUST report resource  
usage, but some resources mandatory and others not.


Cheers,
Michel





More information about the dmis-bof mailing list