Request a freeze exception for Libxl Migration v2 in 4.6

Request a freeze exception for Libxl Migration v2 in 4.6

[Andrew Cooper]

Hello,

I would like to request a freeze exception for libxl migration v2.

v3 of the series was posted this morning, and review seems to indicate
that it is mostly on track.  I hope to have v4 ready to post tomorrow,
and hope to have no further adjustments required.

On the testing side of things, libxc migration v2 and (an earlier
version of) the python conversion script have shipped in XenServer 6.5. 
We are entirely confident of the quality here, have extensive testing in
place.

The libxl side is admittedly far less tested.  All testing is so far
manual on my behalf, but I have specifically tested PV (32 and 64), HVM
(qemu trad and upstream) save, restore, and migrate, including inline
legacy->v2 conversion.

The biggest risk, feature wise, is the subject of Remus streams which I
am unable to test.  An earlier version of the series had some testing
and identified an issue, which has subsequently been fixed.

~Andrew

Re: Request a freeze exception for Libxl Migration v2 in 4.6

[Ian Jackson]

Andrew Cooper writes ("Request a freeze exception for Libxl Migration v2 in 4.6"):
> I would like to request a freeze exception for libxl migration v2.
> 
> v3 of the series was posted this morning, and review seems to indicate
> that it is mostly on track.  I hope to have v4 ready to post tomorrow,
> and hope to have no further adjustments required.

Wei asked me for input and I thought it best to reply by email.

Andrew Cooper's summary of the current state is accurate.

In my opinion, the version posted last week was nearly ready.  The
remaining issues with v3 are minor and I expect them to be resolved
quickly.  The overall quality is high.

> The biggest risk, feature wise, is the subject of Remus streams which I
> am unable to test.  An earlier version of the series had some testing
> and identified an issue, which has subsequently been fixed.

It would IMO be reasonable to treat any further problems discovered as
bugs to fix during the freeze.

Ian.

Re: Request a freeze exception for Libxl Migration v2 in 4.6

[Wei Liu]

On Tue, Jul 14, 2015 at 11:31:10AM +0100, Ian Jackson wrote:
> Andrew Cooper writes ("Request a freeze exception for Libxl Migration v2 in 4.6"):
> > I would like to request a freeze exception for libxl migration v2.
> > 
> > v3 of the series was posted this morning, and review seems to indicate
> > that it is mostly on track.  I hope to have v4 ready to post tomorrow,
> > and hope to have no further adjustments required.
> 
> Wei asked me for input and I thought it best to reply by email.
> 
> Andrew Cooper's summary of the current state is accurate.
> 
> In my opinion, the version posted last week was nearly ready.  The
> remaining issues with v3 are minor and I expect them to be resolved
> quickly.  The overall quality is high.
> 

Thanks.

> > The biggest risk, feature wise, is the subject of Remus streams which I
> > am unable to test.  An earlier version of the series had some testing
> > and identified an issue, which has subsequently been fixed.
> 
> It would IMO be reasonable to treat any further problems discovered as
> bugs to fix during the freeze.
> 

I concur. And I trust that Andrew will fix up issues when they arise.

V4 now has all necessary acks. This feature is not only important in its
own right but also basis for another feature currently being developed.
I'm fine with granting it freeze exception. Do note that this series
needs to be checked in as soon as possible, before next Friday.

Wei.

> Ian.

Re: Request a freeze exception for Libxl Migration v2 in 4.6

[Ian Jackson]

Ian Jackson writes ("Re: Request a freeze exception for Libxl Migration v2 in 4.6"):
> Andrew Cooper writes ("Request a freeze exception for Libxl Migration v2 in 4.6"):
> > I would like to request a freeze exception for libxl migration v2.
> > 
> > v3 of the series was posted this morning, and review seems to indicate
> > that it is mostly on track.  I hope to have v4 ready to post tomorrow,
> > and hope to have no further adjustments required.
> 
> Wei asked me for input and I thought it best to reply by email.

The series is now fully acked and there are only two things stopping
it going in right away:

 * The need for a freeze exception which has not yet been granted.

 * We have a bug report about it breaking Remus.  This is being
   investigated.  My view as maintainer is that this should not be a
   blocker to committing this series, because:

     - This series is itself a prerequisite for Colo work, which
       is being promoted by many of the same people as Remus.

     - I have confidence that this bug will be resolved early during
       the freeze.  In particular I have confidence (based on past
       performance) that the bug-hunt will be thorough, and that the
       submitter of this v2 migration series will quickly take
       responsibility and develop necessary fixes.

  I would like to get a confirmation from a Remus maintainer that they
  are happy with this approach: that is, to commit now, and fix later.

  But after getting that confirmation, if it weren't for the freeze I
  would now be pushing this series to staging.


Arguments in favour of the exception:

 * The series is a prerequisite for other important work (notably
   Colo), and even if that other work misses 4.6, we want to make as
   much progress as possible.

 * This series is cleanup work, rather than new functionality; we hope
   it will improve the release's long-term maintainability and
   quality.

 * The code quality of the initial non-RFC v1 was very high.

 * Without this series we will, for another release, have an
   entirely-unexercised set of `v2 migration' code at the libxc layer.

 * The series is now in good shape and only 3 working days late.

Arguments against:

 * We are switching between implementations of a major piece of
   functionality.


I would recommend granting an exception, subject to two conditions:

 * Confirmation from a Remus maintainer that they would prefer this
   series to go in now, and be fixed later, despite the probable
   existence of a Remus-related bug.

 * That the series should be committed today or tomorrow.

Thanks,
Ian.

Re: Request a freeze exception for Libxl Migration v2 in 4.6

[Ian Jackson]

Wei Liu writes ("Re: Request a freeze exception for Libxl Migration v2 in 4.6"):
> V4 now has all necessary acks. This feature is not only important in its
> own right but also basis for another feature currently being developed.
> I'm fine with granting it freeze exception. Do note that this series
> needs to be checked in as soon as possible, before next Friday.

Ah I see you have reached a conclusion already, good.

When you say `next Friday' when today is Tuesday, conventional English
would read it as meaning Friday a week and a half away, ie the 24th of
July.  Did you mean `this Friday', ie the 17th ?

Ian.

Re: Request a freeze exception for Libxl Migration v2 in 4.6

[Wei Liu]

On Tue, Jul 14, 2015 at 03:13:36PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Request a freeze exception for Libxl Migration v2 in 4.6"):
> > Andrew Cooper writes ("Request a freeze exception for Libxl Migration v2 in 4.6"):
> > > I would like to request a freeze exception for libxl migration v2.
> > > 
> > > v3 of the series was posted this morning, and review seems to indicate
> > > that it is mostly on track.  I hope to have v4 ready to post tomorrow,
> > > and hope to have no further adjustments required.
> > 
> > Wei asked me for input and I thought it best to reply by email.
> 
> The series is now fully acked and there are only two things stopping
> it going in right away:
> 
>  * The need for a freeze exception which has not yet been granted.
> 

It has. I replied to your email earlier.

>  * We have a bug report about it breaking Remus.  This is being
>    investigated.  My view as maintainer is that this should not be a
>    blocker to committing this series, because:
> 
>      - This series is itself a prerequisite for Colo work, which
>        is being promoted by many of the same people as Remus.
> 
>      - I have confidence that this bug will be resolved early during
>        the freeze.  In particular I have confidence (based on past
>        performance) that the bug-hunt will be thorough, and that the
>        submitter of this v2 migration series will quickly take
>        responsibility and develop necessary fixes.
> 
>   I would like to get a confirmation from a Remus maintainer that they
>   are happy with this approach: that is, to commit now, and fix later.
> 
>   But after getting that confirmation, if it weren't for the freeze I
>   would now be pushing this series to staging.
> 
> 
> Arguments in favour of the exception:
> 
>  * The series is a prerequisite for other important work (notably
>    Colo), and even if that other work misses 4.6, we want to make as
>    much progress as possible.
> 
>  * This series is cleanup work, rather than new functionality; we hope
>    it will improve the release's long-term maintainability and
>    quality.
> 
>  * The code quality of the initial non-RFC v1 was very high.
> 
>  * Without this series we will, for another release, have an
>    entirely-unexercised set of `v2 migration' code at the libxc layer.
> 
>  * The series is now in good shape and only 3 working days late.
> 
> Arguments against:
> 
>  * We are switching between implementations of a major piece of
>    functionality.
> 
> 
> I would recommend granting an exception, subject to two conditions:
> 
>  * Confirmation from a Remus maintainer that they would prefer this
>    series to go in now, and be fixed later, despite the probable
>    existence of a Remus-related bug.
> 
>  * That the series should be committed today or tomorrow.
> 

I would say as soon as possible. Don't want to rush everything in within
next week.

Wei.

> Thanks,
> Ian.

Re: Request a freeze exception for Libxl Migration v2 in 4.6

[Wei Liu]

On Tue, Jul 14, 2015 at 03:16:09PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: Request a freeze exception for Libxl Migration v2 in 4.6"):
> > V4 now has all necessary acks. This feature is not only important in its
> > own right but also basis for another feature currently being developed.
> > I'm fine with granting it freeze exception. Do note that this series
> > needs to be checked in as soon as possible, before next Friday.
> 
> Ah I see you have reached a conclusion already, good.
> 
> When you say `next Friday' when today is Tuesday, conventional English
> would read it as meaning Friday a week and a half away, ie the 24th of
> July.  Did you mean `this Friday', ie the 17th ?
> 

I did mean July 24. That's the cut off day for applying patches with
freeze exception.

Wei.

> Ian.

Re: Request a freeze exception for Libxl Migration v2 in 4.6

[Yang Hongyang]

Hi Ian,

On 07/14/2015 10:13 PM, Ian Jackson wrote:
> Ian Jackson writes ("Re: Request a freeze exception for Libxl Migration v2 in 4.6"):
>> Andrew Cooper writes ("Request a freeze exception for Libxl Migration v2 in 4.6"):
>>> I would like to request a freeze exception for libxl migration v2.
>>>
>>> v3 of the series was posted this morning, and review seems to indicate
>>> that it is mostly on track.  I hope to have v4 ready to post tomorrow,
>>> and hope to have no further adjustments required.
>>
>> Wei asked me for input and I thought it best to reply by email.
>
> The series is now fully acked and there are only two things stopping
> it going in right away:
>
>   * The need for a freeze exception which has not yet been granted.
>
>   * We have a bug report about it breaking Remus.  This is being
>     investigated.  My view as maintainer is that this should not be a
>     blocker to committing this series, because:
>
>       - This series is itself a prerequisite for Colo work, which
>         is being promoted by many of the same people as Remus.
>
>       - I have confidence that this bug will be resolved early during
>         the freeze.  In particular I have confidence (based on past
>         performance) that the bug-hunt will be thorough, and that the
>         submitter of this v2 migration series will quickly take
>         responsibility and develop necessary fixes.
>
>    I would like to get a confirmation from a Remus maintainer that they
>    are happy with this approach: that is, to commit now, and fix later.

I'm quite happy with this approach, and am definitely going to fix the
bug asap.

>
>    But after getting that confirmation, if it weren't for the freeze I
>    would now be pushing this series to staging.
>
>
> Arguments in favour of the exception:
>
>   * The series is a prerequisite for other important work (notably
>     Colo), and even if that other work misses 4.6, we want to make as
>     much progress as possible.
>
>   * This series is cleanup work, rather than new functionality; we hope
>     it will improve the release's long-term maintainability and
>     quality.
>
>   * The code quality of the initial non-RFC v1 was very high.
>
>   * Without this series we will, for another release, have an
>     entirely-unexercised set of `v2 migration' code at the libxc layer.
>
>   * The series is now in good shape and only 3 working days late.
>
> Arguments against:
>
>   * We are switching between implementations of a major piece of
>     functionality.
>
>
> I would recommend granting an exception, subject to two conditions:
>
>   * Confirmation from a Remus maintainer that they would prefer this
>     series to go in now, and be fixed later, despite the probable
>     existence of a Remus-related bug.
>
>   * That the series should be committed today or tomorrow.
>
> Thanks,
> Ian.
> .
>

-- 
Thanks,
Yang.

Re: Request a freeze exception for Libxl Migration v2 in 4.6

[Yang Hongyang]

On 07/14/2015 10:13 PM, Ian Jackson wrote:
> Ian Jackson writes ("Re: Request a freeze exception for Libxl Migration v2 in 4.6"):
>> Andrew Cooper writes ("Request a freeze exception for Libxl Migration v2 in 4.6"):
>>> I would like to request a freeze exception for libxl migration v2.
>>>
>>> v3 of the series was posted this morning, and review seems to indicate
>>> that it is mostly on track.  I hope to have v4 ready to post tomorrow,
>>> and hope to have no further adjustments required.
>>
>> Wei asked me for input and I thought it best to reply by email.
>
> The series is now fully acked and there are only two things stopping
> it going in right away:
>
>   * The need for a freeze exception which has not yet been granted.
>
>   * We have a bug report about it breaking Remus.  This is being
>     investigated.  My view as maintainer is that this should not be a
>     blocker to committing this series, because:
>
>       - This series is itself a prerequisite for Colo work, which
>         is being promoted by many of the same people as Remus.
>
>       - I have confidence that this bug will be resolved early during
>         the freeze.  In particular I have confidence (based on past
>         performance) that the bug-hunt will be thorough, and that the
>         submitter of this v2 migration series will quickly take
>         responsibility and develop necessary fixes.

Agreed, having investigated the bug, I know where it is, it can be fixed
after you push the series, I will propose a patch to fix this.

>
>    I would like to get a confirmation from a Remus maintainer that they
>    are happy with this approach: that is, to commit now, and fix later.
>
>    But after getting that confirmation, if it weren't for the freeze I
>    would now be pushing this series to staging.
>
>
> Arguments in favour of the exception:
>
>   * The series is a prerequisite for other important work (notably
>     Colo), and even if that other work misses 4.6, we want to make as
>     much progress as possible.
>
>   * This series is cleanup work, rather than new functionality; we hope
>     it will improve the release's long-term maintainability and
>     quality.
>
>   * The code quality of the initial non-RFC v1 was very high.
>
>   * Without this series we will, for another release, have an
>     entirely-unexercised set of `v2 migration' code at the libxc layer.
>
>   * The series is now in good shape and only 3 working days late.
>
> Arguments against:
>
>   * We are switching between implementations of a major piece of
>     functionality.
>
>
> I would recommend granting an exception, subject to two conditions:
>
>   * Confirmation from a Remus maintainer that they would prefer this
>     series to go in now, and be fixed later, despite the probable
>     existence of a Remus-related bug.
>
>   * That the series should be committed today or tomorrow.
>
> Thanks,
> Ian.
> .
>

-- 
Thanks,
Yang.