Uploaded image for project: 'Multiple Architecture Enablement'
  1. Multiple Architecture Enablement
  2. MULTIARCH-4268

Autoscaling from zero on MA-compute - other providers and upstream work

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • None
    • Support autoscaling from zero for heterogeneous worker machines
    • Future Sustainability
    • OCPSTRAT-2083Autoscaling from zero on MA-compute - other providers and upstream work
    • 0% To Do, 11% In Progress, 89% Done
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • Hide
      • [2025/07/22] The Enhancement Proposal is merged. Working on the first code changes in the core autoscaler.
      • * [03 Jul] The PR is still open, but there appears to be agreement with the community, so it should be approved as soon as the maintainers can prioritize it.
      • [17 Jun] Targetting 4.21. PR open. it carries risk due to uncertainties of how fast things will progress upstream.
      • * [12 Feb] not yet started  
      • [27 Feb] discussions started. Work partially delayed due to the need for support for the new features and release of the MTO
      • [2025/03/05] same as past week.
      • [2025/03/11] A PR to update the enhancement proposal has been opened to add the architecture and OS in the contract between Cluster API and the Cloud Providers' controllers. However, no Cloud Providers Controller implements the reconciliation for all the other fields yet, and we depend on that implementation to execute the work to add the architecture support. From the initial discussions, the first provider that will implement it and that could migrate out of the MachineAPI umbrella is AWS in 4.21. After agreement about the enhancement proposal update, this work will continue by (a) implementing the required changes in the cluster-autoscaler, (b) implementing or supporting the autoscaler team with the status reconcilers in the cloud providers, starting from the AWS one so that we get support for this from day0
      • [2025/03/25] Still pending the reviews in the upstream PR. I'll attend the next cluster API meeting to catch with the reviewers.
      Show
      [2025/07/22] The Enhancement Proposal is merged. Working on the first code changes in the core autoscaler. * [03 Jul] The PR is still open, but there appears to be agreement with the community, so it should be approved as soon as the maintainers can prioritize it. [17 Jun] Targetting 4.21. PR open. it carries risk due to uncertainties of how fast things will progress upstream. * [12 Feb] not yet started   [27 Feb] discussions started. Work partially delayed due to the need for support for the new features and release of the MTO [2025/03/05] same as past week. [2025/03/11] A PR to update the enhancement proposal has been opened to add the architecture and OS in the contract between Cluster API and the Cloud Providers' controllers. However, no Cloud Providers Controller implements the reconciliation for all the other fields yet, and we depend on that implementation to execute the work to add the architecture support. From the initial discussions, the first provider that will implement it and that could migrate out of the MachineAPI umbrella is AWS in 4.21. After agreement about the enhancement proposal update, this work will continue by (a) implementing the required changes in the cluster-autoscaler, (b) implementing or supporting the autoscaler team with the status reconcilers in the cloud providers, starting from the AWS one so that we get support for this from day0 [2025/03/25] Still pending the reviews in the upstream PR. I'll attend the next cluster API meeting to catch with the reviewers.
    • L

      Filing a ticket based on this conversation here: https://github.com/openshift/enhancements/pull/1014#discussion_r798674314

      Basically the tl;dr here is that we need a way to ensure that machinesets are properly advertising the architecture that the nodes will eventually have. This is needed so the autoscaler can predict the correct pool to scale up/down. This could be accomplished through user driven means like adding node arch labels to machinesets and if we have to do this automatically, we need to do some more research and figure out a way.

              rhn-support-adistefa Alessandro Di Stefano
              psundara@redhat.com Prashanth Sundararaman
              Brian Cogan
              None
              None
              ocp-multi-arch-ibm-partners
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: