Hi Lianet, Thanks for reviewing the KIP. I want to avoid having to cascade changes to group configs when the broker config is changed. Instead, the group config is applied, the value is capped using the broker configs. We can log situations in which the group config is outside the bounds specified by the broker configs to help the administrator, but I feel that this is unlikely to be a common situation in practice.
Thanks, Andrew On 2026/01/27 03:33:39 Lianet Magrans wrote: > Thanks for the KIP Andrew! Nice alignment on configs validation/enforcement. > > Just one comment regarding the behaviour on broker configs updates, > this: "*When > a broker configuration is updated, the existing group configurations are > not validated. This ensures that the administrator is able to tighten or > relax limits easily*." > I agree with the approach, seems sensible to allow broker-level configs to > go in without getting blocked on the lower-priority group-level configs. > But this allows an inconsistent state (group configs out of bound) that the > administrator will have to eventually fix (or just live with it, confusing > and with no added value). Would it make sense to align the group-level > configs with the new boundaries if they fall out of it when a broker-level > config is updated? Not sure if this could have other implications, but > sounds consistent. > > Thanks! > Lianet > > On Mon, Jan 19, 2026 at 6:28 AM Andrew Schofield <[email protected]> > wrote: > > > I have updated the KIP and intend to open voting tomorrow if there are no > > additional comments. > > > > Thanks, > > Andrew > > > > On 2026/01/13 10:09:44 Andrew Schofield wrote: > > > Hi Chia-Ping, > > > That seems like a very sensible approach. I will update the KIP > > accordingly. > > > > > > Thanks, > > > Andrew > > > > > > On 2026/01/09 19:04:47 Chia-Ping Tsai wrote: > > > > hi Andrew, > > > > > > > > I'd like to propose a hybird approach for handling these bounds, > > treating the broker-level configs as a "safety cap" rather than just a > > static validator. > > > > > > > > here is the logic: > > > > > > > > 1. on group config update (strict validation): we validate it against > > the current broker-level cap. If it exceed the cap, we reject the request. > > This prevents new invalid configs from entering the system > > > > > > > > 2. on broker config update (non-blocking): we don't validate against > > existing groups. This ensures that admins can tighten limits uring an > > emergency > > > > > > > > 3. at runtime (effective value enforcement): the broker uses the logic > > `min(groupConfig, brokerCap). Even if a legacy group config is higher than > > the new broker cap (due to step 2), the runtime behavious will be clamped > > to the broker cap > > > > > > > > WDYT? > > > > > > > > Best, > > > > Chia-Ping > > > > > > > > On 2026/01/07 17:24:21 Andrew Schofield wrote: > > > > > Hi Chia-Ping, > > > > > Thanks for your comments. > > > > > > > > > > chia_00: The group-level configs are all dynamic. This means that > > when the limits > > > > > are reduced, they may already be exceeded by active usage. Over > > time, as records > > > > > are delivered and locks are released, the system will settle within > > the new limits. > > > > > > > > > > chia_01: This is an interesting question and there is some work off > > the back of it. > > > > > > > > > > For the interval and timeout configs, the broker will fail to start > > when the group-level > > > > > config lies outside the min/max specified by the static broker > > configs. However, the > > > > > logging when the broker fails to start is unhelpful because it omits > > the group ID of > > > > > the offending group. This behaviour is common for consumer groups > > and share groups. > > > > > I haven't tried streams groups, but I expect they're the same. This > > should be improved > > > > > in terms of logging at the very least so it's clear what needs to be > > done to get the broker > > > > > started. > > > > > > > > > > For share.record.lock.duration.ms, no such validation occurs as the > > broker starts. This > > > > > is an omission. We should have the same behaviour for all of the > > min/max bounds > > > > > I think. My view is failing to start the broker is safest for now. > > > > > > > > > > For the new configs in the KIP, the broker should fail to start if > > the group-level config > > > > > is outside the bounds of the min/max static broker configs. > > > > > > > > > > wdyt? I'll make a KIP update when I think we have consensus. > > > > > > > > > > Thanks, > > > > > Andrew > > > > > > > > > > On 2026/01/05 13:56:16 Chia-Ping Tsai wrote: > > > > > > hi Andrew > > > > > > > > > > > > Thanks for the KIP. I have a few questions regrading the > > configuration behaviour: > > > > > > > > > > > > chia_00: Dynamic Update Behavior > > > > > > Are these new group-level configuration dynamic? Specifically, if > > we alter share.delivery.count.limit or share.partition.max.record.locks at > > runtime, will the changes take effect immediately for active share group? > > > > > > > > > > > > chia_01: Configuration Validation on Broker Restart > > > > > > How does the broker handle existing group configuration that fall > > out of bounds after a broker restart? For example, suppose a group has > > share.partition.max.record.locks set to 100 (which is valid at the time). > > If the broker is later restarted with a stricter limit of > > group.share.max.partition.max.record.locks = 50, how will the group loaded > > handle this conflict? > > > > > > > > > > > > Best, > > > > > > Chia-Ping > > > > > > > > > > > > On 2025/11/24 21:15:48 Andrew Schofield wrote: > > > > > > > Hi, > > > > > > > I’d like to start the discussion on a small KIP which adds some > > configurations for share groups which were previously only available as > > broker configurations. > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1240%3A+Additional+group+configurations+for+share+groups > > > > > > > > > > > > > > Thanks, > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > >
