On 02/07/2012 09:05 AM, Daniel P. Berrange wrote:
> On Mon, Feb 06, 2012 at 06:52:40PM -0500, Cole Robinson wrote:
>> Hi all,
>>
>> I'd like to remove virtinst as a public API, and make it private code shared
>> by virt-manager and virt-{install,clone,image,convert}.
>>
>> virtinst really never should have been a library, it's historically not well
>> thought out or stable, and really using the command line tools is a much more
>> stable API. Longer term there are C libraries built around libvirt and gobject
>> that are being developed which will fill the role of virtinst in a much more
>> API friendly way. Privatizing this code will also allow us to clean house a
>> lot, including hopefully merging virt-manager and virtinst into the same repo,
>> so we don't have the annoying lockstep upgrade problem for developers.
>>
>> There aren't many API users that I know of: aside from virt-*, there are
>> pieces of cobbler and koji, which I'm in the process of patching.
>>
>> Ideally I'd like to cut a release at the end of the month which drops virtinst
>> as a public API and possibly merges the two repos.
>>
>> Any comments or thoughts?
>
> If we are to ever try to convert virt-manager / virt-instal over to
> use libosinfo & libvirt-glib, then I think that declaring the existing
> virtinst API as private is a mandatory step. The conversion will
> require non-trivial changes to the existing code and it is just not
> worth the pain of trying to retain compatibility for external apps.
>
Agreed. Though it'll probably be a while before all of virtinst parsing code
is gone, certainly near term I'd like to start integrating libosinfo and
libvirt-glib.
> Any other apps currently using virtinst's internal API should also
> really be planning to switch to libvirt-glib + libosinfo themselves.
>
Truth is the other apps I mentioned (cobbler and koji) using virtinst are
really just duplicating virt-install and virt-clone respectively. So I've
prepared patches to have them call out to the cli tools. They probably won't
ever have much need for the libvirt-glib family, they are just deploying
guests (which using virtinst API for is pretty painful anyways).
The more interesting virtinst benefit of parsing the XML into an easily
editable readable/editable object is kinda new in the history of virtinst, and
I've deliberately made a point of not advertising it so people wouldn't start
using it as a public API. If we people were using it, ripping that out at this
point would be exponentially harder.
- Cole
