What one regards as a feature, other regard as misfeatures. If you like virt-manager, then VirtKick isn't really for you. We value a simple UI more than virt-manager, and REST API more than virsh. We don't say your way is wrong. It's just more difficult.
Existing libvirt clients, at least those that we know of, aren't super reliable though. libvirt stucks when there's too much happening on the HV, or denies jobs without even trying (e.g. when a pool has async jobs). A backend that schedules tasks for background execution is needed for that (and we have it), so even now we're not "just" a frontend for libvirt.
The use case is a very simple panel with zero virt knowledge needed to start.
> so even now we're not "just" a frontend for libvirt.
I would certainly prefer that virtkick was 'just a frontend' for libvirt. Then the people who are making use of virtkick can seamlessly rely on the huge amount of existing software that supports libvirt. You can provide a REST API that is translated to the existing libvirt API rather than replacing it.
If you have task-scheduling improvements for libvirt, they should be upstreamed rather than only exist in your software, so everyone can benefit from them.
Existing libvirt clients, at least those that we know of, aren't super reliable though. libvirt stucks when there's too much happening on the HV, or denies jobs without even trying (e.g. when a pool has async jobs). A backend that schedules tasks for background execution is needed for that (and we have it), so even now we're not "just" a frontend for libvirt.
The use case is a very simple panel with zero virt knowledge needed to start.
Thanks for your comment.