[
https://issues.apache.org/jira/browse/YARN-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070427#comment-16070427
]
Roni Burd edited comment on YARN-6753 at 6/30/17 5:13 PM:
----------------------------------------------------------
[~jlowe] : So the thought is to add a version number to the request, call the
existing one v1 and make it the default in protobuf, and if clients ask for v2,
then pass the extra params.
Another way of doing it is to add this as "detailed state". So the old states
remain as is, but if anyone is interested in the details it can query the state
more. This takes advantage of protobufs instead of needing to add a new version
field.
Any other thoughts?
was (Author: roniburd):
[~jlowe] : Makes sense. So the thought is to add a version number to the
request, call the existing one v1 and make it the default in protobuf, and if
clients ask for v2, then pass the extra params.
Any other concerns?
> 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: [email protected]
For additional commands, e-mail: [email protected]
