Daniel P. Berrange wrote:
> On Tue, Feb 20, 2007 at 02:55:33PM -0500, Chris wrote:
>> A goal during development of group operations was to match support for
>> common domain operations: create, shutdown, destroy, reboot, pause,
>> unpause, save, restore, and migrate. Their group-specific counterparts
>> do what you would expect, but operate on a group of domains instead of
>> on a single domain.
>
> What is the error handling policy ? eg, if 'save' fails will it just
> skip over that domain and save the rest, or will it abort and restart
> the ones it had saved upto that point, or just abort ? Likewise for
> the other group operations
During save, any errors should throw an exception, which would halt the
grp-save -- quite possibly before all members are saved. What happens
to the domain that failed the operation greatly depends on the error.
The failure may result in a domain that is left unscathed or defunct in
exactly the same way a failed operation on a non-grouped domain would.
The domains that were operated on successfully are not acted on in the
event of a failure in separate domain operation. This was a design
choice. Exceptions could instead be caught (and ignored), but I suspect
no matter what I did there would be someone who wants the opposite
behavior. After an error the user can fall back to using non-group
commands (those all should still work on grouped domains) to either
restore the saved domains or whatever is appropriate for the situation.
Perhaps a configuration option for each operation could be added that
would allow the user to specify behavior in the event of a failure.
>> 2. Operation ordering: it is advantageous to guarantee the order of
>> group operations. A practical example is to ensure that the group's
>> database server is always running before and after the group's web server.
>
> This somewhat ties into my question on error handling above, but also
> raises the question of how do you know whether the DB server has completed
> booting far enough to be able to start the web server. The latter seems a
> pretty much impossible question to answer reliably unless you've got
> some notification from the app inside the guest to say it is ready to
> serve.
I have spent just enough time thinking about that problem to realize it
was a big enough challenge to spin off into a separate project. A first
step would be to provide the mechanism to impose order on basic domain
operations: create, shutdown, migrate, etc. E.g., a mechanism to
provide a guarantee that domA is paused before domB. From there
ordering could be extended with an app in the guest to provide
application specific readiness information. I'm not saying this is the
way to go, but rather it's an important problem that needs some
discussion. Thanks for bringing it up. :)
The intent of this patchset is not to solve all domain grouping
problems. Rather, it is a starting point designed to provide a base set
of functionality for domain groups. Inclusion in the mainstream would
make life a lot easier and allow me time to work on improvements (like
the good ones you've suggested).
Cheers,
Chris
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home