Compute Transfer examples for transfers that require a flow

[MaxTueckeGlobus]

sc-40468

For GCS collection transfer actions that require a flow, added a variation for each compute transfer example flow.

Example 1

Example 1 is for transferring files from the shared GCS compute endpoint. The shared GCS compute collection should have in its associated_flow_policy that this flow is required when it is the source of a transfer. It can take an optional destination path to save the tar file to. If it is not provided, the flow will use the random UUID from the compute function as the output destination path. The flow will then behave the same as its counterpart; creating a tarball from the src files, and transferring said tarball to the destination collection.

Example 2

Example 2 is meant for transferring files between two collections. The destination collection should have in its associated_flow_policy that this flow is required when it is the destination of a transfer. It can take an optional destination path to save the tar file to. If it is not provided, the flow will use the random UUID from the compute function as the output destination path. The flow behaves the same as its counterpart; transferring the source files into the shared GCS compute collection, creating a tarball from them, and then transferring said tarball to the specified destination.

Both flows were tested on sandbox and prod with the new webapp behavior for automatically starting a flow when trying to start a transfer from the file manager.

[sirosen]

I only have feedback on the first example so far, but as addressing it may also impact the second example I decided to post early.

These need READMEs, since the only place we currently have descriptive text about what they are and what they do is in the PR description. I'd prefer that we add them as asciidoc files, so that we have fewer conversions to do if we want to integrate these examples into the docs.globus.org publishing pipeline in the future.
Even stubby readmes -- equivalent to the current PR text -- are a very significant step up from no readme.

[MaxTueckeGlobus]

These need READMEs, since the only place we currently have descriptive text about what they are and what they do is in the PR description. I'd prefer that we add them as asciidoc files, so that we have fewer conversions to do if we want to integrate these examples into the docs.globus.org publishing pipeline in the future. Even stubby readmes -- equivalent to the current PR text -- are a very significant step up from no readme.

I have some drafted READMEs. Once we are happy with the flow definitions, I'll update them as needed and add them.

[sirosen]

I think the first example is in pretty good shape -- certainly good enough for a first draft -- although I have some inline notes on more doc which is needed.

For the second example, I don't think I can formulate good feedback without understanding the motivation behind some of what I see in there.

[sirosen]

I'm flying blind a little since I don't know what the proposed function for this example does. I find it matters most when trying to double check that the output is being used correctly here. Could we include a .py file with just the relevant function?
(I'd prefer to omit any Compute registration code and just document the function itself.)

[MaxTueckeGlobus]

It's the same compute function as the original tar and transfer examples. I wasn't sure if we wanted to include the file again

[sirosen]

I would vote for including it again, or at least providing a readme which references it in the other existing example.

I'd be better able to comment on what the right approach is if we had a readme for these examples -- I know you said you have drafts, but I think not having them as part of the proposal is impeding review.

For example, suppose I'm looking at a limitation of the example flow. If the readme says "NOTE: this example has this limitation...", then I know it's intentional. And if it's not, I can suggest that we add such a note and make it intentional. Without that documentation, it's very hard to read intent from the code itself, or to grasp these as full examples -- they're incomplete without the accompanying docs.

[MaxTueckeGlobus]

The draft docs have been added. I have yet to verify they render correctly.

[ada-globus]

@MaxTueckeGlobus Looks like this hit a failure in pre-commit (codespell flagged a typo in "initialization")

[sirosen]

Looks great! I had a very minor tweak to asciidoc rendering I noted.

I'm not sure we will want to keep all of the examples long-term, but this is good and we can refine in the future.