Re: [HTCondor-devel] Remote IO in vanilla universe

[Brian Bockelman <bbockelm@xxxxxxxxxxx>]

On Jan 28, 2013, at 9:01 AM, Douglas Thain <dthain@xxxxxx> wrote:

> Brian -
> 
> The idea all along has been to have a common protocol definition, so
> that the various implementations would interoperate:
> http://research.cs.wisc.edu/htcondor/chirp
> 
> We last looked at this about 1.5 years ago -- and it worked -- but I
> don't believe there is any regular testing of the interaction between
> the cctools chirp and the condor chirp.  Without that, things may
> drift apart over time.
> 
> I will be happy to put forth some effort from my group to make this
> interaction work better.  How about we start by identifying the known
> problems and any desired features?  (Off list, probably.)
> 

Going stream-of-conscious, here's one direction this could go:
1) Add parrot to the Condor externals.
2) Make a new version of the HTCondor libchirp_client.so which can decide at runtime between the CCL and the HTCondor implementation of the chirp client.
3) Write integration tests so the (CCL | HTCondor) chirp server is tested against the (CCL | HTCondor) client.
4) For UW or proper builds, we could decide on which version is used by default for shipped clients.
 - For an application like this, I would prefer the CCL implementation.  Others may prefer HTCondor, I suppose.  Having two independent implementations of a protocol is always useful, of course.

I think the key here would be to get the matrix of client and server implementations into the HTCondor tests, rather than trying to wedge HTCondor into the CCL build.

Brian

Attachment: smime.p7s
Description: S/MIME cryptographic signature