Fix: fix an issue where the wrong action name could not be ignored

[xieyanke]

What type of PR is this?

/kind bug
/area scheduling

What this PR does / why we need it:

fix an issue where the wrong action name could not be ignored

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?

[volcano-sh-bot]

Welcome @xieyanke!

It looks like this is your first PR to volcano-sh/volcano.

Thank you, and welcome to Volcano. 😃

[volcano-sh-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign k82cn
You can assign the PR to them by writing /assign @k82cn in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• pkg/scheduler/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[xieyanke]

/assign @k82cn

[bogo-y]

I think that should not be ignored.
For example, when a user makes a typo mistake such as typing "allocated" instead of "allocate", it is better to detect and resolve the issue immediately.

[Monokaix]

I think that should not be ignored. For example, when a user makes a typo mistake such as typing "allocated" instead of "allocate", it is better to detect and resolve the issue immediately.

Currently there is a log showing the message.

[bogo-y]

Currently there is a log showing the message.

There is too much messages when vc-scheduler just start... Maybe we need keep use klog.Errorf to make it highly visible?

[xieyanke]

Currently there is a log showing the message.

There is too much messages when vc-scheduler just start... Maybe we need keep use klog.Errorf to make it highly visible?

Since actions are configurable, it’s reasonable to allow ignoring user misconfigurations while providing warning-level log messages.
I think your concern can be addressed through another feature "action classification". Some actions, such as "enqueue or allocate" are essential and require action validation, while others can be optionally ignored.

[bogo-y]

Currently there is a log showing the message.

There is too much messages when vc-scheduler just start... Maybe we need keep use klog.Errorf to make it highly visible?

Since actions are configurable, it’s reasonable to allow ignoring user misconfigurations while providing warning-level log messages. I think your concern can be addressed through another feature "action classification". Some actions, such as "enqueue or allocate" are essential and require action validation, while others can be optionally ignored.

There is no benefit to keep a wrong action name in configuration file, and if users discovered a mistake like this, they will fix it very easily.
just my personal opinion

[Monokaix]

Currently there is a log showing the message.

There is too much messages when vc-scheduler just start... Maybe we need keep use klog.Errorf to make it highly visible?

Since actions are configurable, it’s reasonable to allow ignoring user misconfigurations while providing warning-level log messages. I think your concern can be addressed through another feature "action classification". Some actions, such as "enqueue or allocate" are essential and require action validation, while others can be optionally ignored.

It's not a good way to classify different actions, all actions are important.

[Monokaix]

Currently there is a log showing the message.

There is too much messages when vc-scheduler just start... Maybe we need keep use klog.Errorf to make it highly visible?

Since actions are configurable, it’s reasonable to allow ignoring user misconfigurations while providing warning-level log messages. I think your concern can be addressed through another feature "action classification". Some actions, such as "enqueue or allocate" are essential and require action validation, while others can be optionally ignored.

There is no benefit to keep a wrong action name in configuration file, and if users discovered a mistake like this, they will fix it very easily. just my personal opinion

How about change Warning to Error?

[bogo-y]

How about change Warning to Error?

I think it's better than just use warning.

FYI: https://github.com/kubernetes/kubernetes/blob/release-1.32/pkg/scheduler/framework/runtime/framework.go#L658

[xieyanke]

How about change Warning to Error?

I think it's better than just use warning.

FYI: https://github.com/kubernetes/kubernetes/blob/release-1.32/pkg/scheduler/framework/runtime/framework.go#L658

Okey agreed, I'll make the changes.