On Tue, May 25, 2010 at 05:35:53PM +0200, Juan Quintela wrote:
> Anthony Liguori <anth...@codemonkey.ws> wrote:
>
> >> +Example:
> >> +
> >> +{ "event": "MIGRATION_FAILED",
> >> + "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
> >> +
> >> +MIGRATION_STARTED
> >> +-----------------
> >> +
> >> +Emitted when migration starts (both in source and target).
> >>
> >
> > I think this makes more sense as a MIGRATION_CONNECTED event. It
> > probably should carry peer information too.
>
> What kind of peer information?
>
> We have tcp/fd/exec/unix migrations. calling it CONNECTED vs STARTED, I
> don't care. But adding information? Notice that the management
> application knows what it did, I can put the:
>
> "exec: gzip -d < /tmp/foo"
>
> string, but not much more that I can put here.
This is why I think network client CONNECT/DISCONNECT events should be
separate from MIGRATION START/END events. They happen to occur at roughly
the same time if using a TCP / UNIX socket based migration transport,
but CONNECT/DISCONNECT + peer info is meaningless for exec or fd based
migration.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
