Introduce ADR 15 for Admin API #237
Conversation
ghost
requested review from
|
I framed it as an ADR because it seems to me it changes the architecture of the node significantly. |
Fair enough. What would the architectural changes look like exactly? |
| * We can easily extend such an API with websockets to provide notifications (eg. peers connectivity, setup events...) | ||
| * *Why a separate component?* | ||
| * We could imagine extending the existing [APIServer](../../hydra-node/src/Hydra/API/Server.hs) interface with new messages related to this network configuration, however this seems to conflate different responsibilities in a single place: Configuring and managing the Hydra node itself, and configuring, managing, and interacting with the Head itself | ||
| * "Physical" separation of endpoints makes it easier to secure a very sensitive part of the node, namely its administration, e.g by ensuring this can only be accessed through a specific network interface, without relying on application level authnz mechanisms |
There was a problem hiding this comment.
Another Q: The Admin API shall not allow to add/remove peers when a Head is open, how will that be handled?
(I'd like to get this answered as it is a more involved scenario which requires knowledge of the HeadState. IMO it ought to be handled in the HeadLogic, or the Admin API component needs access to the HeadState.. which the architecture change diagram above does not indicate)
There was a problem hiding this comment.
I initially started with more complex interaction in the diagram to address this particular point, but then thought it would be something to refine when actually implementing this. As the name (kind of) implies and the implementation follows, HeadLogic is responsible for managing the lifecycle of a single Head whose behaviour depends on the existence of a Network component. Hence as long as the network is not properly setup there can be no well-behaving HeadLogic hence no interaction with it.
Practically speaking, this means the Admin component (arguably a very bad name so we'll need to find better) would kind of "create" the HeadLogic once it gets a go. It really is handling the setup phase so happens before any Head.
| * This API is an interface over a specific _resource_ controlled by the Hydra node, namely its knowledge of other peers with which new _Head_s can be opened. As such a proper REST interface (_not_ RPC-in-disguise) seems to make sense here, rather than stream/event-based [duplex communication channels](./0003-asynchronous-duplex-api.md) | ||
| * We can easily extend such an API with websockets to provide notifications (eg. peers connectivity, setup events...) | ||
| * *Why a separate component?* | ||
| * We could imagine extending the existing [APIServer](../../hydra-node/src/Hydra/API/Server.hs) interface with new messages related to this network configuration, however this seems to conflate different responsibilities in a single place: Configuring and managing the Hydra node itself, and configuring, managing, and interacting with the Head itself |
There was a problem hiding this comment.
I wouldn't say it conflates these responsibilities, but the API component would merely provide access to the functionality of managing the hydra-node. The same way as the current functionality of the hydra-node (manage a single head and use it when open) is also not provided by the API component right now.
There was a problem hiding this comment.
We are talking about managing 2 different entities, with clear separation of capabilities and state: The Node and its network part on one side, the Head which the Node is hosting on the other side (there can be multiple Heads in a Node, possibly with different parties and peers, if not concurrently atm at least sequentially).
Hence it seems that having a single component (the current APIServer) providing access to these 2 capabilities is a conflation of 2 different concerns.
|
Added as draft as part of 695b437 Referenced by the documentation as a possible evolution of the command-line options and link was broken without. We can continue the discussion on voice chat I believe and settle on this matter. |
No description provided.