[
https://issues.apache.org/jira/browse/MAPREDUCE-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103633#comment-13103633
]
Robert Joseph Evans commented on MAPREDUCE-2790:
------------------------------------------------
{quote}
In short, the switcheroo is intentional.
In long: One of the changes requested by Ramya was for Scheduling Info to
display the information analogous to what is displayed in 0.20. This is
provided by the getContainerInfo(). getSchedulingInfo() provides the URL for
the AM. (the AM info).
{quote}
Can you please comment this better then, because just about everyone who looked
at the code thought it was a bug.
{quote}
Which binary compatibility are we talking about here? Between which two
versions? The constructor signatures have been changed significantly between
0.20 and 0.23 already. 0.23 hasn't been released yet.
JobStatus in 0.23 is quite far removed from that in 0.20. In my opinion I think
we should mark these interfaces as unstable for some time.
{quote}
I am talking about compatibility between 0.20 and 0.23. Specifically there is
user code out there that might use some of these interfaces and it would be
nice to not require them to look up new APIs and change their code to get the
same behavior as before. That is why the API is marked as public and stable.
Adding in new constructors or methods will not break compatibility, but
changing the parameters to existing ones will. If it is simple to do I would
prefer that we do it. If the constructor signatures have already changed
between 0.20 and 0.23 then don't worry about them.
{quote}
Furthermore it provides no tangible benefit.
{quote}
I disagree. It does not provide a benefit right now, but I have heard a
request to have the list of containers being used by an application be
accessible (I don't know the JIRA if there is one yet). I can see lots of use
cases coming in the future to be able to have access to this type of
information. Also what happens in the future if we ever do decided to do
localization? The Resource Manager before it returns a string will have to
know what the local is for the user it is talking to. Providing raw data, and
then formatting that data at the interface level I think is a lot cleaner then
returning an arbitrarily formatted string.
{quote}
As we add other attributes to containers, the data structure you proposed will
have to be modified (to include CPU / disk etc).
{quote}
I agree and it may take a bit more effort to think about how you want to set up
the data structure so it can expand easily. But just because it is harder does
not mean it is not the right thing to do. Perhaps you just provide a summary
in the job info with the container usage data in it and then in the future we
have a separate API to get the details of containers used.
{quote}
The commit that introduced the TODO line corresponds to
https://issues.apache.org/jira/browse/MAPREDUCE-2807. I did not find an
associated JIRA. Do we have JIRAs associated to all the TODO's in code? We
should. And then reference them in the TODO line. But I'm afraid I couldn't
find a JIRA corresponding to this line.
{quote}
I agree with all TODOs need a JIRA. I thought at some point there was a JIRA
to look at all the TODOs in MRV2 and fix/file JIRAs for them. I am not sure
what happened to that. If you could start putting the JIRA in the TODO
comments for filing a JIRA for any TODOs that would be great. I was just
curious because the scope of that TODO has now increased with this change and
it would be nice to update the JIRA accordingly.
> [MR-279] Add additional field for storing the AM/job history info on CLI
> ------------------------------------------------------------------------
>
> Key: MAPREDUCE-2790
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2790
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mrv2
> Affects Versions: 0.23.0
> Reporter: Ramya Sunil
> Assignee: Ravi Prakash
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-2790.v1.txt, MAPREDUCE-2790.v2.txt
>
>
> bin/mapred job [-list [all]] displays the AM or job history location in the
> "SchedulingInfo" field. An additional column has to be added to display the
> AM/job history information. Currently, the output reads:
> {noformat}
> JobId State StartTime UserName Queue Priority
> SchedulingInfo
> jobID FAILED 0 ramya default NORMAL AM
> information/job history location
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
