Hi Jonas, When creating this Gitlab issue, please be sure and provide a use-case for this change.
You are describing placing a class membership guard on the subnet or pool (client-classes) while simultaneously not evaluating the client's membership in the class (evaluate-additional-classes) unless the subnet or pool is chosen. This seems to be a logic error. I suggest that you consider separating the class(s) that guard pool selection or the evaluate-additional-classes to disparate subnets such that they are not the same classes. This would allow you to assign parameters (options or whatever) via the "evaluate-additional-classes" mechanism but only if the pool was selected via membership in another class(s) via the "client-classes" mechanism. You also may be interested in https://kea.readthedocs.io/en/kea-2.7.5/arm/classify.html#option-class-tagging if some of this is being used to make a decision about the inclusion of options. Thank you, Darren Ankney On Fri, Jan 3, 2025 at 5:13 AM Peter Davies <[email protected]> wrote: > > Hi Jonas, > > Thank you for your interest in Kea. > > > Please create a feature request issue at > https://gitlab.isc.org/isc-projects/kea . > > You can attach any configurations to the gitlab issue. > > > Kind Regards Peter > > ISC Support > > > ________________________________ > From: "[email protected]" <[email protected]> > To: "[email protected]" <[email protected]> > Cc: "Jonas Alfredsson" <[email protected]> > Sent: Friday, 3 January, 2025 11:02:23 > Subject: [Kea-users] Feature request: Control when > "evaluate-additional-classes" is executed > > Hi, > > With Kea 2.7.5 it is now possible to add a "client-classes" limit to the pool > argument like this: > > { > "pool": "172.27.140.2-172.27.140.10", > "client-classes": ["k8s-node", "special-k8s-node"] > }, > { > "pool": "172.27.140.20-172.27.140.30", > "client-classes": ["not-k8s-node"] > } > > This is nice, but I ran into an issue where when we mark these classes with > "only-in-additional-list": true, they are only evaluated after a pool has > been selected, thus these pools will never be chosen unless we remove the > late evaluation from the class definitions (which would mean that all > requests are classified, even though it is only relevant for a single > subnet). > > My suggestion/request would be that these "only-in-additional-list" are > evaluated at the level where the "evaluate-additional-classes" is defined. > So if we have the following configuration: > > "subnet4": [{ > "id": 1, > "subnet": "172.27.140.0/26", > "evaluate-additional-classes": [ > "k8s-node", > "special-k8s-node", > "not-k8s-node" > ], > "pools": { ... } > }] > > The classes defined in that list are evaluated when the subnet has been > chosen, > but before the actual pool has been chosen. > > I will attach a complete config file to provide more context to what I am > trying to achieve, and I am looking forward to hear what you think of this. > > Best regards, > Jonas > > > > -- > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > > Kea-users mailing list > [email protected] > https://lists.isc.org/mailman/listinfo/kea-users > -- > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > > Kea-users mailing list > [email protected] > https://lists.isc.org/mailman/listinfo/kea-users -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
