[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [geclipse-dev] Gria Information Gathered
|
Hi All,
First, it is nice to see a living discussion now about GRIA :)
Second, let me again outline the relations between the GRIA concepts and the g-Eclipse model:
1) In the model we have the VO as central access point to the user's Grid. In the case of gLite the VO therefore contains the info service and the user's VO parameters in order to build the user's personalized Grid (i.e. available services). Within GRIA there is nothing that is comparable to our VO. Here we have to find a "workaround". This is the very first step we have to make.
2) After the VO is defined the user has access to his services (data services, job services ... this also includes computing and storage!) within a project or within the info view. Obviously these services map to the GRIA services (DataService, JobService ...). Furthermore our IGridComputing and IGridStorage map to JobService and DataService, too!
3) A DataService can be used to create a DataStager. This DataStager corresponds to our IGridConnection. Therefore righ-clicking a DataService that is listed in our project's VO node may present the mount action that will create a new DataStager in the Filesystem folder of our project. After that the user may drag'n'drop data from or to the DataStager which is handled like an ordinary filesystem (We therefore need an EFS implementation).
4) A JobService can be used to submit (or to create as it is called within GRIA) a job. Since GRIA does not support something like a Job Description Language this is another hook where we have to investigate. But as I see from the JobService.java there is also a method called getApplicationDescription that returns an XML. I assume this contains also things like what is needed by the application in order to execute properly. This may be input/output files or application parameters, is this assumption right Ken? If so we may make use of this XML or at least a derivative of it in order to describe a GRIA job, called our GRIAJobDescription then.
So now to the main problem at the moment, what should be provided by the info system? From my point of view the info system should provide any information about the user's infrastructure that is available from the VO by using the registered GRIA services. That also means that the main problem shifts from the info system to the VO. That is the central point were we have to define this GRIA infrastructure. At the moment this is done by creating services by hand rather than by querying a central info service, this approach works fine for now. Discussing about something more sophisticated is not needed at the moment. Let's rather go for some first working implementations of data and job functionalities using the things that are already there.
And now comes the current show-stopper that does not allow us to really go on with development. We still have this problem with the configuration directory that has to be solved before we can work with GRIA. So I highly recommend focusing on that now! This has to be solved since nobody is currently able to make use of any GRIA functionality because of this issue. So Ken, can you please report on this? Is there any progress/solution/workaround for this show-stopper? If not please put highest priority on this and do not hesitate to ask the team for help if needed!
Cheers, Mathias
-----Ursprüngliche Nachricht-----
Von: geclipse-dev-bounces@xxxxxxxxxxx [mailto:geclipse-dev-bounces@xxxxxxxxxxx] Im Auftrag von Nick Tsioutsias
Gesendet: Montag, 26. November 2007 11:58
An: Developer mailing list
Betreff: Re: [geclipse-dev] Gria Information Gathered
Hi Harald!
Harald Kornmayer wrote:
> So from my point it would be nice anyhow to have a list of the
> distributed services called a registry? Such a service registry can just
> be viewed as a "bookmark" to the services as the bookmarks in browsers.
The bookmarks in browsers can only be seen by the user that creates
them. The registry that Ariel is trying to install is a registry that
can be seen by all the users that can access a specific GRIA Server.
What would be very nice is a way to have a list off all the existing
GRIA servers but since there is no central service of storing them (like
an LDAP list) where the administrators must post their site when it is
created I don't think we can have it.
> My questions:
> How do you plan to sort the distributed services in the InfoView?
>
My first thoughts on this is that if we have a project with a GRIA VO
nothing will be added on the Computing Elements Tree. Under the sites I
will add the gria server name (for example iwr-geclipse.fzk.de) and I
will have information about the available applications (subtree) and
existing data staggers (another subtree). Under the storage Elements we
can have all the existing data staggers.
> How do you get the "complete" list of available services at different
> locations?
>
For each GRIA site we need to know the link of its JobService in order
to get its available applications.
Thanks,
Nick.
>> Hello everyone. I have been looking in how to get information about
>> the GRIA services and data and I have managed to get the following:
>>
>> I got all the services that are provided by our example GRIA server in
>> iwr-geclipse.fzk.de. I can get the information in the following xml
>> format:
>>
>> ______________________________________________________________________
>> <?xml version="1.0" encoding="UTF-8"?>
>> <application xmlns="">
>>
>> <name>http://it-innovation.soton.ac.uk/grid/imagemagick/swirl</name>
>> <version>1.0.0</version>
>> <description>Application to swirl an image</description>
>> <application-inputType>
>> <name>source-image</name>
>> <type>jpg</type>
>> <description>image file of any type</description>
>> </application-inputType>
>> <application-outputType>
>> <name>swirled-image</name>
>> <type>jpg</type>
>> <description>swirled image of the same type as input
>> type</description>
>> </application-outputType>
>> </application>
>>
>> ______________________________________________________________________
>>
>> As you can see I also get the inputs and the outputs of the job.
>>
>> I also managed to get the data staggers that I had created with the
>> GRIA client in xml format like:
>>
>> ______________________________________________________________________
>> <ns4:title
>> xmlns:ns4="http://purl.org/dc/elements/1.1/";>MyData</ns4:title>
>> <ns5:serviceresourcetype
>> xmlns:ns5="http://it-innovation.soton.ac.uk/2005/grid";>http://www.it-innovation.soton.ac.uk/grid/resource/data</ns5:serviceresourcetype>
>> <ns6:status
>> xmlns:ns6="http://it-innovation.soton.ac.uk/2005/grid";>full</ns6:status>
>>
>> ______________________________________________________________________
>>
>> As you can see I get the title of the data stagger and whether it is
>> full or empty. I think this information is enough for the infosystem
>> to provide. If you agree with me in this, then this means that we will
>> not need the registry service that Ariel tries so hard to install :)
>>
>> Nikos.
>> _______________________________________________
>> geclipse-dev mailing list
>> geclipse-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/geclipse-dev
>>
_______________________________________________
geclipse-dev mailing list
geclipse-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/geclipse-dev
