[Qemu-devel] converging around a single guest agent

[Barak Azulay]

On 11/17/2011 06:14 PM, Daniel P. Berrange wrote:
> On Thu, Nov 17, 2011 at 09:58:33AM -0600, Adam Litke wrote:
>> On Thu, Nov 17, 2011 at 03:46:37AM -0500, Ayal Baron wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> I have been following this thread pretty closely and the one sentence
>>>> summary of the current argument is: ovirt-guest-agent is already featureful
>>>> and tested, so let's drop qemu-ga and have everyone adopt ovirt-guest-agent.
>>>
>>> What we're suggesting is let's drop *one* of the two agents (obviously it
>>> would be easier for us to drop qemu-ga, but we'd rather reach consensus and
>>> unite behind one agent regardless of which agent it is).
>>>
>>>>   Unfortunately, this track strays completely away from the stated goal of
>>>>   convergence.  I have at least two examples of why the greater KVM community
>>>>   can never adopt ovirt-guest-agent as-is.  To address this, I would like to
>>>>   counter with an example on how qemu-ga can enable the deployment of
>>>>   ovirt-guest-agent features and satisfy the needs of the whole community at
>>>>   the same time.
>>>>
>>>> 1) Scope:  The ovirt-guest-agent contains functionality that is incredibly
>>>> useful within the context of oVirt.  Single Sign-on is very handy but KVM
>>>> users outside the scope of oVirt will not want this extra complexity in
>>>> their agent.  For simplicity they will probably just write something small
>>>> that does what they need (and we have failed to provide a ubiquitous KVM
>>>> agent).
>>>
>>> I totally agree, but that could easily be resolved using the plugin
>>> architecture suggested before.
>>>
>>>>
>>>> 1) Deployment complexity: The more complex the guest agent is, the more
>>>> often it will need to be updated (bug/security fixes, distro compatibility,
>>>> new features).  Rolling out guest agent updates does not scale well in large
>>>> environments (especially when the guest and host administrators are not the
>>>> same person).
>>>
>>> Using plugins, you just deploy the ones you need, keeping the attack surface /
>>> #bugs / need to update lower
>>
>> In order for any KVM guest agent to become ubiquitous, I think the code _must_ live
>> in the qemu repository.  This includes the base infrastructure and a core set of
>> plugins to provide the current set of qemu-ga APIs.  This way, both endpoints
>> (host/guest) can evolve together.  How easy would it be to extract this basic
>> infrastructure from the ovirt-guest-agent?  Is the qemu project opposed to a
>> Python agent?
>
> IMHO Python would be a really bad choice for the agent. An agent wants to be
> maximally portable to any guest OS, regardless of its vintage. The changes
> between each python release, even within the 2.x stream, let alone between
> 2.x and 3.x would cause us endless compatibility problems upon deployment.
> And while python is common on Linux, we don't really want to get into the
> business of installing the python runtime on Windows or other OS, simply to
> run an agent.


And still the ovirt-guest-agent:

- is written in python
- Supports many guest OSs (f15, f16, RHEL6.X RHEL5.X, winXP, W7 (32&64), 
2k3 (32/64) 2k8 (32/64/R2))
- Deployed in binary format on win (py2exe ... no need to install python 
and no compatibility problems)



>
> Regards,
> Daniel