Increase NodePool requirements `maxItems`

kubernetes-sigs / karpenter

Karpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.

Apache License 2.0

560 stars 185 forks source link

Increase NodePool requirements `maxItems` #1270

Open NetanelK opened 4 months ago

NetanelK commented 4 months ago

Description

What problem are you trying to solve? While working on aws/karpenter-provider-aws#5779 I've reached the maximum limit of 30 requirements per node pool, to support more requirements from providers, the maxItems limit needs to be increased.

karpenter-provider-aws tests should support combined instance type labels.

How important is this feature to you? This feature is needed to expand karpenter abilities to select instances more granularly.

I'd be happy to contribute this small adjustment if approved.

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

k8s-ci-robot commented 4 months ago

This issue is currently awaiting triage.

If Karpenter contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.

NetanelK commented 4 months ago

cc @jonathan-innis

jmdeal commented 3 months ago

I believe this limit had to do with CEL limitations around cost estimation. @engedaam do you remember if this was the original reason?

k8s-triage-robot commented 1 week ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue as fresh with /remove-lifecycle stale
Close this issue with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale