On 08/10/2011 07:23 PM, Anthony Liguori wrote:
Right now we have capabilties in the form of -help output.
If -help says
-no-xzbrle disable xzbrle support
(or -migration-compression xzbrle=off, or something) that's sufficient
for management tools.
This is static, not dynamic. You may attempt to migrate to another
host that supports it and then migrate to a second host that doesn't
support it after the first migration fails.
This may be acceptable, wait until the entire migration cluster is
xzbrle capable before enabling it. If not, add a monitor command.
We shouldn't block this feature just because some monitor facility is
not yet implemented.
We shouldn't make *any* changes to the migration protocol before we
have a feature negotiation capability. I only want to do a hard break
of the protocol once.
Didn't we agree that management tool mediated feature negotiation (that
is, outside the migration protocol itself) is acceptable?
--
error compiling committee.c: too many arguments to function
