On Dec 13, 2007, at 12:09 PM, Stuempert, Mathias IWR wrote:
Hi All,
I redirected this mail to the dev list since this is definitely a developer’s discussion …
Here are my comments concerning your point a:
We can have this folder as a Grid project folder by extending the corresponding extension point. Ask me for further details…
Could you please point us in the right direction.
Nevertheless I object to having different middlewares in one project. With its attached VO a project is specific to a single middleware and we should follow this principle since it proved to be very useful in the past!!! Therefore the Generic VO should not be used in general.
From a user/developers point of view I agree with you. The difference for the Operator is that when I configure my site I configure it for all VOs. I.e. for the operator the abstraction of the Grid is a site, it is not a VO within the Grid. Thats why we though to use the Generic VO for projects that are holders for local Grid sites configuration files etc. Since these configuration files are not tailored for a specific VO. It is more like a Project that the Operator stores all the information that she needs to maintain her local Grid site.
So instead of coming up with another "Grid Project" definition that will fit the needs of the Operator perspective we though to reuse the "Grid Project" abstraction that are used for the other perspective. Except that for the operator the "feature" of coupling your project with a single VO is not necessary, as the operator doesn't work on a VO base, but on a site base.
Anyway, as long as there is the option to create a generic VO we cannot really prevent the user/operator from doing what we propose. But any suggestion on how this can be presented to the operator are welcome. This was just our first attempt at a solution.
Thanks,
Harald G.
Cheers Mathias
a) Site management in the Grid Project
(see Figure ProjectTree.pdf)
An optional folder can be added to the Grid Project, like the workflow folder, maybe named "Site Config". In this folder each middleware (*see below) will get their own folder. The middleware specific folder is created when one of the wizards to "configure" a specific Grid site is activated. For example when the Batch Service wizard is completed it will place the batch site file (ce201.batch) in "Site Config." -> "gLite". When the Grid site wizard is completed a file "ws101.gria" will be placed in "Site Config." -> "Gria"
* For batch based middlewares the name of the middleware folder can be something generic like "batch middlewares" and not gLite.
b) Tasks for the Operator View for Gria
A wizard will be used to specify a new Gria site. In the wizard the user will provide two URLs: the tomcat end-point and the Gria web service end-point. I.e.
In addition the user also specifies the user name of the admin account of these sites. The information from the wizard are saved in an *.gria file, place under the "Site Config" -> "Gria" -> "Sites" folder.
When opening a *.gria file a view/editor is opened in the Editor space of the perspective. The view/editor will be tabbed, so you can have multiple Gria and batch sites open at the same time. An open Gria site will consist of two web pages (can be selected from the bottom, like a multi-page editor) that where specified in the wizard. From these two web pages the operator can perform most of the administrative tasks of the site.
As the administrator deploy applications in a Gria site. The operator will have a placeholder for applications in a folder ("Site Config." -> "Gria" -> "Applications"). Each application consists of two files a *.pl and *.xml file that are stored in a folder named after the application. The administrator can edit these files using standard Eclipse editors. There will be a Context Menu option from the folder of an application to deploy the application. Then a wizard is opened where the operator can specify to which Grid sites she wants to deploy the application. The result of the deployment is reported back at the last page of the wizard.
We may not get to this, but its an idea. In each of the application folders we will also keep a ".metadata" file. In this file we will store to which site the application were uploaded and when. In this case when the Application folder is selected, then in the Properties View this information will be displayed. The usefulness of this feature is that when a administrator have modified/optimized an application she will know to which site the application should be uploaded to again.
3) Manage ACLs (This is a wish item so we might not get to it)
Similar to managing of application the administrator will be able to have a set of ACL policy files stored in her Grid Project. These policy files (*.xml) can be edited using standard Eclipse editors. A context menu option on each of the policy files will give the option of applying the ACL to specific Gria Grid sites.
Harald G.<image001.jpg><image002.jpg>
geclipse-dev mailing list
geclipse-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/geclipse-dev
