Re: AW: [geclipse-dev] Storage vs. Service

[Ariel Garcia <garcia@xxxxxxxxxx>]

Hi,

well, late but better than never... (i mean, contributing to this 
discussion)

> > > We have gathered few ideas:
> > > 1. keep as it is
> > > pros:
> > > - no effort required
> >
> > Yes, I love to implement ostrich algorithm. :)
>
> Well, I like the pro, too. But that's all. So definitely -1 from me.

-1 also but the required changes are not much in my opinion

A point i wanted to stress:
   LFC is NOT storage!  ie, even if we can mount it, EFS etc, there is NO 
data physically stored in that server, it is just a catalog.

Actually i would think of all resources in a grid as services, but 
separating the (true) storage and computing out just because there are 
many of them! (more below)

> > > 2. create a new branch in Services: Data Access Services
> > > pros:
> > > + all data access services are clustered in one place
> > > + it's easy to find LFC endpoint
> >
> > Not always easy. Try to create dteam VO. :)
> > There are severals hundreds of services. Even "data services" branch 
> > will not solve the problem, as there is a lot of SRM services.
>
> In principle I agree to Pawel. Nevertheless we could have something like
> the "Data Access Services" branch and beyond that branches for the
> different access "flavors", i.e. SRM, LFC, ...

i am not sure that making the tree deeper is a good idea... 

we have tree different things here:
   - how things are organized in the glue schema 
   - how things are in our model
   - how things are displayed

We should try to keep them more or less in sync, otherwise our code gets 
completely messy!!!

Glue 1.3 (ie, current gLite version) has 3 (relevant) top level elements, 
Computing, Storage, and Services
As you may know already, normal CE's appear only as computing, but SE's 
also publish as service. 
But that should also change for CE's, as cream CEs should sometime publish 
as services also.

This was somehow recognized/addressed in Glue 2.0, where storage and 
computing are subelements of service, ie, everything is a service, which 
means that being "service" contains no extra information.

So i would propose that the VO view follows the information in the 
infosystem more or less closely. It is then of course responsabillity of 
the <middleware>.info plugins to arrange the different 
servers/services/resources into the information tree (glue schema in 
principle)
This is what we had discussed regarding Gria in Linz

Why not keep 
 - Computing  (CEs in glite, job-services in GRIA)
 - Storage      (SRMs in glite, data-services in GRIA)
 - Services (ie, all others)
        * Type1
        * Type2
        * Job-submission (ie, glite RB)
        * File-catalogs
        * ...
        * TypeN

where the Type is simply taken from Glue?  (ie, the glite.info plugin could 
take care of reading the GlueServiceType published by the service, and 
convert it into a human readable category,

   GlueServiceType: org.glite.wms.WMProxy -> Type="Job SubmissionServices"
   GlueServiceType: lcg-local-file-catalog       -> Type="File Catalogs"

and use that 'Type' to organize the Services folder
We do NOT need to start extending/changing/complicating the model for 
that!!

> > > 3. create an entry for LFC in Storage branch
> > > pros:
> > > + logically consistent (LFC behaves as storage element)

well, just for the "mount" action it behaves like the SRMs, but for the 
user (glite ones at least...) it is confusing


> > to have new class LFCStorage implementing IStorage. And this object
> > can be constructed from LFCService and added to "Storage" branch..

uh? i mean, just for making LFCs appear in another part of the VO tree?
see my comment below


> 1) In principle I like the idea since it seems to clean up things a bit.
> And as Pawel already mentioned it may be a good idea to introduce some
> substructures in order to make large VOs "browseable".

yes, but not deeper as 3 levels please (3 clicks: VO, type, subtype)

Actually i think that that classification _should_ be based on 
the "GlueServiceType" key that the service is publishing (or, if there is 
no infosys or glue like in Gria, the one that the  gria.info plugin 
decides to use)
That way the code can be kept MW-independent without adding extra 
complication in the model

To make more clear my point: we do not need to introduce extra (empty) 
Interfaces  in the model just for being able to do 
   if ( object instance of IMyCoolService ) {
      //
   }


> So, what has to be done on the model-side to implement this?! We have to
> introduce something like:
>
> class IGridDataAccessService extends IGridService {

no, please no more things in the model... these are just re-combinations of 
available functionality

>   /**
>    * Return a String identifying the type of the service.
>    * (Is this really necessary or can we use IGridService#getURI()
>    * to group the services?)
>    */
>   public String getServiceType();

we have getURI  and getHostname in IGridResource already (which doesn't 
make any sense for a IGridJob but well...  i never understood why IGridJob 
is an IGridResource... i am missing something for sure).

So we _could_ have getServiceType (returning the GlueServiceType as said 
above) in IGridService interface. But not inside a subinterface!

>   /**
>    * Creates a new storage from this service.
>    */
>   public IGridStorage createStorage();

what does precisely 'creates a new storage' mean, do we really need that?
If "something" is both a IGridService and IGridStorage it should be 
returned as those two things by the info system, right?
Somehow it looks like a "workaround" for me... i am wrong? what is the 
usecase here?

My (streched) 2 cents ;-)
Cheers, Ariel