----- 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