Configuring an EGEE VO to use desktop grid resources

These are the instructions for extending an EGEE VO with desktop grid resources provided by EDGeS via its bridge services in the EGEE ⇒ DG direction. This is for you if you are an EGEE VO administrator and want to use EDGeS resources from your EGEE VO.

Overview

Using desktop grid resources from an EGEE VO can be accomplished by adding a special Computing Element which acts like an lcg-CE but it is not a cluster of WNs behind its queues but a desktop grid (a single bridge CE can connect multiple DGs which will appear as separate queues). Due to the security model of desktop grids they cannot run any executable but only preinstalled applications are supported. Consequently, unlike normal lcg-CEs the queues of this bridge CE only accept jobs for applications in the EDGeS Application Repository which can run on the connected DG. However, the WMS is not aware of this and without further consideration would send any job to this CE which could fail and need resubmission. Because of this, some care is needed when adding a bridge CE to a VO to avoid unwanted effects for unsuspecting users.

Basically there are the following options you can choose from:

  1. Make sure your VO members are aware of this and have appropriate Requirements in their JDLs to allow or avoid using the appropriate bridge CE queues depending on the application. In this case the bridge CE can be added to the VO as any other CE but may require VO users to change their JDLs so usually this option is only preferable for small VOs.
  2. Add the bridge CE as a Closed CE, which means that in the BDII the CE will advertise itself as GlueCEStateStatus: Closed thus, the WMS will not select this CE by default. If you choose this option then there are two ways to access this CE:
    • Either using the -r option in glite-wms-job-submit or the equivalent SubmitTo attribute in the JDL to target a specific queue/desktop grid,
    • or you can set up a UI where you change the default JDL Requirement attribute in the VO configuration to use Closed instead of Production, which has the effect that from this modified UI the bridge CEs can be used as normal CEs and normal CEs can be accessed only with -r or SubmitTo.
  3. Create a new Role in VOMS (e.g. BridgeUser) and arrange that the bridge CE only accepts users with proxies that have this role set. This way the VO manager can control who has access to bridge CEs (and via them desktop grid resources) by assigning the role only to allowed users. The assigned users can control if they want to use bridge CEs by using proxies with or without the role set and can then fine tune which resources they want to use for each application by adding the appropriate Requirements in their JDL. Since the WMS[1] will take the VOMS role into account while matching resources, users without the role will not be affected, and unlike in the previous option where only normal or bridge CEs could be used, with this option users with the role can access both normal and bridge CEs at the same time.
    This is the most complete option preferred for bigger VOs. This option combines the previous two by allowing to add a bridge CE without affecting unaware users just like adding a Closed CE in option 2. but allows knowledgeable users to use all resources in the VO just like in option 1. with the difference that not every user gets this behaviour by default but only those who have the role and explicitly ask for using it at proxy creation time thus, confirming they know what they are doing.

[1]Note: Be aware that a patch may be required for the WMS for proxy renewal to work correctly. See this GGUS ticket, a fix is available from gLite developers but may not be released yet.

After deciding on which option you prefer from the above there are two ways to use the EDGeS bridge depending on what desktop grid resources you want to use:

  • If using the EDGeS Bridge Services the bridge CE will be operated by EDGeS and you may access desktop grids already connected to EDGeS. This is the simpler and preferred option that will be discussed on this page.
  • If you want to connect your own desktop grids using EDGeS technology you could do so installing your own bridge CE. This is more complex because you will also need to set up additional infrastructure and manage your own DGs so this is not discussed here, contact us if you prefer this option (but first consider connecting your DG to EDGeS as described here instead and choosing the previous option to allow resource sharing between projects).

Details of using the EDGeS bridge services

MTA SZTAKI (an EDGeS partner, site name in GOCDB is SZTAKI) operates bridge CEs that are connected to desktop grids and we can configure one of these CEs to support your VO to allow appropriate jobs to be bridged to DG resources. Apart from the considerations above adding a bridge CE is no different than allowing the SZTAKI site to provide a CE to your VO.
  • All EDGeS services live in the 193.224.187.128/25 network block so you may need to allow this in your firewall if needed.
  • The EDGeS services have certificates signed by the NIIF CA, check that you have this CA certificate and a valid CRL in your /etc/grid-security/certificates directories. If your WMS complains about expired CRLs while the CRL is correctly refreshed see this GGUS ticket.
  • Then send to the EDGeS bridge administrator (edges-bridgeadm _at_ mail.edges-grid.eu) the necessary VO configuration info needed to configure a CE for your VO and the IP addresses or ranges of your central services (WMS, LB, top level BDII, etc.) where outbound connections may come (this is needed because the EDGeS services are firewalled).
We will configure our CE and firewall and then advertise it in our site BDII which you may need to add to your top BDII unless you are using the all sites list from EGEE which already contains the SZTAKI site.