Hi Ryan!
Thanks for the comment and feedback.
Regarding Scaling Executor Plugin decision events: Yes, we can tackle this
as part of the current implementation an emit a Kubernetes event when the
scaling was vetoed and an event when the scaling was approved (in order to
see if any refinements to the summaries were performed).
Regarding Scaling Executor Plugin decision metrics: This can be implemented
internally by the plugin itself.
Regarding Scaling Executor Plugin ordering: The actual discovery order is
currently printed through `Discovered ScalingExecutorPlugin from plugin
directory[{}]: {}.` log. Further, the ordering will be made based on the
priority set each Scaling Executor Plugin. But yes, I do see the need here
for better visibility and clarity around the actual ordering. To address
that, I will introduce a small startup log that prints the plugins in the
exact order in which they will be applied.
Regarding ResourceQuota: I agree it would make an excellent open-source
reference implementation. I'll keep it out of this FLIP to keep the scope
focused.
Best regards,
Dennis
On Tue, Apr 21, 2026 at 8:13 PM Ryan van Huuksloot via dev <
[email protected]> wrote:
> Regarding:
> "No feedback mechanism: When a executor plugin vetoes scaling, the only
> feedback is a log message. There is no structured event or metric emitted
> that operators can alert on. Integration with AutoScalerEventHandler for
> executor plugin veto events is left for future work."
>
> I think adding something basic as part of this FLIP is worthwhile. It is a
> big pain point today and the plugins may further complicate understanding
> what is blocking scaling. A simple metric would help significantly.
>
> I also want to call out how important this will be:
> "The ordered chain is logged at startup for operational visibility."
> (Should we also explicitly order by priority, defaulting to lexicographical
> ordering if the priorities are the same?)
>
> Otherwise, looks great - we'd use this for our resource quotas.
> It may be useful to create an open source implementation for
> https://kubernetes.io/docs/concepts/policy/resource-quotas/. It has been
> annoying for a while, and could serve as a good open-source example.
>
> Ryan van Huuksloot
> Staff Engineer, Infrastructure | Streaming Platform
> [image: Shopify]
> <https://www.shopify.com/?utm_medium=salessignatures&utm_source=hs_email>
>
>
> On Tue, Apr 21, 2026 at 8:15 AM Gabor Somogyi <[email protected]>
> wrote:
>
> > Hi Dennis,
> >
> > +1 from my side.
> >
> > BR,
> > G
> >
> >
> > On Tue, Apr 21, 2026 at 2:08 PM Márton Balassi <[email protected]>
> > wrote:
> >
> > > Hi Dennis,
> > >
> > > +1
> > > Thanks for driving this.
> > >
> > > Marton
> > >
> > > On 2026/04/14 06:49:27 [email protected] wrote:
> > > > Hi Dennis,
> > > >
> > > > +1
> > > >
> > > > I have reviewed the proposal and it looks good to me given the
> previous
> > > approaches we have taken!
> > > >
> > > > Cheers
> > > > Gyula
> > > >
> > > > Sent from my iPhone
> > > >
> > > > > On 13 Apr 2026, at 17:17, Dennis-Mircea Ciupitu <
> > > [email protected]> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I’d like to start a discussion on FLIP-XXX: Scaling Executor Plugin
> > > SPI for
> > > > > the Flink Autoscaler [1].
> > > > >
> > > > > I’ve also opened a draft PR with a reference implementation to make
> > the
> > > > > proposal concrete and easier to review [2].
> > > > >
> > > > > Feedback and suggestions are very welcome.
> > > > >
> > > > > Best regards,
> > > > > Dennis
> > > > >
> > > > > [1]
> > > > >
> > >
> >
> https://docs.google.com/document/d/19el5lLwAj9YAx0vI1Kj8jxHr8RMNYN4-abofrvZ-C6A/edit?tab=t.0#heading=h.kldoa0q0zqmr
> > > > > [2] https://github.com/apache/flink-kubernetes-operator/pull/1085
> > > >
> > >
> >
>
