[Swift-devel] Re: Provenance use case

[Michael Wilde]

That makes sense; I need to start using that feature.

On 3/28/09 3:13 AM, Ben Clifford wrote:
> I was imagining more that you would have the execution $PATH pointing to 
> the suite of remote software (using Swift's PATHPREFIX functionality), 
> rather than specifying the path individually to each one in tc.data; and 
> then run a version command with (unparameterised) gives the version for 
> the entire suite.
> 
> 
> On Fri, 27 Mar 2009, Michael Wilde wrote:
> 
>>
>> On 3/27/09 4:33 PM, Ben Clifford wrote:
>>> On Fri, 27 Mar 2009, Michael Wilde wrote:
>>>
>>>> so instead of echo monkey foo, this profile entry should go on the tc.data
>>>> entry, and do something like:
>>>>
>>>> getAppVersion.sh appName appPath
>>> It doesn't have any access to tc.data - it runs remotely.
>> No, I realized that. I meant, since the string in the key="SWIFT_EXTRA_INFO"
>> env profile entry is a command (you showed "echo") and since (I was assuming)
>> you can specify a unique string as a profile on each tc.data entry, then one
>> could generate tc.data entries that passed enough info to this command that it
>> could find the actual app at runtime on the execution host, and echo the
>> appropriate text to stdout where it would then go to the wrapper log.
>>
>> Is this logic feasible? (Will try when I get a chance...)
>>
>> Seems that it only depends on the ability to specify a unique value for the
>> env key EXTRAINFO=$($SWIFT_EXTRA_INFO) on each tc.data entry.
>>> It probably has access the internal variables of the remote wrapper (but
>>> those shouldn't be relied on in general)
>> Right. It would get its info by using its arg to hunt down the command, or
>> take its info right from the arg.
>>
>> eg:
>>
>> sitex runrama  /home/oops/trunk/bin/runrama.bgp.sh    INSTALLED INTEL32::LINUX
>> \
>> env::SWIFT_EXTRA_INFO="getVersion.sh runrama
>> /home/oops/trunk/bin/runrama.bgp.sh"
>>
>> or:
>>
>> env::SWIFT_EXTRA_INFO="getVersion.sh runrama
>> /home/oops/trunk/bin/runrama.bgp.sh oops-2.4.1"
>>
>> would echo:
>>
>> running runrama revision 2474 -or-
>> running runrama version 2.4.1
>>
>> In the first case it can walk up the path /home/oops/trunk/bin looking for
>> application- or collaboration-specific release info (eg /home/oops/RELEASE in
>> oops's case has the svn revision) or it can look to see if the path is
>> symlinked to a version directory.
>>
>> I.e, if its not going to poke around in the remote wrapper's environment, it
>> needs to know what's being run.
>>
>> Anyways, this seems cool and I think it will work.
>>
>>>> Next we need to work on collection and summarization of the info from
>>>> wrapper.sh.  Are you doing any of that in your current provenance work?
>>> there has been code in the past to do pull stuff from wrapper logs - not a
>>> huge amount at the moment but it should be straightforward to add if there
>>> is useful information being collected.
>>>
>>