Change Details

As explained in https://vyos.dev/T5305 configure endpoints (/configure, /config-file) are handled by functions //not// defined as async due to blocking. However, certain functions in the C library libvyosconfig need to explicitly call thread_registration when called from outside the main thread. Commonly used functions handle this implicitly, however, the critical function `read_cache` to generate a ConfigTree instance from the internal yojson representation requires this to be explicit if called from http-api in a non-async function. The capability to set `thread_registration` has been present in the ocaml-ctypes library since 0.8.0 for the Foreign function interface, but is not available for the inverted cstubs module that we require (it appears to be easy to add and submit upstream, should we consider it necessary). The immediate cause, however, can be addressed by taking a finer-grained approach to the sync/async nature of http-api configure functions: as only a single call in each configure function is blocking, that call can be run in a a threadpool within a configure function defined as async. As we already assign those configure operations that change the state of the http-api itself to FastAPI background_tasks, running the general commit operation in a threadpool is consistent with the current design, without requiring any major changes.

Note that this only affects vyconf development, and is not evident in the current rolling release. As explained in https://vyos.dev/T5305 configure endpoints (/configure, /config-file) are handled by functions //not// defined as async due to blocking. However, certain functions in the C library libvyosconfig need to explicitly call thread_registration when called from outside the main thread. Commonly used functions handle this implicitly, however, the critical function `read_cache` to generate a ConfigTree instance from the internal yojson representation requires this to be explicit if called from http-api in a non-async function. The capability to set `thread_registration` has been present in the ocaml-ctypes library since 0.8.0 for the Foreign function interface, but is not available for the inverted cstubs module that we require (it appears to be easy to add and submit upstream, should we consider it necessary). The immediate cause, however, can be addressed by taking a finer-grained approach to the sync/async nature of http-api configure functions: as only a single call in each configure function is blocking, that call can be run in a a threadpool within a configure function defined as async. As we already assign those configure operations that change the state of the http-api itself to FastAPI background_tasks, running the general commit operation in a threadpool is consistent with the current design, without requiring any major changes.

Note that this only affects vyconf development, and is not evident in the current rolling release. As explained in https://vyos.dev/T5305 configure endpoints (/configure, /config-file) are handled by functions //not// defined as async due to blocking. However, certain functions in the C library libvyosconfig need to explicitly call thread_registration when called from outside the main thread. Commonly used functions handle this implicitly, however, the critical function `read_cache` to generate a ConfigTree instance from the internal yojson representation requires this to be explicit if called from http-api in a non-async function. The capability to set `thread_registration` has been present in the ocaml-ctypes library since 0.8.0 for the Foreign function interface, but is not available for the inverted cstubs module that we require (it appears to be easy to add and submit upstream, should we consider it necessary). The immediate cause, however, can be addressed by taking a finer-grained approach to the sync/async nature of http-api configure functions: as only a single call in each configure function is blocking, that call can be run in a a threadpool within a configure function defined as async. As we already assign those configure operations that change the state of the http-api itself to FastAPI background_tasks, running the general commit operation in a threadpool is consistent with the current design, without requiring any major changes.