Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proportion bug in cluster with multi extend resource #550

Closed
lminzhw opened this issue Nov 25, 2019 · 2 comments
Closed

Proportion bug in cluster with multi extend resource #550

lminzhw opened this issue Nov 25, 2019 · 2 comments
Labels
area/scheduling kind/bug Categorizes issue or PR as related to a bug. priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now.
Milestone

Comments

@lminzhw
Copy link
Contributor

lminzhw commented Nov 25, 2019

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug

What happened:

Firstly, we have a case

Cluster have 2 extend resource Ra, Rb, 2 queues Qa, Qb with different weight.
For example, we have 10Ra, 10Rb allocatable, Qa weight 1, Qb weight 100.
Now, Qa request 100 Ra, Qb request 100 Rb.

In this case, we wanna to assign 10Ra to Qa and 10 Rb to Qb.


But, the result is not as we expected.

if attr.request.Less(attr.deserved) {

At here, Less means request should be less than deserved in every resource.

In this case, the Less func will not treat Qb as meet state, it means almost all Ra will be assigned to it. So, the pod in Qa would hardly be scheduled.

What you expected to happen:

I think do propotion in every resource may fix this.

for resource, quantity in cluster.allocatable {
    assign allocatable resource to every queue by weight
}
@volcano-sh-bot volcano-sh-bot added the kind/bug Categorizes issue or PR as related to a bug. label Nov 25, 2019
@lminzhw
Copy link
Contributor Author

lminzhw commented Nov 25, 2019

/cc @k82cn @sivanzcw

@k82cn k82cn added area/scheduling priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now. labels Nov 26, 2019
@k82cn k82cn added this to the v0.3 milestone Nov 26, 2019
@k82cn
Copy link
Member

k82cn commented Dec 19, 2019

Should be fixed by #599 .

@k82cn k82cn closed this as completed Dec 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/scheduling kind/bug Categorizes issue or PR as related to a bug. priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now.
Projects
None yet
Development

No branches or pull requests

3 participants