CI test pass for libvirt compatibility

[weltling]

As noted on this libvirt issue page, with the release of 28.0 libvirt will become incompatible due to the API changes. Given this situation is most likely to repeat itself in the future anytime, would it make sense to integrate a CI stage involving some libvirt tests?

Another point for stability also - libvirt would need to be able to support multiple versions of the API. Once an LTS release is out, there should be probably some test to ensure libvirt still supports it, despite some latest Cloud Hypervisor might have modified the API in a non compatible manner.

Perhaps there's more in general about the libvirt fork support, just at least the points above is what seems to be something to care about today.

[rbradford]

The libvirt CI could add a test to check against the main branch. However I would also expect the maintainers/contributors to the libvirt support to read the release notes and react to the deprecations (we give at least 2 cycles warning of the removals.)

I would discourage the libvirt plugin supporting multiple versions of Cloud Hypervisor but that would be a decision for the maintainers of the plugin

[rbradford]

(I moved this issue as I don't think this is a Cloud Hypervisor VMM issue rather one for the libvirt integration)

[weltling]

Thanks for checking this, Robert. Yep, the 2 cycles defined in the release doc is a good notice. In the case of API change there seems to be no obvious connection with libvirt, at least for those not familiar with the libvirt internals. Thus, only could catch it once the corresponding changes have landed in main. But that's still a good time buffer and the fix would seem trivial.

Regarding the CI then - it seems then some github actions would need to be integrated in this repo. Would it be CI actions then?

Thanks

[rbradford]

This repository looks very out-of-date vs upstream. Keeping it in sync automatically would be a prerequisite I guess.

[weltling]

Indeed, the current situation looks quite like a "moment of inertia". The continuous rebase is however a very good point, as the older the fork gets the harder it is to up port. I'm not sure I can commit to the continuous rebase for keeping things up to date ATM. Perhaps we could still keep this issue open, so then at least the idea of catching up with CH main would keep hanging in the air.

Thanks