On Thu, Nov 17, 2011 at 11:14 AM, 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.
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.
vdsm-devel mailing list