[
https://issues.apache.org/jira/browse/YARN-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070605#comment-16070605
]
Jason Lowe commented on YARN-6753:
----------------------------------
The approach I proposed also leverages protobufs, passing a new version field
in the client request instead of a new detailed info field in the server
response. At a high level they're the same concept -- pass new information in
a field that old code will ignore.
I personally think it's cleaner for users to extend the existing enum
transparently to the user's code (i.e.: the client version shenanigans will be
hidden by the yarn client layer), but it does complicate the server code since
it has to translate the container state to the appropriate list of enums. I
don't feel super strongly about it either way. If we create a separate
detailed field, note we'll have the same dilemma if we later add a new
container state. Would we then have a "super detailed" state? ;-)
> Expose more ContainerImpl states from NM in ContainerStateProto
> ----------------------------------------------------------------
>
> Key: YARN-6753
> URL: https://issues.apache.org/jira/browse/YARN-6753
> Project: Hadoop YARN
> Issue Type: Bug
> Components: nodemanager
> Reporter: Roni Burd
> Priority: Minor
>
> The current NM protobuf definition exposes a subset of the NM internal state
> via ContainerStateProto.
> We are currently building tools that can use of more fine grain state like
> LOCALIZING, LOCALIZED, EXIT_WITH_FAILURES etc.
> The proposal is to add more internal states in the API.
> I'm not sure if this is considered an Incompatible change or not
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
