You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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:
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:
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.
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.
The text was updated successfully, but these errors were encountered: