meeting zoom (passcode: 77777) Meetings are scheduled for 19:00 UTC, immediately following the Cluster API office hours. Please add agenda items for future meetings here: <add name and agenda topic above here ex. [name] topic> 2025-03-19 @ 19:00 (UTC) recording

Capturing some of the work that will need to be done to expand the coverage of the opt-in autoscaling from zero feature in Cluster API. Subsections of this document will cover specific providers and the necessary changes in each to support scale from zero as an automated process. The overall process for adding capacity information is as follows: reconcile infrastructure machine template resources for provider look up instance information from infrastructure machine template add status.capacity to the infrastructure machine template Open Questions For any given provider, what is the most convenient/efficient way to learn the capacity information?on some providers this may involve a call to a cloud service

Topics machine learning and autoscalerhttps://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/proposals/provisioning-request.md how to handle GPUs how will CAS handle DRA? bottlenecks in CAS, where are they? moving running PODs, is this possible?

After discussion during the 1 May 2024 feature group meeting, we are reevaluating what types of custom resources the capi provider will utilize. Originally, we had the notion of talking directly to the InfrastructureMachineTemplates and creating orphan Machines to manage resources. But, this approach loses all the contextual information that a user might encode in their MachineDeployments, and this is degredation of the core capi experience. To quote from the Cluster API manifesto on the topic of simplicity: Kubernetes Cluster lifecycle management is a complex problem space, especially if you consider doing this across so many different types of infrastructures. Hiding this complexity behind a simple declarative API is “why” the Cluster API project ultimately exists. The project is strongly committed to continue its quest in defining a set of common API primitives working consistently across all infrastructures (one API to rule them all). Working towards graduating our API to v1 will be the next step in this journey.

Capturing some thoughts and ideas about creating a set of generic CCM tests for use by the wider cloud provider community. These tests will be owned by SIG Cloud Provider and be used as a baseline for ensuring that all external CCMs have a minimal signal for testing. Background For several years now (see kubernetes issue#70194) there has been a desire to remove the provider specific details which exist in the main kubernetes repository. Currently, the tests in the test/e2e/cloud and test/e2e/network which exercise functionality of the cloud controllers are gated by logic which detects the underlying infrastructure platform. Some of these tests also contain instructions which can only be executed on those specific platforms. This creates a situation where the tests in the kubernetes/kubernetes repository have a direct dependency on the specific cloud provider platforms. Ideas These are some ideas captured after reviewing the available material, and talking with members of SIG Cloud Provider, SIG Storage, and SIG Testing to help drive the conversation forward towards creating a set of generic cloud controller tests in kubernetes.

This document provides a brief overview of the Mastodon social network for the OKD community to assist in our understanding of the technology as it pertains to broadcasting OKD news and updates. What is Mastodon? Mastodon is free and open-source software for running self-hosted social networking services. It has microblogging features similar to Twitter, which are offered by a large number of independently run nodes, known as instances, each with its own code of conduct, terms of service, privacy policy, privacy options, and content moderation policies. Wikipedia How is Mastodon Different from Twitter? Decentralized Mastodon instances are separate from each other and use the ActivityPub standard to share information, contributing to what is informally known as the “Fediverse”.

looking at the use of Expect, Eventually, and Consistently in the cluster-api-actuator-pkg. summary breaking up by package is probably the best for making cards. looks like we have three sizes large infra