Re: [Condor-devel] Writing a SAGA adaptor for Condor

[Todd Tannenbaum <tannenba@xxxxxxxxxxx>]

João Abecasis wrote:
> Hello everyone,
>
> I'm a developer with the SAGA C++ project, which provides the Simple
> API for Grid Applications. In our implementation, middleware specifics
> are hidden behind the standard API through the use of pluggable
> adaptors. Currently, there are adaptors for Globus and GridSAM and I
> will be developing one to interface to Condor.

Wonderful!

> You can find additional
> about the project here, and I'll be getting to the point after the
> break:
>
>     http://saga.cct.lsu.edu/
>
> So, while I'm still getting started, I'm looking for advice any of you
> may have. In particular, I need to decide on the particular Condor API
> to target.

Take a peek at
  http://www.cs.wisc.edu/condor/slides/API/apis.ppt
if you haven't already... give a high-level overview of the options and 
the various pros/cons associated with each.

> > From what I've gathered, I couldn't find a C API or library to link
> to. It seems that the recommended APIs are the command line tools,
> GAHP and SOAP. Any comments on this or issues I should be aware of?
> Any recommendations with regard to the backward and forward
> compatibility of the APIs?

The GAHP interface only supports job submission, control, and 
monitoring.  There is no way to query about the machines available, for 
instance.  But if that is all you need, it could be a good choice.  From 
the Condor daemon's point of view, it cannot tell the difference between 
commands arriving from the GAHP client or from command-line tool clients.

The command tools are not a choice to overlook, assuming you (a) can 
live with the fact that they need to be installed, (b) performance-wise 
you can live with a fork/exec everytime you want to interact w/ Condor, 
and (b) you don't rely so much on scraping their output - instead use 
the "-xml" or the "-format" options to tools like condor_q and 
condor_status.  After all, the text-output-for-humans can change from 
release to release.  The command-line option is probably the best 
documented and best tested, because it is how most users and web portals 
interact w/ Condor.


> Also, since we want to cover the broadest installed base, from your
> experience, would any of those be less widely available? For instance,
> the SOAP API is turned off, by default. Does anyone have an indication
> of how that relates to deployments out there?

No real data on how many sites turn it on -vs- leave it off.  Course, it 
is easy to turn on...

> Comments are mostly welcome. Thank you all for your time.

SOAP is our official API.  The WSDL files are what you get in lieu of C 
libraries or what not.  They give you practically all the functionality 
of the Condor command-line tools.  However, the API is at a fairly low 
level - for some folks this is a good thing, for others it just means 
more work.  Also, while working w/ SOAP is really easy w/ .NET and/or 
Java Axis --- it can sometimes be painful in other environments.

If I were you, I'd prolly use the command-line tools unless one of the 
cons I listed above was a show-stopper (and often they are).  Then I'd 
probably look at SOAP if I was in .NET or Java or needed more than job 
queue access, else I'd look at the GAHP.

hope this helps
Todd


> Cheers,
>
>
> João Abecasis
> _______________________________________________
> Condor-devel mailing list
> Condor-devel@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/condor-devel


--
Todd Tannenbaum                       University of Wisconsin-Madison
Condor Project Research               Department of Computer Sciences
tannenba@xxxxxxxxxxx                  1210 W. Dayton St. Rm #4257