[Swift-devel] a note on stress testing

[Michael Wilde]

> ... my understanding was that we'd need three types on
> runs based on where swift runs:

> -> Local | Local ( Swift runs locally with jobs also run locally )
> -> Local | Remote ( Swift runs locally but the compute resources
> are remote providers ? )
> -> Remote | Local ( Swift instantiated on a remote system to
> coordinate resources locally )

Right.

> In the case you have pointed out, Swift on Midway submits jobs to
> beagle.

> Is this a remote|remote type which I haven't listed?

Not by itself: its "local|remote".

But you can *initiate* this test remotely, making it "remote|remote".

So while all 4 boxes of this 2x2 matrix make sense, ultimately you could think of all the tests being initiated from a test service like Jenkins, so *all* tests would be "remote" in column one of your list above. That simplifies the way you can organize the test plan and execution mechanism.

> Can we expect to
> see the same errors,
> if we were to run swift on an MCS machine to submit the same jobs to
> beagle?

Yes, I think in this particular case, the main errors were not caused by the environment in the submitting system (midway hosts).  But they very well *could have been*.  For example, if we only test on hosts that have single network interfaces, we'd never see known errors related to not handling the multiple-NIC case correctly.  And in fact in our testing yesterday this was indeed an issue thats still unresolved: whether GLOBUS_HOST or the equivalent sites.xml tag needs to be set to a dotted IP or could accept a DNS FQDN, and under what circumstances. This needs both testing *and* documentation. Similar issues apply to hosts with various firewall/iptables settings.

- Mike