Direct Connect to Socket

[psuet]

Daemon/Area

All Daemons

Feature/Enhancement you are proposing

While the connection via REST-API is quite easy, this always requires the provisioning of a Kea CTRL Agent per Server.

I have implemented an extension to this project that provides an alternative Kea Object which uses Socket Paths instead of URLs. Otherwise its 100% compatible with the existing Kea Class API

KeaSocket:
    """Basic wrapper around requests module for interacting with the
    Kea Management API for the various daemons supported.

    Args:
        socket_path_dhcp4:      Socket Path for DHCP4 server (optional)
        socket_path_dhcp6:      Socket Path for DHCP6 server (optional)
        socket_path_ddns:       Socket Path for DDNS server (optional)
    """

This implementation is currently not ready for upstreaming, but I would like to upstream it, to contribute back.

Is this feature generally in-scope of the library? Are there any implementation details one would appreciate in the pull request?

Reason for Feature/Enhancement

In certain scenarios, it may be disadvantageous to have to deploy a Kea CTRL Agent and use HTTP compared to directly using the sockets provided by the corresponding daemon and used by the control agent.

This may be

• more secure
• less resource intensive
• less management
• architecturally advantageous

[BSpendlove]

Hey! I'll have to look into this more to get more familiar as I've only used the http api myself, I can't see why I would be against this feature.

The use case would be if someone wants python support to interact with Kea via the sockets locally on the same instance right? I can't imagine this being any less manageable than running the control agent as you'll have to install pykeadhcp on ever server and write scripts on each server? I think in my head the best use case I can imagine is a script that sits locally on a lot of servers which sync dhcp pools/subnets/reservations from an IPAM solution?

Do you know if the returned data is exactly the same format as how the CA returns it? If so then that's ideal because there won't be more pydantic models to maintain 😁

As long as there are pytest scripts for the CI tests before a release and you follow the coding style in the contributing doc (which I'm still working on as it's only been me so far developing this), then I'd be open to this type of feature added!

[BSpendlove]

I've just read a bit about it actually just now as it's literally the same as the control agent, seems like it just forwards on the json to the socket directly, so I don't think the models would need to change at all / can use the same models built already...

[BSpendlove]

No further work has been done on this, we can reshape the project if there is more demand but there is no demand right now so closing issue!