[jira] [Comment Edited] (HADOOP-17276) Extend CallerContext to make it include many items

["Mingliang Liu (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HADOOP-17276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202490#comment-17202490 ] 

Mingliang Liu edited comment on HADOOP-17276 at 9/26/20, 2:06 AM:
------------------------------------------------------------------

So, for the code reviews, I'll leave comments about implementation in the pull request. Allow me sort my understanding out here:

# This is compatible change because it does not enforce any format of the existing caller context. This is very important to confirm. The initial {{CallerContext}} design used a plain string format instead of {{key:value,key:value}} format for sake of flexibility and simplicity. Audit log per se is using {{key=value}} format and was not designed with nested structure in mind. I believe every time we revisit audit format, people would think of better ways e.g. JSON. But compatibility - not only code setting it but also existing tools parsing it - is always one of the key concern.
# Here for easier appending more information into the caller context in an organized way, in this JIRA we propose that user can call multiple times {{builder.append(key, value)}} to append information into the context. The CallContext object once constructed is still immutable as it is. So we are not changing any existing behavior in this proposal.

Given above points, I would be +1 on this.

For the implementation, one point is not allowing "=" or "\t" as the separator of the key/value items in the context string. This is because the audit log itself is using = to separate key/values in every top-level field, and using "\t" to separate top-level fields.

CC: [~jitendra] [~stevel] [~[~inigoiri] and [~aajisaka]

Thanks,


was (Author: liuml07):
So, for the code reviews, I'll leave comments about implementation in the pull request. Allow me sort my understanding out here:

# This is compatible change because it does not enforce any format of the existing caller context. This is very important to confirm. The initial {{CallerContext}} design used a plain string format instead of {{key:value,key:value}} format for sake of flexibility and simplicity. Audit log per se is using {{key=value}} format and was not designed with nested structure in mind. I believe every time we revisit audit format, people would think of better ways e.g. JSON. But compatibility - not only code setting it but also existing tools parsing it - is always one of the key concern.
# Here for easier appending more information into the caller context in an organized way, in this JIRA we propose that user can call multiple times {{builder.append(key, value)}} to append information into the context. The CallContext object once constructed is still immutable as it is. So we are not changing any existing behavior in this proposal.

Given above points, I would be +1 on this.

For the implementation, one point is not allowing "=" or "\t" as the separator of the key/value items in the context string. This is because the audit log itself is using = to separate key/values in every top-level field, and using "\t" to separate top-level fields.

CC: [~jitendra] [~stevel] [~goiri] and [~aajisaka]

Thanks,

> Extend CallerContext to make it include many items
> --------------------------------------------------
>
>                 Key: HADOOP-17276
>                 URL: https://issues.apache.org/jira/browse/HADOOP-17276
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: Hui Fei
>            Assignee: Hui Fei
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Now context is string. We need to extend the CallerContext because context may contains many items.
> Items include 
> * router ip
> * MR or CLI
> * etc



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org