Re: [Xen-devel] [PATCH v6 COLO 07/15] implement the cmdline for COLO

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-06-25 at 12:06 +0800, Yang Hongyang wrote:
> 
> On 06/16/2015 07:19 PM, Ian Campbell wrote:
> > On Mon, 2015-06-08 at 11:45 +0800, Yang Hongyang wrote:
> >> From: Wen Congyang <wency@xxxxxxxxxxxxxx>
> >>
> >> Add a new option -c to the command 'xl remus'. If you want
> >> to use COLO HA instead of Remus HA, please use -c option.
> >>
> >> Update man pages to reflect the addition of a new option to
> >> 'xl remus' command.
> >>
> >> Also add a new option -c to the internal command 'xl migrate-receive'.
> >
> > I asked about whether COLO was an extension or a peer to Remus in an
> > earlier patch. the answer may have an impact here too.
> 
> We implemented COLO based on Remus, so we assume it is an extension to Remus.

It's not so much a question of implementation (since any two unrelated
features might share some code, or be inspired by one another) but of
how the features relate logically from the users point of view, is COLO
an extension to Remus or is it an independent feature?

i.e. would a user expect the interface to be:
        xl remus <...> # run remus on a domain
        xl colo <...> # run colo on a domain
or
        xl remus <...> # run remus on a domain
        xl remus -c <...> # run remus with colo extensions on a domain

From this end it seems that although colo builds upon the Remus code and
concepts in many ways to the end user it is actually a logically
separate feature which fills a similar niche to Remus. 

It might be that I've not fully appreciated how the two relate and colo
really is "just" an extension to Remus, I'm not sure.

A similar argument applies further down the stack at the libxl API layer
too (my comment on patch #3).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel