Project

General

Profile

Feature #18860

Support direct local submission of glideins, e.g. for sites with double authentication or VMs

Added by Marco Mambelli almost 2 years ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Category:
-
Target version:
Start date:
01/31/2018
Due date:
% Done:

0%

Estimated time:
Stakeholders:
Duration:

Description

There are resources that are currently not supported by GlideinWMS and would be of interest for some VOs.
These include clusters that require 2 factors authentication (e.g. used by IceCube) and
VM started up without joining a compute element (e.g. CMS Azure effort)

From here the proposal of new mechanisms to start glideins:
1. a thin client started via cron, that pulls the factory for commands and glidein files
2. a self-starting glidein (that eventually may pull for updates from the factory but not necessarily)

Here some note from the meeting w/ the IceCube PyGlidein group:

Why they choose pyglidein and what site admin like about it:
- simplicity
- single python package
- the configuration pre-populated
- add some site specific configuration (how to submit jobs, how to query queue for jobs)
- no firewall configuration for the communication w/ the server

Gonzalo:
1. they do not provide a CE gateway
2. there is no factory authentication
Any local cluster w/ head node or 2 factor authentication would be a problem for traditional GlideinWMS (restrictive firewall does not let through, 2 factor auth not doable programmatically).
With pyglidein they only need to have an account on the remote cluster and deploy the package.

They have resources at different universities not interested in opening stuff up or installing servers.
The collaborator cannot commit opening ports in the firewall. Very limited or no admin support.
A lot of university are requiring 2 factor authentication.
Is important the ability not to punch holes in the sites or require login information because it cannot handle 2 factor auth
The server is maintaining a web server and condor central manager
The client on the resource queries the server via http and retrieves glideins to run locally (they start the startd receiving user jobs)
Currently they are using condor password security protocol, passwors submitted w/ the job. So far has been OK.

Something similar could be an interesting development for a new resource type supported by GlideinWMS
Another box w/ jobs running there and a client quering the factory for glideins (provisioning requests)
Something like a reverse gahp, w/ a BOSCO that does not require ssh into the site would be very interesting
https://github.com/juve/rvgahp

If you were able to help us tackle the firewall issue we’d be glad to give GWMS another shot: you have a development team and we’d be able to tag along and get access to more resources, including OSG and the ones providing servers.

Further things to consider:
- Site token project, https w/ jason web token
- Installation: tarball in user space or python package (pip install local virtualenv) 
- Keep in mind that it will need to update from time to time
- Most sites are set up as cron jobs (a server in user space is probably less reliable)

History

#1 Updated by Marco Mambelli over 1 year ago

  • Target version changed from v3_2_x to v3_4_x

#2 Updated by Marco Mambelli over 1 year ago

  • Target version changed from v3_4_x to v3_5_x

#3 Updated by Marco Mambelli 2 months ago

  • Target version changed from v3_5_x to v3_6_x


Also available in: Atom PDF