It would be good to use krill-sync as a library in Krill's publication server. There is currently some code duplication going on, and krill-sync has a much better implementation of best practices regarding RRDP and (more so) rsync file handling. See: https://datatracker.ietf.org/doc/draft-timbru-sidrops-publication-server-bcp/
Furthermore, it would allow for better end-to-end tests in Krill that leverage krill-sync validation. E.g. we can then make a test that sets up ROAs, does a key rollover, or whatever, and verify that the expected ROA VRPs are reported as valid.
It may be an idea then that Krill itself no longer serves the /rrdp path. The Krill publication server could just keep its current state in memory (it already does) and push this to krill-sync as a lib, rather than krill-sync fetching where Krill published. This could make the code quite a bit cleaner in terms of seperation of concerns.
It would be good to use krill-sync as a library in Krill's publication server. There is currently some code duplication going on, and
krill-synchas a much better implementation of best practices regarding RRDP and (more so) rsync file handling. See: https://datatracker.ietf.org/doc/draft-timbru-sidrops-publication-server-bcp/Furthermore, it would allow for better end-to-end tests in Krill that leverage
krill-syncvalidation. E.g. we can then make a test that sets up ROAs, does a key rollover, or whatever, and verify that the expected ROA VRPs are reported as valid.It may be an idea then that Krill itself no longer serves the
/rrdppath. The Krill publication server could just keep its current state in memory (it already does) and push this to krill-sync as a lib, rather than krill-sync fetching where Krill published. This could make the code quite a bit cleaner in terms of seperation of concerns.