True however what this actually represents is the state of the current attempt's AM.
That's not true and which I am trying to impress upon. ApplicationState.New and ApplicationState.SUBMITTED don't even represent any state of the AM. ApplicationState.RUNNING means multiple things: it may be that an AM is running, or it may also mean that AM is down and in the process of restarting. ApplicationState.FAILED may actually mean that the platform is not even able to launch the AM for some reason.
To be semantically correct, RMAppAttemptState represents the AM state, ApplicationState is much more than RMAppAttemptState, it subsumes the whole application including any and all app-attempts.
A submitted/running/completed AM only really implies the state of the AM and it would be better if we changed this from ApplicationState to ApplicationMasterState to avoid confusion as to what it really implies.
Ditto. Like I pointed above, ApplicationState.Running doesn't map directly to a running AM, neither does ApplicationState.FAILED represent actual job-failure.
From the perspective of a client, a client would prefer to assume that the application 'finish' state is whether my "job" completed successfully or not.
Not sure if you worked with other resource-managers which give you an ability to run your own code. In torque, for example, the corresponding state for ApplicationState.FINISHED only means the app has finished. To know what happened to your actual job, you need a separate state.
The RM does not need to act on it today so a string should work. However, the question is whether using a flexible string/blob based approach is the way to go? I, in particular, do not have any preference over string/enum.
I prefer the blob approach as having an enum is stricter and obviously we cannot have an enum representing final-states for all possible frameworks.
A client would monitoring AppMasterState for completion ( succeeded/failed/killed ) and if succeeded, look at the ApplicationFinishState to actually verify that the work was done successfully.
Given above, a client would be instead monitoring for ApplicationState, if it is one of the final states SUCCEEDED, FAILED or KILLED, it will look at the corresponding ApplicationReport.FinalFrameworkState to see what actually happened to the job.
Apologies if I am giving an impression of creating a storm. But honestly all of this was thought through earlier end-to-end and I firmly belive that the current states and records represent the correct abstraction.