This bit that I added to the FLIP is perhaps worthy of a bit more scrutiny, as it's based on my assumptions (misunderstandings?) of how the FKO project works.
In the section "Promoting MiniCluster to a stable API" I asserted: > For the Flink Kubernetes Operator project to provide a launcher > as an example project would depend on the core Flink project > promoting some MiniCluster components to @PublicEvolving ... > This is not a technical requirement, as the current > proof-of-concept demonstrates that the existing API is sufficient > - the promotion recommended here is of MiniCluster’s existing > submission surface. The requirement is about the Operator project > managing risk by building upon a stable contract. ... Is that really a requirement or have I just invented that? :) Looking more closely at the existing code, I can see we already have plenty of uses of flink-runtime classes that don't have @Public / @PublicEvolving annotations, so my usage of flink-runtime classes like the MiniCluster and MiniClusterConfiguration wouldn't be without precedent. While I still think it'd be lovely to build this feature solely on stable APIs, maybe I'm creating an unreasonably high bar to clear by framing it this so strongly. What do you think? What are the norms here? Kind regards Dale -- dalelane.co.uk On Wednesday, 5 August 2026 at 16:02, Dale Lane <[email protected]> wrote: > I'd like to start a discussion on > FLIP-XXX : Running Flink jobs in MiniCluster using the Kubernetes Operator > https://docs.google.com/document/d/1dtGjPYcsBkx1vxHPs1QnDtPxeH_Acz_pl8gx4b1BLB4/edit?usp=sharing > > The aim of the FLIP is to extend the Flink Kubernetes Operator to offer a > single-pod, light-weight deployment option for low-throughput jobs. > > From the motivation: > A single-pod, self-contained Flink job that starts fast and needs no > multi-pod coordination could be a good fit for low-throughput jobs that > aren't suitable for session clusters because they need isolation. > > Looking forward to feedback, both on the general motivation (Have you seen a > need for very small lightweight Flink jobs where fast crash-consistent resume > is good enough without a full distributed Flink cluster?) and the suggested > implementation approach (Do you think a new custom resource kind is the best > way to represent this capability?) > > Kind regards > > Dale > -- > dalelane.co.uk >
