[Qemu-devel] converging around a single guest agent

[Eric Gaulin]

On Thu, Nov 17, 2011 at 11:14 AM, Daniel P. Berrange
<berrange at redhat.com> 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.
>
> Regards,
> Daniel
> --

I agree with Daniel,

A good example to get inspired from is the ZABBIX agent. A single C
source tree that can be compiled to many Unix and Windows binaries.

Eric Gaulin
___