AW: [geclipse-dev] Application Deployment

["Tao, Jie" <jie.tao@xxxxxxxxxx>]

Hi Powel,

Application deployment will focus on two scenerios: 1. users install a software on a CE 2. users have source code and intend to create executables on Ces

In Glite case, we use the experiment software installation LCG tool to implement the deployment. The installation is controlled by the lcg manage software (/opt/lcg/bin/lcg-manageSoftware). After installation, the software is published in the information service. The uninstall is only for theses installed application.

Jie

-----Ursprüngliche Nachricht-----
Von: geclipse-dev-bounces@xxxxxxxxxxx [mailto:geclipse-dev-bounces@xxxxxxxxxxx] Im Auftrag von Pawel Wolniewicz
Gesendet: Freitag, 4. April 2008 16:17
An: Developer mailing list
Betreff: Re: [geclipse-dev] Application Deployment




On Fri, 4 Apr 2008, Stuempert, Mathias IWR wrote:

> Hi All,
>
>
>
> Today we had a discussion within FZK concerning the application 
> deployment stuff. I do not want to report about all details of this 
> discussion but about the impact to the model that you should be aware 
> of. So especially for Nick and GRIA this may be interesting.
>
>
>
> 1)       We will have a new model element representing applications
> installed on a CE (e.g. IGridApplication or so).

Be carefull. The name Application is now used in context of predefined extentions to JSDL wizard. Maybe it is possible to integrate the two concepts into common Application model

What method and functionality do you plan to have for IGridApplications?

>
> public IGridApplication[] fetchApplications( IGridContainer parent, 
> IVirtualOrganization vo, IGridComputing ce, IProgressMonitor monitor 
> );
>
> The info service has then to retrieve the applications available on 
> the specified CE and accessible by the specified VO.

Hmmm... That can be problem.
For GRIA application are defined by XML, for gLite GLUE just by name. I am not sure if just a string name will be enough to create IGridApplication.
And in fact they are just a tag and not all tags are applications.

>
>
> 4)       The VO subtree of a grid project will have a new top level
> folder called "Applications" containing all applications for that VO 
> of all CEs.

Good. For GRIA now applications are listed as Computing, so they can be easily moved to Applications.

>
> 5)       The CEs will have all applications installed on them and
> accessible for the VO as children.

Currently for GRIA we have:

Computing
|-blend@xxxxxxxxxxxxxxxxxxx
|-paint@xxxxxxxxxxxxxxxxxxx
|-swirl@xxxxxxxxxxxxxxxxxxx

We can have it then:

Computing
|-iwr-geclipse.fzk.de
   |-blend
   |-paint
   |-swirl

>
> 6)       For any of these applications there will be a context menu
> action for deinstalling this application.

I see problem here. How can you know how to deinstall application?
Or only applications installed by g-Eclipse can be deinstalled?

I see problem with deinstalling gLite applications. From GlueHostApplicationSoftwareRunTimeEnvironment field in GLUE there is no clue where the application is installed and how it should be deinstalled.
It is possible to look into /exp_soft/[VO]/[TAG_NAME] but there is no guarantie that application is there and even no guarantie that the TAG describes this application.

>
> 7)       We can also think about other context actions (think about
> tests or so).

The natural action for me would be "submit". Or at lease "create job description"
But for GRIA JSDL the wizard can prepare additional wizard pages for the application by parsing XML. For gLite it will not be possible...
But I am sure the user seeing application "APP@CE" would like to submit that application and not deinstall it. If the functionality is only for install/deinstall and not submit, then I vote for shoing them only for Operator perspective.

>
> 8)       The application deployment action will be available on the VO
> (VO wide deployment) the CE folder (also VO wide deployment) and on 
> the CEs (CE wide deployment).

I hope that these actions will be shown only for Operator Perspective.


Regards,

Pawel

_______________________________________________
geclipse-dev mailing list
geclipse-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/geclipse-dev