On 08/27/10 19:42, Alexander Larsson wrote:
On Fri, 2010-08-27 at 17:28 +0200, Gerd Hoffmann wrote:
Hi,
Having a more fine-grained command line feature selection just causes
complexity and risk that sysadmins get things wrong. I don't see any
gain in it.
Point.
I'll note that this switch i
On Fri, 2010-08-27 at 17:28 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > Having a more fine-grained command line feature selection just causes
> > complexity and risk that sysadmins get things wrong. I don't see any
> > gain in it.
>
> Point.
>
> > I'll note that this switch is really only about migr
Hi,
Having a more fine-grained command line feature selection just causes
complexity and risk that sysadmins get things wrong. I don't see any
gain in it.
Point.
I'll note that this switch is really only about migration compatibility.
Any reason to add this now? We could delay it until
On Fri, 2010-08-27 at 15:08 +0200, Gerd Hoffmann wrote:
> >> As you are talking about "set of features" already ...
> >>
> >> I think we should use a feature bitmask instead of a version number in
> >> the API.
> >
> > How would you use this in qemu though? Say you link to spice 0.10.0,
> > which h
As you are talking about "set of features" already ...
I think we should use a feature bitmask instead of a version number in
the API.
How would you use this in qemu though? Say you link to spice 0.10.0,
which has a set of new features not in 0.8.0. Why would you want to make
a spice instance t
On Fri, 2010-08-27 at 09:16 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > This API allows qemu to limit the set of features that spice uses to
> > those compatible with an older version, in order to do an upgrade like
> > this. Right now it doesn't really do much, since we don't keep compat
> > with 0.4
Hi,
This API allows qemu to limit the set of features that spice uses to
those compatible with an older version, in order to do an upgrade like
this. Right now it doesn't really do much, since we don't keep compat
with 0.4.0 atm (although that may be added later).
As you are talking about "s
On Thu, 2010-08-26 at 09:26 -0400, Alon Levy wrote:
> - al...@redhat.com wrote:
>
> > From: Alexander Larsson
> >
> > When upgrading a cluster of machines you typically do this by
> > upgrading a set of machines at a time, making the new machines run
> > the new software version, but in a fa
- al...@redhat.com wrote:
> From: Alexander Larsson
>
> When upgrading a cluster of machines you typically do this by
> upgrading a set of machines at a time, making the new machines run
> the new software version, but in a fashion compatible with the old
> versions (in terms of e.g. migrat
From: Alexander Larsson
When upgrading a cluster of machines you typically do this by
upgrading a set of machines at a time, making the new machines run
the new software version, but in a fashion compatible with the old
versions (in terms of e.g. migration). Then when all machines are
any new fea
10 matches
Mail list logo
