Sounds good all around - thanks! Ryan van Huuksloot Staff Engineer, Infrastructure | Streaming Platform [image: Shopify] <https://www.shopify.com/?utm_medium=salessignatures&utm_source=hs_email>
On Thu, Apr 23, 2026 at 5:02 AM Dennis-Mircea Ciupitu < [email protected]> wrote: > 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 >> > > > >> > > >> > >> >
