[Qemu-devel] converging around a single guest agent

[Daniel P. Berrange]

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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|