Currently, we do not use async functions for kvx. This also still needs some work in kvx itself.
Under the hood, postgres is accessed using async, but as it's currently hidden behind a sync interface, it uses its own runtime for this. This leads to issues if we call this from async code.
This means that for the moment we cannot postgres as a kvx instance.
The async kvx code itself is not overly complicated, but using it in Krill presents some challenges. Essentially we need to update AggregateStore and WalStore to use async functions for manipulating entities: creating, getting, sending commands.
Unfortunately, this means that the command processing by Aggregates and WalSupport types also needs to become async. This is mainly because various entities (like CAs) need access to the signer. But the signer is in fact a complex beast that supports multiple singer implementations - the correct implementation is looked up at runtime but for this we need the latest signer instance, which means we need async access to the storage layer.
Furthermore, we implemented pkri::crypto::Signer on the SignerRouter which is used for this routing logic. And that trait is sync. So either we need an async_trait signer in rpki, or we need to work around this in Krill - i.e. we look up the correct signers etc async, and then call the actual signing code in rpki-rs once we have it. The latter is probably easier as we already provide high-level functions in Krill (e.g. sign ROA, ASPA etc).
See PR #1152. The relevant kvx code was imported into Krill and supports async in that PR. There is no database implementation ported, but that can be added in future.
Update Krill to use async
kvx
(see https://github.com/NLnetLabs/kvx/pull/15)Currently, we do not use async functions for
kvx
. This also still needs some work inkvx
itself.Under the hood, postgres is accessed using async, but as it's currently hidden behind a sync interface, it uses its own runtime for this. This leads to issues if we call this from async code.
This means that for the moment we cannot postgres as a
kvx
instance.The async kvx code itself is not overly complicated, but using it in Krill presents some challenges. Essentially we need to update AggregateStore and WalStore to use async functions for manipulating entities: creating, getting, sending commands.
Unfortunately, this means that the command processing by Aggregates and WalSupport types also needs to become async. This is mainly because various entities (like CAs) need access to the signer. But the signer is in fact a complex beast that supports multiple singer implementations - the correct implementation is looked up at runtime but for this we need the latest signer instance, which means we need async access to the storage layer.
Furthermore, we implemented
pkri::crypto::Signer
on theSignerRouter
which is used for this routing logic. And that trait is sync. So either we need an async_trait signer inrpki
, or we need to work around this in Krill - i.e. we look up the correct signers etc async, and then call the actual signing code inrpki-rs
once we have it. The latter is probably easier as we already provide high-level functions in Krill (e.g. sign ROA, ASPA etc).