[YUNIKORN-2991] The queue in Draining state does not accept new applications

[rhh777]

What is this PR for?

When the queue is in the Drafting state, new applications are still allowed to be scheduled after submission.
I think we should refuse.

What type of PR is it?

• - Improvement

What is the Jira issue?

https://issues.apache.org/jira/browse/YUNIKORN-2991

How should this be tested?

Unit tests included

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.35%. Comparing base (f7d0e10) to head (f3d2d18).
Report is 6 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1002      +/-   ##
==========================================
+ Coverage   81.57%   82.35%   +0.78%     
==========================================
  Files          97       97              
  Lines       15656    15635      -21     
==========================================
+ Hits        12771    12876     +105     
+ Misses       2601     2479     -122     
+ Partials      284      280       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[wilfred-s]

See my comment in the jira, can we investigate doing the check in the AppPlacementManager?

[rhh777]

I have made the suggested modifications, and now the rejected information in the pod event information is not very clear. Should we display more rejection information?

Before modification

After modification

See my comment in the jira, can we investigate doing the check in the AppPlacementManager?

[wilfred-s]

I have made the suggested modifications, and now the rejected information in the pod event information is not very clear. Should we display more rejection information?

I think that is a problem on the shim side. When I look at the processing of the rejection there it does this:

func (app *Application) handleRejectApplicationEvent(reason string) {
	log.Log(log.ShimCacheApplication).Info("app is rejected by scheduler", zap.String("appID", app.applicationID))
	// for rejected apps, we directly move them to failed state
	dispatcher.Dispatch(NewFailApplicationEvent(app.applicationID,
		fmt.Sprintf("%s: %s", constants.ApplicationRejectedFailure, reason)))
}

It skips the rejected state and goes to failed. That is something we can follow up separately. I think the code change beside the two nits on the core side is looking good now.

[rhh777]

I have made the suggested modifications, and now the rejected information in the pod event information is not very clear. Should we display more rejection information?

I think that is a problem on the shim side. When I look at the processing of the rejection there it does this:

func (app *Application) handleRejectApplicationEvent(reason string) {
	log.Log(log.ShimCacheApplication).Info("app is rejected by scheduler", zap.String("appID", app.applicationID))
	// for rejected apps, we directly move them to failed state
	dispatcher.Dispatch(NewFailApplicationEvent(app.applicationID,
		fmt.Sprintf("%s: %s", constants.ApplicationRejectedFailure, reason)))
}

It skips the rejected state and goes to failed. That is something we can follow up separately. I think the code change beside the two nits on the core side is looking good now.

Okay, we can optimize it in shim when we have time.