airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject Re: Decoupling GFac Providers
Date Tue, 05 Mar 2013 04:15:52 GMT
Hi Danushka,

I agree with Amila, we should not get any implementation details into schemas. The Schemas
are a contract between user and the system. Its within the system how it executes the task
user wants to accomplish. These schemas are completely agnostic to how Airavata talks to a
system. For instance, user should be able to say, I want to run a job on Amazon and the host
description has EC2 end points. But we should not at that level describe/tag classes on how
Airavata talks to EC2.

Your suggestions on decoupling the provider has some value, but given Lahiru has recently
eased this in a big way, if further improvements are needed, lets focus on looking at improving
them. To achieve your goal of decoupling the providers to make it easy for developers to add
new providers is a good one. Other alternatives to achieve this goal may be to write good
amount of test cases, or make it easy within GFAC as a framework to add providers. 

Cheers,
Suresh


On Mar 4, 2013, at 10:51 PM, Danushka Menikkumbura <danushka.menikkumbura@gmail.com>
wrote:

> Amila,
> 
> Correct. When you define the class name in your schema definition, it
> actually goes into the HostDescriptionType.
> 
> Thanks,
> Danushka
> 
> 
> On Tue, Mar 5, 2013 at 8:44 AM, Amila Jayasekara <thejaka.amila@gmail.com>wrote:
> 
>> On Mon, Mar 4, 2013 at 9:56 PM, Danushka Menikkumbura
>> <danushka.menikkumbura@gmail.com> wrote:
>>> Hi,
>>> 
>>> As we have discussed on a separate thread it is very beneficial to have
>>> gfac providers decoupled from the core so that gateway developers can
>> write
>>> their own providers and seamlessly integrate them with the Airavata
>>> runtime. I suggested we have a separate plugin architecture to facilitate
>>> that but it looks as if a simple and neat approach would be to enable
>> using
>>> dynamically loaded providers in the scheduler without having a separate
>>> plugin manager to do that.
>>> 
>>> In order to do that, we need to let the scheduler know the
>> fully-qualified
>>> class names of providers. I suggest we have the provider class name
>> defined
>>> in the host description.
>> 
>> Hi Danushka,
>> 
>> The provider class name is an implementation detail in GFac. I think
>> we should not expose that to API. User does not need to know about
>> class names implementing appropriate providers. Therefore I do not
>> think HostDescriptor is the right place to put fully qualified class
>> name of provider.
>> 
>> Further I believe the fully qualified class name should be associated
>> with org.apache.airavata.schemas.gfac.HostDescriptionType.
>> 
>> HostDescriptionType has following derivations;
>> 
>> org.apache.airavata.schemas.gfac.GlobusHostType
>> org.apache.airavata.schemas.gfac.Ec2HostType
>> org.apache.airavata.schemas.gfac.GsisshHostType
>> org.apache.airavata.schemas.gfac.UnicoreHostType
>> 
>> Thanks
>> Amila
>> 
>>> 
>>> WDYT?
>>> 
>>> Thanks,
>>> Danushka
>> 


Mime
View raw message