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 _______________________________________________ vdsm-devel mailing list firstname.lastname@example.org https://fedorahosted.org/mailman/listinfo/vdsm-devel