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

ddm: API should allow tagging / filtering of originated prefixes #432

Open
rmustacc opened this issue Jan 21, 2025 · 1 comment
Open

ddm: API should allow tagging / filtering of originated prefixes #432

rmustacc opened this issue Jan 21, 2025 · 1 comment
Assignees

Comments

@rmustacc
Copy link

While debugging issues with DNS zone expungement, there were a few things that came up to make it a bit easier for sled-agent to use the DDM APIs here. sled-agent really has three different classes of addresses that it loads into advertisements:

  • The sled's bootstrap prefix, which is based on information in the FRU from the factory
  • The sled's underlay prefix, which is based on information around the sled being part of the cluster
  • DNS server prefixes, which come and go based on the cluster's configuration, but sled-agent needs to bring up as part of cold-boot

There are a few things that would be helpful here that we can probably improve upon. At the core, these three classes of addresses have different management and reconciliation properties. There is little reconciliation needed for the first two, but the third involves updates from RPWs and sagas and therefore due to the possibility of failures and crashes does need reconciliation. This leads to a few different things:

  1. We should probably provide a way for someone who is doing a PUT for a prefix to originate to be able to add some kind of tag or top-level category/group assignment. This would allow us to group each of these three as different classes of prefixes. This is not something that should be part of anything that is actually in the routing protocol, mostly a way to improve local management. In turn, sled-agent would be able to query this information, which would make it easier to implement that loop.

  2. We should consider some form of POST request that basically is a here is the new set of addresses that correspond go this tag/category. That perhaps is moving around the deck chairs with respect to who is implementing the reconciler loop, but also means there's less immediate need for then asking for ETags or similar mechanisms to ensure that things aren't being pulled out from under sled-agent due to another actor as it tries to implement that.

@Nieuwejaar
Copy link
Contributor

I've grabbed this for now, but I don't have a good sense of how high priority it is. If it's not critical, it might just wait for Ry to get back.

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

No branches or pull requests

2 participants