-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
azure-pipelines scaler: exact match demands (don't match jobs without capability) #4138
Comments
Hi @patst, |
@JorTurFer thanks for your reply.
I will try to come up with a pull request the next days |
nice! |
@patst @JorTurFer thank you. This feature is very important and useful for us as well. |
…core#4138 Signed-off-by: Patrick Steinig <patrick.steinig@googlemail.com>
…core#4138 Signed-off-by: Patrick Steinig <patrick.steinig@googlemail.com>
…core#4138 Signed-off-by: Patrick Steinig <patrick.steinig@googlemail.com> Signed-off-by: patst <patrick.steinig@googlemail.com>
…core#4138 Signed-off-by: Patrick Steinig <patrick.steinig@googlemail.com> Signed-off-by: patst <patrick.steinig@googlemail.com>
…core#4138 Signed-off-by: Patrick Steinig <patrick.steinig@googlemail.com> Signed-off-by: patst <patrick.steinig@googlemail.com>
Proposal
We are using the azure-pipelines scaler and configuring the capability support introduced with #2328 .
Example trigger config:
I would like to have an attribute like
requireDemands
to configure that a scaled object for above trigger is only scaled if the Azure DevOps job is requesting a capability named "4gb".Use-Case
We have different types of build agents running inside a kubernetes cluster.
Our internal developer use these buildagents and they are autoscaled by KEDAs azure-pipelines scaler.
All buildagents are in the same Nodepool (e.g. DEV) but have different configurations regarding CPU and RAM limits.
At the moment everything works fine, when a demand is configured an the Azure DevOPs pipeline:
If the pipelines to not specify a demand all buildagent types are scaled and one auf dem randomly picks the waiting job. The others are scaled even if there is no work left for them.
This behaviour is documented in the docs (Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.).
Wouldn't it be great to add the configuration to only scale up if the demands configured in an trigger are all requested by and job?
I think the logic could be implemented here: https://github.com/kedacore/keda/blob/main/pkg/scalers/azure_pipelines_scaler.go#L367
Just check if every demand from the trigger is requested by the job.
Is this a feature you are interested in implementing yourself?
Yes
Anything else?
An alternative to this would be a configuration flag like
matchEmptyDemands: false
(with a default valuetrue
) which only checks if the Job requests anything as demand. GitLab runners allow this with a flag called--run-untagged=false
This way we would be able to provide a "default" scaledObject without any demands.
Our usecase would be fulfilled by this behaviour and it is probably even easier to implement.
WDYT?
The text was updated successfully, but these errors were encountered: