You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by Shahbaz Memon <m....@fz-juelich.de> on 2013/08/28 16:30:31 UTC
Gateway portal - Airavata client integration
Hi Devs,
Consider a scenario of a science gateway portal that is already using Airavata to submit remote jobs. Supposedly Airavata (GFac) introduces a new provider say middleware A and the gateway portal decides to use that provider, does this portal require any changes in their client code (used to talk to Airavata)? or will it work without any changes as Airavata abstracts provider related details? how do you deal with provider specific resource and security requirements?
Thanks.
Shahbaz
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September, von 10:00 bis 17:00 Uhr: http://www.tagderneugier.de
Re: Gateway portal - Airavata client integration
Posted by Suresh Marru <sm...@apache.org>.
On Aug 29, 2013, at 9:32 AM, Shahbaz Memon <m....@fz-juelich.de> wrote:
> I am more concerned about the user acceptance testing on Airavata. Is there any architectural element physically available for that purpose?
I am not sure I fully followed your question. My way of looking at Airavata users are portal and gateway developers. So if we are targeting end users who use computational resources, I wonder if it is out of scope for Airavata. Airavata by design is a gateway framework and good way to judge will be well documented API's (as of now this is the weakest point, since the project was so much focusing on the framework itself). If end users are looking for CLI's, I think they will be disappointed since its not targeted for them. There needs to be a layer in front of Airavata which converts the generic functionality of Airavata into user friendly actions.
Does this answer your question?
Suresh
>
> Shahbaz Memon
> Jülich Supercomputing Center
> Forschungszentrum Jülich
>
> ---------------------------------------------------------------
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> Karsten Beneken (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> Prof. Dr. Sebastian M. Schmidt
> ---------------------------------------------------------------
>
>
> On Thu, Aug 29, 2013 at 3:25 PM, Suresh Marru <sm...@apache.org> wrote:
> Hi Shahbaz,
>
> XBaya as it stands is for gateway developers who would like to test the various aspects of the Airavata services. I will about to start a discussion on various client interactions and looks like your questions raise good use cases for these. Lets discuss all these possibilities and knock them off within next couple of months.
>
> Suresh
>
> On Aug 29, 2013, at 7:37 AM, Shahbaz Memon <m....@fz-juelich.de> wrote:
>
> > Thanks for your reply.
> >
> > > The Gateway Developer needs to know how the security works and provides the required deployment information (like Unicore BES EPR) and associated security (for instance, for XSEDE, registers the OA4MP token).
> >
> > That means gateway developers have to change the interaction characteristics with the framework if any new provider has special requirements and attributes.
> >
> > In the link you mentioned the End user can use GUI and CL to communicate her request to Airavata. Is XBaya the GUI intended here? and what CL client you are using? Are both or any of these client interfaces supporting all the capabilities of Airavata's supported providers?
> >
> > Thanks.
> >
> > Shahbaz
> >
> >
> >
> >
> >
> >
> > On Wed, Aug 28, 2013 at 6:13 PM, Suresh Marru <sm...@apache.org> wrote:
> > Hi Shahbaz,
> >
> > Good question. I think to better understand this problem lets look at it from the perspective of the three classes of airavata stake holders [1], end users, gateway developers and core developers.
> >
> > The core framework developer adds a provider to GFac, adds the associated security handling details to Credential Store and ensures the Airavata API has the required mechanisms to pass the security details.
> >
> > The Gateway Developer needs to know how the security works and provides the required deployment information (like Unicore BES EPR) and associated security (for instance, for XSEDE, registers the OA4MP token).
> >
> > The end users should not change anything and just specify the new resources enabled by the provider added.
> >
> > Does this answer your question?
> >
> > Suresh
> >
> > [1] - http://airavata.apache.org/architecture/airavata-stakeholders.html
> >
> > On Aug 28, 2013, at 10:30 AM, Shahbaz Memon <m....@fz-juelich.de> wrote:
> >
> > > Hi Devs,
> > >
> > > Consider a scenario of a science gateway portal that is already using Airavata to submit remote jobs. Supposedly Airavata (GFac) introduces a new provider say middleware A and the gateway portal decides to use that provider, does this portal require any changes in their client code (used to talk to Airavata)? or will it work without any changes as Airavata abstracts provider related details? how do you deal with provider specific resource and security requirements?
> > >
> > > Thanks.
> > >
> > > Shahbaz
> > >
> > >
> > > ------------------------------------------------------------------------------------------------
> > > ------------------------------------------------------------------------------------------------
> > > Forschungszentrum Juelich GmbH
> > > 52425 Juelich
> > > Sitz der Gesellschaft: Juelich
> > > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> > > Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> > > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> > > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> > > Prof. Dr. Sebastian M. Schmidt
> > > ------------------------------------------------------------------------------------------------
> > > ------------------------------------------------------------------------------------------------
> > >
> > > Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September, von 10:00 bis 17:00 Uhr: http://www.tagderneugier.de
> >
> >
>
>
Re: Gateway portal - Airavata client integration
Posted by Shahbaz Memon <m....@fz-juelich.de>.
I am more concerned about the user acceptance testing on Airavata. Is there
any architectural element physically available for that purpose?
Shahbaz Memon
Jülich Supercomputing Center
Forschungszentrum Jülich
---------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneken (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
---------------------------------------------------------------
On Thu, Aug 29, 2013 at 3:25 PM, Suresh Marru <sm...@apache.org> wrote:
> Hi Shahbaz,
>
> XBaya as it stands is for gateway developers who would like to test the
> various aspects of the Airavata services. I will about to start a
> discussion on various client interactions and looks like your questions
> raise good use cases for these. Lets discuss all these possibilities and
> knock them off within next couple of months.
>
> Suresh
>
> On Aug 29, 2013, at 7:37 AM, Shahbaz Memon <m....@fz-juelich.de> wrote:
>
> > Thanks for your reply.
> >
> > > The Gateway Developer needs to know how the security works and
> provides the required deployment information (like Unicore BES EPR) and
> associated security (for instance, for XSEDE, registers the OA4MP token).
> >
> > That means gateway developers have to change the interaction
> characteristics with the framework if any new provider has special
> requirements and attributes.
> >
> > In the link you mentioned the End user can use GUI and CL to communicate
> her request to Airavata. Is XBaya the GUI intended here? and what CL client
> you are using? Are both or any of these client interfaces supporting all
> the capabilities of Airavata's supported providers?
> >
> > Thanks.
> >
> > Shahbaz
> >
> >
> >
> >
> >
> >
> > On Wed, Aug 28, 2013 at 6:13 PM, Suresh Marru <sm...@apache.org> wrote:
> > Hi Shahbaz,
> >
> > Good question. I think to better understand this problem lets look at it
> from the perspective of the three classes of airavata stake holders [1],
> end users, gateway developers and core developers.
> >
> > The core framework developer adds a provider to GFac, adds the
> associated security handling details to Credential Store and ensures the
> Airavata API has the required mechanisms to pass the security details.
> >
> > The Gateway Developer needs to know how the security works and provides
> the required deployment information (like Unicore BES EPR) and associated
> security (for instance, for XSEDE, registers the OA4MP token).
> >
> > The end users should not change anything and just specify the new
> resources enabled by the provider added.
> >
> > Does this answer your question?
> >
> > Suresh
> >
> > [1] - http://airavata.apache.org/architecture/airavata-stakeholders.html
> >
> > On Aug 28, 2013, at 10:30 AM, Shahbaz Memon <m....@fz-juelich.de>
> wrote:
> >
> > > Hi Devs,
> > >
> > > Consider a scenario of a science gateway portal that is already using
> Airavata to submit remote jobs. Supposedly Airavata (GFac) introduces a new
> provider say middleware A and the gateway portal decides to use that
> provider, does this portal require any changes in their client code (used
> to talk to Airavata)? or will it work without any changes as Airavata
> abstracts provider related details? how do you deal with provider specific
> resource and security requirements?
> > >
> > > Thanks.
> > >
> > > Shahbaz
> > >
> > >
> > >
> ------------------------------------------------------------------------------------------------
> > >
> ------------------------------------------------------------------------------------------------
> > > Forschungszentrum Juelich GmbH
> > > 52425 Juelich
> > > Sitz der Gesellschaft: Juelich
> > > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> > > Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> > > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> > > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> > > Prof. Dr. Sebastian M. Schmidt
> > >
> ------------------------------------------------------------------------------------------------
> > >
> ------------------------------------------------------------------------------------------------
> > >
> > > Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September,
> von 10:00 bis 17:00 Uhr: http://www.tagderneugier.de
> >
> >
>
>
Re: Gateway portal - Airavata client integration
Posted by Suresh Marru <sm...@apache.org>.
Hi Shahbaz,
XBaya as it stands is for gateway developers who would like to test the various aspects of the Airavata services. I will about to start a discussion on various client interactions and looks like your questions raise good use cases for these. Lets discuss all these possibilities and knock them off within next couple of months.
Suresh
On Aug 29, 2013, at 7:37 AM, Shahbaz Memon <m....@fz-juelich.de> wrote:
> Thanks for your reply.
>
> > The Gateway Developer needs to know how the security works and provides the required deployment information (like Unicore BES EPR) and associated security (for instance, for XSEDE, registers the OA4MP token).
>
> That means gateway developers have to change the interaction characteristics with the framework if any new provider has special requirements and attributes.
>
> In the link you mentioned the End user can use GUI and CL to communicate her request to Airavata. Is XBaya the GUI intended here? and what CL client you are using? Are both or any of these client interfaces supporting all the capabilities of Airavata's supported providers?
>
> Thanks.
>
> Shahbaz
>
>
>
>
>
>
> On Wed, Aug 28, 2013 at 6:13 PM, Suresh Marru <sm...@apache.org> wrote:
> Hi Shahbaz,
>
> Good question. I think to better understand this problem lets look at it from the perspective of the three classes of airavata stake holders [1], end users, gateway developers and core developers.
>
> The core framework developer adds a provider to GFac, adds the associated security handling details to Credential Store and ensures the Airavata API has the required mechanisms to pass the security details.
>
> The Gateway Developer needs to know how the security works and provides the required deployment information (like Unicore BES EPR) and associated security (for instance, for XSEDE, registers the OA4MP token).
>
> The end users should not change anything and just specify the new resources enabled by the provider added.
>
> Does this answer your question?
>
> Suresh
>
> [1] - http://airavata.apache.org/architecture/airavata-stakeholders.html
>
> On Aug 28, 2013, at 10:30 AM, Shahbaz Memon <m....@fz-juelich.de> wrote:
>
> > Hi Devs,
> >
> > Consider a scenario of a science gateway portal that is already using Airavata to submit remote jobs. Supposedly Airavata (GFac) introduces a new provider say middleware A and the gateway portal decides to use that provider, does this portal require any changes in their client code (used to talk to Airavata)? or will it work without any changes as Airavata abstracts provider related details? how do you deal with provider specific resource and security requirements?
> >
> > Thanks.
> >
> > Shahbaz
> >
> >
> > ------------------------------------------------------------------------------------------------
> > ------------------------------------------------------------------------------------------------
> > Forschungszentrum Juelich GmbH
> > 52425 Juelich
> > Sitz der Gesellschaft: Juelich
> > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> > Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> > Prof. Dr. Sebastian M. Schmidt
> > ------------------------------------------------------------------------------------------------
> > ------------------------------------------------------------------------------------------------
> >
> > Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September, von 10:00 bis 17:00 Uhr: http://www.tagderneugier.de
>
>
Re: Gateway portal - Airavata client integration
Posted by Shahbaz Memon <m....@fz-juelich.de>.
Thanks for your reply.
> The Gateway Developer needs to know how the security works and provides
the required deployment information (like Unicore BES EPR) and associated
security (for instance, for XSEDE, registers the OA4MP token).
That means gateway developers have to change the interaction
characteristics with the framework if any new provider has special
requirements and attributes.
In the link you mentioned the End user can use GUI and CL to communicate
her request to Airavata. Is XBaya the GUI intended here? and what CL client
you are using? Are both or any of these client interfaces supporting all
the capabilities of Airavata's supported providers?
Thanks.
Shahbaz
On Wed, Aug 28, 2013 at 6:13 PM, Suresh Marru <sm...@apache.org> wrote:
> Hi Shahbaz,
>
> Good question. I think to better understand this problem lets look at it
> from the perspective of the three classes of airavata stake holders [1],
> end users, gateway developers and core developers.
>
> The core framework developer adds a provider to GFac, adds the associated
> security handling details to Credential Store and ensures the Airavata API
> has the required mechanisms to pass the security details.
>
> The Gateway Developer needs to know how the security works and provides
> the required deployment information (like Unicore BES EPR) and associated
> security (for instance, for XSEDE, registers the OA4MP token).
>
> The end users should not change anything and just specify the new
> resources enabled by the provider added.
>
> Does this answer your question?
>
> Suresh
>
> [1] - http://airavata.apache.org/architecture/airavata-stakeholders.html
>
> On Aug 28, 2013, at 10:30 AM, Shahbaz Memon <m....@fz-juelich.de> wrote:
>
> > Hi Devs,
> >
> > Consider a scenario of a science gateway portal that is already using
> Airavata to submit remote jobs. Supposedly Airavata (GFac) introduces a new
> provider say middleware A and the gateway portal decides to use that
> provider, does this portal require any changes in their client code (used
> to talk to Airavata)? or will it work without any changes as Airavata
> abstracts provider related details? how do you deal with provider specific
> resource and security requirements?
> >
> > Thanks.
> >
> > Shahbaz
> >
> >
> >
> ------------------------------------------------------------------------------------------------
> >
> ------------------------------------------------------------------------------------------------
> > Forschungszentrum Juelich GmbH
> > 52425 Juelich
> > Sitz der Gesellschaft: Juelich
> > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> > Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> > Prof. Dr. Sebastian M. Schmidt
> >
> ------------------------------------------------------------------------------------------------
> >
> ------------------------------------------------------------------------------------------------
> >
> > Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September,
> von 10:00 bis 17:00 Uhr: http://www.tagderneugier.de
>
>
Re: Gateway portal - Airavata client integration
Posted by Suresh Marru <sm...@apache.org>.
Hi Shahbaz,
Good question. I think to better understand this problem lets look at it from the perspective of the three classes of airavata stake holders [1], end users, gateway developers and core developers.
The core framework developer adds a provider to GFac, adds the associated security handling details to Credential Store and ensures the Airavata API has the required mechanisms to pass the security details.
The Gateway Developer needs to know how the security works and provides the required deployment information (like Unicore BES EPR) and associated security (for instance, for XSEDE, registers the OA4MP token).
The end users should not change anything and just specify the new resources enabled by the provider added.
Does this answer your question?
Suresh
[1] - http://airavata.apache.org/architecture/airavata-stakeholders.html
On Aug 28, 2013, at 10:30 AM, Shahbaz Memon <m....@fz-juelich.de> wrote:
> Hi Devs,
>
> Consider a scenario of a science gateway portal that is already using Airavata to submit remote jobs. Supposedly Airavata (GFac) introduces a new provider say middleware A and the gateway portal decides to use that provider, does this portal require any changes in their client code (used to talk to Airavata)? or will it work without any changes as Airavata abstracts provider related details? how do you deal with provider specific resource and security requirements?
>
> Thanks.
>
> Shahbaz
>
>
> ------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> Prof. Dr. Sebastian M. Schmidt
> ------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------
>
> Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September, von 10:00 bis 17:00 Uhr: http://www.tagderneugier.de