chore: add configMaps component to tailnet #11400
Conversation
9704400 to
d9c25c1
Compare
da115a4 to
86113e2
Compare
d9c25c1 to
9af1797
Compare
86113e2 to
8d938f7
Compare
3b7ebdf to
032d52d
Compare
b03a760 to
6f37b9b
Compare
| return out | ||
| } | ||
|
|
||
| func (c *configMaps) setAddresses(ips []netip.Prefix) { |
There was a problem hiding this comment.
Even though these won't be used outside of tailnet, I think it would be clearer to export the functions that callers are expected to use. Otherwise they feel a little lost next to all of the internal-only functions.
There was a problem hiding this comment.
Do you think it's worth putting into its own package? Otherwise I don't think the internal/external distinction is meaningful and I'm not sure readers would will pick up on the difference.
Maybe adding some method comments would help make it clear.
There was a problem hiding this comment.
As I was going through, other than the configLoop() routine, I don't know if any internal/external distinction is going to pass the test of time. For example, right now the functions that return the current config are only called from the configLoop(), but there isn't any strong reason we couldn't call them from the Conn later---there are a lot of functions already that query various aspects of config---so long as they obey the locking requirements.
There was a problem hiding this comment.
That makes sense. I was initially a bit confused on what was intended to be called externally. Comments sound helpful 👍
6f37b9b to
0ec3722
Compare
0ec3722 to
d013264
Compare
d013264 to
018e3b8
Compare
Merge activity
|
Work in progress on a subcomponent of the Conn which will handle configuring the wireguard engine on changes. I've implemented setAddresses as the simplest case and added unit tests of the reconfiguration loop.
Besides making the code easier to test and understand, the goal is for this component to handle disconnect and loss updates about peers, and thereby, implement the v2 Tailnet API.
Further PRs will handle peer updates, status updates, and net info updates.
Then, after the subcomponent is implemented and tested, I will refactor Conn to use it instead of the current monolithic architecture.