On Mon, Feb 02, 2015 at 01:21:31PM -0500, Andrew Laski wrote:
>
> On 02/02/2015 11:26 AM, Daniel P. Berrange wrote:
> >On Mon, Feb 02, 2015 at 11:19:45AM -0500, Andrew Laski wrote:
> >>On 02/02/2015 05:58 AM, Daniel P. Berrange wrote:
> >>>On Sun, Feb 01, 2015 at 11:20:08AM -0800, Noel Burton-Krah
On 02/02/2015 11:26 AM, Daniel P. Berrange wrote:
On Mon, Feb 02, 2015 at 11:19:45AM -0500, Andrew Laski wrote:
On 02/02/2015 05:58 AM, Daniel P. Berrange wrote:
On Sun, Feb 01, 2015 at 11:20:08AM -0800, Noel Burton-Krahn wrote:
Thanks for bringing this up, Daniel. I don't think it makes sen
On Mon, Feb 02, 2015 at 11:19:45AM -0500, Andrew Laski wrote:
>
> On 02/02/2015 05:58 AM, Daniel P. Berrange wrote:
> >On Sun, Feb 01, 2015 at 11:20:08AM -0800, Noel Burton-Krahn wrote:
> >>Thanks for bringing this up, Daniel. I don't think it makes sense to have
> >>a timeout on live migration,
On 02/02/2015 05:58 AM, Daniel P. Berrange wrote:
On Sun, Feb 01, 2015 at 11:20:08AM -0800, Noel Burton-Krahn wrote:
Thanks for bringing this up, Daniel. I don't think it makes sense to have
a timeout on live migration, but operators should be able to cancel it,
just like any other unbounded l
- Original Message -
> From: "Daniel P. Berrange"
> To: "Robert Collins"
> Cc: "OpenStack Development Mailing List (not for usage questions)"
> ,
> openstack-operat...@lists.openstack.org
> Sent: Monday, 2 February, 2015 5:56:56 AM
&g
On Sun, Feb 01, 2015 at 11:20:08AM -0800, Noel Burton-Krahn wrote:
> Thanks for bringing this up, Daniel. I don't think it makes sense to have
> a timeout on live migration, but operators should be able to cancel it,
> just like any other unbounded long-running process. For example, there's
> no
On Mon, Feb 02, 2015 at 08:24:20AM +1300, Robert Collins wrote:
> On 31 January 2015 at 05:47, Daniel P. Berrange wrote:
> > In working on a recent Nova migration bug
> >
> > https://bugs.launchpad.net/nova/+bug/1414065
> >
> > I had cause to refactor the way the nova libvirt driver monitors liv
015 11:47:16 AM
> > Subject: [openstack-dev] [nova][libvirt] RFC: ensuring live migration ends
> >
> > In working on a recent Nova migration bug
> >
> > https://bugs.launchpad.net/nova/+bug/1414065
> >
> > I had cause to refactor the way the nova libv
On 31 January 2015 at 05:47, Daniel P. Berrange wrote:
> In working on a recent Nova migration bug
>
> https://bugs.launchpad.net/nova/+bug/1414065
>
> I had cause to refactor the way the nova libvirt driver monitors live
> migration completion/failure/progress. This refactor has opened the
> do
Thanks for bringing this up, Daniel. I don't think it makes sense to have
a timeout on live migration, but operators should be able to cancel it,
just like any other unbounded long-running process. For example, there's
no timeout on file transfers, but they need an interface report progress
and t
- Original Message -
> From: "Daniel P. Berrange"
> To: openstack-dev@lists.openstack.org, openstack-operat...@lists.openstack.org
> Sent: Friday, 30 January, 2015 11:47:16 AM
> Subject: [openstack-dev] [nova][libvirt] RFC: ensuring live migration ends
>
>
In working on a recent Nova migration bug
https://bugs.launchpad.net/nova/+bug/1414065
I had cause to refactor the way the nova libvirt driver monitors live
migration completion/failure/progress. This refactor has opened the
door for doing more intelligent active management of the live migratio
12 matches
Mail list logo
