No, applications still start as they did before, no reason to change it
May not, for example, when priority comparator enabled, how to activate apps could be determined by priority of the app instead of submission order. But it's a future requirement, we can postpone the changes to when they really needed.
No, this comes from the interface definition and it's needed to enable another scheduler, say FS, be able to use the same code with their derived application types of choice
I don't think FS will use the CapacitySchedulerConfiguration, it's not a big deal, let's keep it as-is.
So this configuration is not for defining the policy, that is "ORDERING_POLICY" (which is where you would have "fair", "fifo", etc), this is for configuration elements which may modify the behavior of the policy, such as sizeBasedWeight, & it's needed for that purpose.
Hmm.. That could be a problem after take a look at
YARN-3319. IMO, Configure OrderingPolicy should follow the style of how we configure other modules, which is using capacity-scheduler.xml in CS and using fair-scheduler.xml in FS. For individual options such as sizeBasedWeight, it's better to make it to be a separated option instead of putting all of them together. And the configure(String config) for OrderingPolicy could be problematic, I missed this point while reviewing YARN-3318, how about change it to Map<String, String> to explicitly pass option_key=value pairs to configure OrderingPolicy?
I'm actually not getting any there, I think because this is used for mocking
I can see while using eclipse, you can suppress them to avoid javac warning.