Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core: Change getListenerFromPlugin signature #6651

Merged
merged 24 commits into from
Dec 12, 2024

Conversation

MayCXC
Copy link
Contributor

@MayCXC MayCXC commented Oct 21, 2024

I wanted #6622 to go into the next release 100%, because it cleaned up an unnecessary func added in #6573 . this PR separates the address, port range, and port offset in getListenerFromPlugin . this lets plugins create listeners in the caddy pool if they want, and map port ranges to their own groups of listen addresses (e.g systemd socket units) in a direct way.

@mohammed90
Copy link
Member

this PR renames NetworkAddress JoinHostPort to JoinAt

Can you share more on the reasoning for the rename? It's one of the oldest methods in Caddy codebase, and I worry the rename will break plugins relying on it.

@MayCXC
Copy link
Contributor Author

MayCXC commented Oct 21, 2024

this PR renames NetworkAddress JoinHostPort to JoinAt

Can you share more on the reasoning for the rename? It's one of the oldest methods in Caddy codebase, and I worry the rename will break plugins relying on it.

the rename is just to make its syntax distinct from net.JoinHostPort, because it has no host or port parameters. I did intend for the change to affect plugins, because when the host port and offset get passed together to getListenerFromPlugin, it is confusing which should be passed to net.JoinHostPort v.s. na.JoinHostPort without the rename.

@mholt
Copy link
Member

mholt commented Oct 21, 2024

the rename is just to make its syntax distinct from net.JoinHostPort, because it has no host or port parameters.

True, but arguably, that's even more reason to keep the HostPort part in the name, since it's not obvious that's what it's joining otherwise.

I think we should leave this one, since it's been around a while and may be used in a lot of places.

@MayCXC
Copy link
Contributor Author

MayCXC commented Oct 21, 2024

& to address your concern, currently any plugins passing a port offset to na.JoinHostPort are making one up, because before this PR they did not know the actual offset of the port they were passed, or the full port range. so that break is intentional / overlapping with the getListenerFromPlugin change.

@MayCXC
Copy link
Contributor Author

MayCXC commented Oct 21, 2024

the rename is just to make its syntax distinct from net.JoinHostPort, because it has no host or port parameters.

True, but arguably, that's even more reason to keep the HostPort part in the name, since it's not obvious that's what it's joining otherwise.

I think we should leave this one, since it's been around a while and may be used in a lot of places.

I'm with it if we can figure out where the offset is coming from. if plugins actually use it, it probably needs to be changed to the new offset parameter in this branch.

@mohammed90
Copy link
Member

mohammed90 commented Oct 21, 2024

I'm with it if we can figure out where the offset is coming from

The NetworkAddress is an address family and IP address and a port range, where the offset is 0 at the first port in the range, and it extends to NetworkAddress#PortRangeSize. Typical usage is to loop for PortRangeSize iterations and do JoinHostPort at the offset of the index of the iteration.

I admit, it's my fault for not making the method return an error if the offset join result goes beyond the defined range.

@MayCXC
Copy link
Contributor Author

MayCXC commented Oct 21, 2024

I'm with it if we can figure out where the offset is coming from

The NetworkAddress is an IP address and a port range, where the offset is 0 at the first port in the range, and it extends to NetworkAddress#PortRangeSize. Typical usage is to loop for PortRangeSize iterations and do JoinHostPort at the offset of the index of the iteration.

I admit, it's my fault for not making the method return an error if the offset join result goes beyond the defined range.

I think I get it, and that port range would come from config / a custom module? I only considered plugins using RegisterNetwork, so if plugins are reading port ranges from somewhere else I'll revert.

@mohammed90
Copy link
Member

I think I get it, and that port range would come from config / a custom module?

It comes from user configuration. It's the value set with bind in the Caddyfile and apps.http.servers.[index/name].listen in the JSON structure.

@francislavoie francislavoie changed the title core: rename NetworkAddress JoinHostPort to JoinAt and change getListenerFromPlugin signature core: Change getListenerFromPlugin signature Oct 21, 2024
@MayCXC
Copy link
Contributor Author

MayCXC commented Oct 21, 2024

ok, RegisterNetwork plugins will be fine with the current func name. next I will go back in time and propose JoinHostPortAt

@MayCXC
Copy link
Contributor Author

MayCXC commented Oct 23, 2024

preemptive caddy-tailscale update: MayCXC/caddy-tailscale@afda8ef

Copy link
Member

@mholt mholt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, let's try this!

@mholt mholt merged commit e76405d into caddyserver:master Dec 12, 2024
33 checks passed
@mholt mholt added this to the v2.9.0-beta.4 milestone Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants