[SPARK-51072][CORE] CallerContext to set Hadoop cloud audit context

[steveloughran]

What changes were proposed in this pull request?

When enabled, cloud store client audit context is set to the
same context string as the Hadoop IPC context.

Why are the changes needed?

CallerContext adds information about the spark task to hadoop IPC context and then to HDFS, YARN and HBase server logs.

It is also possible to update the cloud storage "audit context".
Storage clients can attach the audit information to requests to be stored in the service's own logs, where it can be retrieved, parsed and used for analysis.

It is currently supported by the S3A connector, which adds the information to a synthetic referrer header, which is then stored in the S3 Server logs. (Not cloudtrail, sadly).

See S3A Auditing

Does this PR introduce any user-facing change?

If enabled, it adds extra entries in cloud storage server logs through cloud
storage clients which support it.

How was this patch tested?

Expanded existing test "Set Spark CallerContext" to verify
full setting of passed down parameters to caller and audit contexts.
This required extracting the functional code of CallerContext.setCurrentContext
into a @VisibleForTesting private[util] method setCurrentContext(Boolean)

Without this, the test suite only ran if the process had been launched
with the configuration option "hadoop.caller.context.enabled being set
to true -this is not the default, so the existing test suite code
was probably never executed.

Was this patch authored or co-authored using generative AI tooling?

No

[dongjoon-hyun]

Thank you for making a PR. This one line seems to be the actual change. Did I understand correctly?

[steveloughran]

yes! Rest of it is test related

[dongjoon-hyun]

According to the PR title, do you mean S3 Audit Context feature has been broken until now ? Otherwise, could you revise the PR title by narrowing down the scope more specifically?

[SPARK-51072][CORE] CallerContext to set Hadoop cloud audit context

[cnauroth]

+1 (non-binding). This will be useful. Thanks, @steveloughran !

[cnauroth]

According to the PR title, do you mean S3 Audit Context feature has been broken until now ? Otherwise, could you revise the PR title by narrowing down the scope more specifically?

[SPARK-51072][CORE] CallerContext to set Hadoop cloud audit context

From the perspective of Spark or other clients of the file system, they are interacting with a general auditing feature defined in the Hadoop Common module. In theory, multiple file systems could implement support for actually recording this audit information. AFAIK, only S3A implements it right now. (We don't have it in the GCS file system.) Other file systems could eventually choose to implement it though.

[dongjoon-hyun]

Ya, IIUC, without this PR, S3A audit has been working already as designed, hasn't it?

[steveloughran]

@dongjoon-hyun audit context has been working properly, but spark info not wired up. Other things get in (process Id, UGI, filesystem id, underlying operation for a sequence), but the actual spark job didn't get in. Once an s3a or manifest committer was started, it'd set the app and job ID values -but they only get involved during the write phase -and they didn't get the full spark context info

[steveloughran]

@cnauroth well, you should -if you can get it anywhere into your logs, possibly as a new http header. s3afs attaches as an http referrer as it is the sole entry other than UA which goes into the standard S3 logs -and other things like to set that UA field.

[dongjoon-hyun]

Got it. Please let me know when the PR is ready, @steveloughran .

[steveloughran]

I can't think of any changes, unless we want to set that audit stuff even if caller context is not being set.

[cnauroth]

Once again putting a +1 (non-binding) on this, now that it has been updated to be consistent with the testing strategy from #49893 and #49898. Thanks again, @steveloughran .

[dongjoon-hyun]

+1, LGTM. Thank you, @steveloughran and @cnauroth .

Merged to master for Apache Spark 4.1.0.