Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling

Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling

[Lars Kurth]

Hi all,
these are my notes from http://sched.co/AjES
These are a little crude and I may have missed some things or misrepresented

ACTIONS for
* Wei Liu
* Julien Grall
* Lars Kurth
* Ian Jackson

Feel free to correct
Lars

Releases Lessons learned
========================

Process issues in 4.9.0 (checklists, guides, templates)
-------------------------------------------------------

Ian:
* Lots of fiddly bits need to be executed (right now we have a release technician checklist)
* We don't have a comprehensive checklist that is useful for Release Managers
* Started the final steps for 4.9.0 on Tue of the release week
* By this tine we were committed to releasing on Wed (no point of return due to PR)
* Some items were release managers job, but discovered by Release Technician (Ian)
* Release technician checklist is in xen.git

ACTION (Wei, Julien, Lars): Have a how to be release manager file (needs to contain some of the stuff in Release technician checklist)
 * RM file: clear set of criteria on PR. Go/NoGo part
 * See https://lists.xenproject.org/archives/html/xen-devel/2017-07/threads.html#01500 for a starting point

ACTION (Lars/Wei/Julien) to write "standard e-mail templates for common stuff" rather than re-doing these every single time
 
ACTION (Ian): Clean up release technician checklist after we have the how to be release manager file

ACTION (Wei/Julien): Additional stuff to add to the templates/RM guide
* Add hand-over of tasks for Release Manager responsibility to the "how to be release manager" file
* Add clear reminders in particular at the beginning of a release into e-mail templates: such as "put dates X,Y, Z in your calendar"
* Communicate better when tree is open again (add to checklist and templates)

ARM issues in 4.9.0
-------------------

Julien: Unreliable testing on ARM32/64 
- ongoing problems with ARM64 box (hardware issue), other ARM64 box (firmware issue), ARM32 Arndale hardware problem (replace)

On ARM everything is in progress and not much more can be done => no concrete ACTION as those already executed

x86 Heisenbugs in 4.9.0
-----------------------
- x86 migration Heisenbugs have caused us issues this release cycle: not completely understood the issues and hard to debug

Ian: These are most likely software problems, most likely in Xen.
ISSUE: nobody wants to debug Windows Heisenbugs
ISSUE: have nobody to do formal triage - doing back-pressure on developers

ACTION: Ian, Julien
- Manually add ignore list for specific Heisenbugs until we found another solution
- Requires a proposal to the list - Julien to propose


ACTION: Julien to propose 
- OSSTEST to CC people blocked/proposed on test failures instead just the list
- Release manager can say "not releasing now" because of too many bugs
  "until someone fixes these". "no more patches until XYZ" 


Improving the Process
=====================

JIRA
----
Open source projects do NOT need licenses for JIRA: these was raised by OpenXT folks, who use JIRA

ACTION: Lars to follow up with Atlassian - https://www.atlassian.com/software/views/open-source-license-request
ACTION: Lars to follow up with Intel on owner and describe simple process to nominate new people

We then had a brief discussion on whether to use labels or components. OpenXT believe components are easier to manage

ACTION: Julien - Decide on whether to use labels or components for wiki page
ACTION: Julien - Make a proposal on components on list for review (note: Lars could help based on https://lists.xenproject.org/archives/html/xen-devel/2017-07/threads.html#01590)

XSA Testing 
-----------
ACTION: include Lars'es tool into checklist

Arguments on the mailing list on XSAs
-------------------------------------
Delayed RC by two days: security patches produced by the security team - we don't always consult the maintainer

ACTION: committers@ + maintainer of relevant code of Advisory should be on pre-disclosure list 
* Explicitly say in public that security team should be informed pre-disclosure ...
  With appropriate template

Resolved in https://lists.xenproject.org/archives/html/xen-devel/2017-07/threads.html#01590

Release Manager for 4.11
------------------------
Julien stepping down after 4.10 - we should find another volunteer

ACTION: Lars to sound out SUSE (Juergen Gross), Ross Phillipson (Oracle)
Note: Juergen would be happy to do this for one release







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

Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 2407 bytes --]

Update on some actions

> On 18 Jul 2017, at 13:18, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
> 
> 
> ACTION (Wei, Julien, Lars): Have a how to be release manager file (needs to contain some of the stuff in Release technician checklist)
> * RM file: clear set of criteria on PR. Go/NoGo part
> * See https://lists.xenproject.org/archives/html/xen-devel/2017-07/threads.html#01500 for a starting point
> 
> ACTION (Lars/Wei/Julien) to write "standard e-mail templates for common stuff" rather than re-doing these every single time
> 
> ACTION (Ian): Clean up release technician checklist after we have the how to be release manager file
> 
> ACTION (Wei/Julien): Additional stuff to add to the templates/RM guide
> * Add hand-over of tasks for Release Manager responsibility to the "how to be release manager" file
> * Add clear reminders in particular at the beginning of a release into e-mail templates: such as "put dates X,Y, Z in your calendar"
> * Communicate better when tree is open again (add to checklist and templates)

This is covered in 
* http://markmail.org/message/lvig3u2gcqt3nwgs <http://markmail.org/message/lvig3u2gcqt3nwgs> (v2)
* http://markmail.org/message/4as7zfl2tfqhpdyo <http://markmail.org/message/4as7zfl2tfqhpdyo> (v1)

> Improving the Process
> =====================
> 
> JIRA
> ----
> Open source projects do NOT need licenses for JIRA: these was raised by OpenXT folks, who use JIRA
> 
> ACTION: Lars to follow up with Atlassian - https://www.atlassian.com/software/views/open-source-license-request <https://www.atlassian.com/software/views/open-source-license-request>

This is covered and I raised two tickets
#CA-297630 confirmed: Open Source license request by Xen Project
  #CA-297631 confirmed: Purchasing and licensing request (this covers how to migrate the account if approved)

> ACTION: Lars to follow up with Intel on owner and describe simple process to nominate new people

Will follow up, once approved.

> We then had a brief discussion on whether to use labels or components. OpenXT believe components are easier to manage
> 
> ACTION: Julien - Decide on whether to use labels or components for wiki page
> ACTION: Julien - Make a proposal on components on list for review (note: Lars could help based on https://lists.xenproject.org/archives/html/xen-devel/2017-07/threads.html#01590)

No progress yet

Lars

[-- Attachment #1.2: Type: text/html, Size: 4109 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 2155 bytes --]

@Committers, @Julien,

> On 26 Jul 2017, at 13:53, Lars Kurth <lars.kurth.xen@gmail.com> wrote:

>> Improving the Process
>> =====================
>> 
>> JIRA
>> ----
>> Open source projects do NOT need licenses for JIRA: these was raised by OpenXT folks, who use JIRA
>> 
>> ACTION: Lars to follow up with Atlassian - https://www.atlassian.com/software/views/open-source-license-request <https://www.atlassian.com/software/views/open-source-license-request>
> 
> This is covered and I raised two tickets
> #CA-297630 confirmed: Open Source license request by Xen Project
>   #CA-297631 confirmed: Purchasing and licensing request (this covers how to migrate the account if approved)

Hi everyone, our account was converted to an open source account. So in theory, we should not have a number limitation on people signed up. See mail below.
If there are any issues/unexpected changes in behaviour, please let me know

> Begin forwarded message:
> 
> From: Sen Geronimo <advocates@atlassian.com>
> Subject: [SUPPORT] Comment posted to request #CA-297630: Open Source license request by Xen Project
> Date: 26 July 2017 at 16:04:01 BST
> To: <lars.kurth@xenproject.org>
> 
> Hi Lars,
> 
> Thanks for reaching out.
> 
> We are happy to grant you the requested Open Source Cloud subscription. Your Atlassian Cloud Instance (xenproject.atlassian.net <http://xenproject.atlassian.net/>) has been converted to Open Source.
> 
> Please note, third-party Cloud add-ons are not available within the Open Source program. If you wish to include Marketplace <https://marketplace.atlassian.com/> plug-ins, you will be required to provide payment.
> 
> Yo
> 

The next step would be to draft some sort of policy (I am happy to draft it), but want to chat with key committers and Julien to get a sense of
a) how open we want https://xenproject.atlassian.net to be
b) what the process/criteria would be for giving people write access
c) what we expect them to do/not do

There is still the issue of labels vs components for wiki page. Maybe we can roll this into the proposal
@Julien: when would you have time for a chat

Lars

[-- Attachment #1.2: Type: text/html, Size: 5307 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling

[Jan Beulich]

>>> Lars Kurth <lars.kurth.xen@gmail.com> 07/18/17 2:18 PM >>>
>x86 Heisenbugs in 4.9.0
>-----------------------
>- x86 migration Heisenbugs have caused us issues this release cycle: not completely understood the issues and hard to debug
>
>Ian: These are most likely software problems, most likely in Xen.
>ISSUE: nobody wants to debug Windows Heisenbugs

Hmm, I think we believe to have understood what the issue is, it's just that
the change needed is on the tool stack side (gracefully deal with a domain
rebooting while being migrated).

Jan


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

Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling

[Ian Jackson]

Jan Beulich writes ("Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling"):
> [Lars:]
> >Ian: These are most likely software problems, most likely in Xen.
> >ISSUE: nobody wants to debug Windows Heisenbugs
> 
> Hmm, I think we believe to have understood what the issue is, it's just that
> the change needed is on the tool stack side (gracefully deal with a domain
> rebooting while being migrated).

No, the problem is that we don't understand why the domain is
rebooting.  It should not be.

Ian.

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

Windows "heinsenbug" (WAS: Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling)

[Julien Grall]

Hi all,

On 07/27/2017 05:56 PM, Ian Jackson wrote:
> Jan Beulich writes ("Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling"):
>> [Lars:]
>>> Ian: These are most likely software problems, most likely in Xen.
>>> ISSUE: nobody wants to debug Windows Heisenbugs
>>
>> Hmm, I think we believe to have understood what the issue is, it's just that
>> the change needed is on the tool stack side (gracefully deal with a domain
>> rebooting while being migrated).
> 
> No, the problem is that we don't understand why the domain is
> rebooting.  It should not be.

This bug still seem to be around and likely going to impact once again 
the release testing.

As discussed during the summit, I am really thinking to make this 
"heinsenbug" a blocker until somehow finally spend sometimes 
investigating the problem and suggest actions.

Cheers,

-- 
Julien Grall

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

Re: Windows "heinsenbug" (WAS: Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling)

[Paul Durrant]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
> Julien Grall
> Sent: 13 September 2017 10:52
> To: Ian Jackson <Ian.Jackson@citrix.com>; Jan Beuli ch <jbeulich@suse.com>
> Cc: Juergen Gross <jgross@suse.com>; Wei Liu <wei.liu2@citrix.com>;
> ross.philipson@gmail.com; lars.kurth.xen@gmail.com; xen-
> devel@lists.xen.org; committers@xenproject.org
> Subject: [Xen-devel] Windows "heinsenbug" (WAS: Re: Notes Design
> Session: Making Releases Lessons Learned: Improving Our Release Process
> and Tooling)
> 
> Hi all,
> 
> On 07/27/2017 05:56 PM, Ian Jackson wrote:
> > Jan Beulich writes ("Re: Notes Design Session: Making Releases Lessons
> Learned: Improving Our Release Process and Tooling"):
> >> [Lars:]
> >>> Ian: These are most likely software problems, most likely in Xen.
> >>> ISSUE: nobody wants to debug Windows Heisenbugs
> >>
> >> Hmm, I think we believe to have understood what the issue is, it's just
> that
> >> the change needed is on the tool stack side (gracefully deal with a domain
> >> rebooting while being migrated).
> >
> > No, the problem is that we don't understand why the domain is
> > rebooting.  It should not be.
> 
> This bug still seem to be around and likely going to impact once again
> the release testing.
> 
> As discussed during the summit, I am really thinking to make this
> "heinsenbug" a blocker until somehow finally spend sometimes
> investigating the problem and suggest actions.

If testing was done with PV drivers installed then we could get a lot more information into the logs. BSODs vs. clean shutdowns (perhaps due to Windows Update) would then become obvious.

  Paul

> 
> Cheers,
> 
> --
> Julien Grall
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Windows "heinsenbug" (WAS: Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling)

[Julien Grall]

Hi Paul,

On 13/09/17 19:26, Paul Durrant wrote:
>> -----Original Message-----
>> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
>> Julien Grall
>> Sent: 13 September 2017 10:52
>> To: Ian Jackson <Ian.Jackson@citrix.com>; Jan Beuli ch <jbeulich@suse.com>
>> Cc: Juergen Gross <jgross@suse.com>; Wei Liu <wei.liu2@citrix.com>;
>> ross.philipson@gmail.com; lars.kurth.xen@gmail.com; xen-
>> devel@lists.xen.org; committers@xenproject.org
>> Subject: [Xen-devel] Windows "heinsenbug" (WAS: Re: Notes Design
>> Session: Making Releases Lessons Learned: Improving Our Release Process
>> and Tooling)
>>
>> Hi all,
>>
>> On 07/27/2017 05:56 PM, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: Notes Design Session: Making Releases Lessons
>> Learned: Improving Our Release Process and Tooling"):
>>>> [Lars:]
>>>>> Ian: These are most likely software problems, most likely in Xen.
>>>>> ISSUE: nobody wants to debug Windows Heisenbugs
>>>>
>>>> Hmm, I think we believe to have understood what the issue is, it's just
>> that
>>>> the change needed is on the tool stack side (gracefully deal with a domain
>>>> rebooting while being migrated).
>>>
>>> No, the problem is that we don't understand why the domain is
>>> rebooting.  It should not be.
>>
>> This bug still seem to be around and likely going to impact once again
>> the release testing.
>>
>> As discussed during the summit, I am really thinking to make this
>> "heinsenbug" a blocker until somehow finally spend sometimes
>> investigating the problem and suggest actions.
> 
> If testing was done with PV drivers installed then we could get a lot more information into the logs. BSODs vs. clean shutdowns (perhaps due to Windows Update) would then become obvious.

Would it be feasible to get those installed in osstest?

Cheers,

-- 
Julien Grall

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

Re: Windows "heinsenbug" (WAS: Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling)

[Paul Durrant]

> -----Original Message-----
> From: Julien Grall [mailto:julien.grall@arm.com]
> Sent: 14 September 2017 03:49
> To: Paul Durrant <Paul.Durrant@citrix.com>; Ian Jackson
> <Ian.Jackson@citrix.com>; Jan Beuli ch <jbeulich@suse.com>
> Cc: Juergen Gross <jgross@suse.com>; Wei Liu <wei.liu2@citrix.com>;
> ross.philipson@gmail.com; lars.kurth.xen@gmail.com; xen-
> devel@lists.xen.org; committers@xenproject.org
> Subject: Re: [Xen-devel] Windows "heinsenbug" (WAS: Re: Notes Design
> Session: Making Releases Lessons Learned: Improving Our Release Process
> and Tooling)
> 
> Hi Paul,
> 
> On 13/09/17 19:26, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
> >> Julien Grall
> >> Sent: 13 September 2017 10:52
> >> To: Ian Jackson <Ian.Jackson@citrix.com>; Jan Beuli ch
> <jbeulich@suse.com>
> >> Cc: Juergen Gross <jgross@suse.com>; Wei Liu <wei.liu2@citrix.com>;
> >> ross.philipson@gmail.com; lars.kurth.xen@gmail.com; xen-
> >> devel@lists.xen.org; committers@xenproject.org
> >> Subject: [Xen-devel] Windows "heinsenbug" (WAS: Re: Notes Design
> >> Session: Making Releases Lessons Learned: Improving Our Release
> Process
> >> and Tooling)
> >>
> >> Hi all,
> >>
> >> On 07/27/2017 05:56 PM, Ian Jackson wrote:
> >>> Jan Beulich writes ("Re: Notes Design Session: Making Releases Lessons
> >> Learned: Improving Our Release Process and Tooling"):
> >>>> [Lars:]
> >>>>> Ian: These are most likely software problems, most likely in Xen.
> >>>>> ISSUE: nobody wants to debug Windows Heisenbugs
> >>>>
> >>>> Hmm, I think we believe to have understood what the issue is, it's just
> >> that
> >>>> the change needed is on the tool stack side (gracefully deal with a
> domain
> >>>> rebooting while being migrated).
> >>>
> >>> No, the problem is that we don't understand why the domain is
> >>> rebooting.  It should not be.
> >>
> >> This bug still seem to be around and likely going to impact once again
> >> the release testing.
> >>
> >> As discussed during the summit, I am really thinking to make this
> >> "heinsenbug" a blocker until somehow finally spend sometimes
> >> investigating the problem and suggest actions.
> >
> > If testing was done with PV drivers installed then we could get a lot more
> information into the logs. BSODs vs. clean shutdowns (perhaps due to
> Windows Update) would then become obvious.
> 
> Would it be feasible to get those installed in osstest?
> 

Julien,

  That should not be too hard. We have a driver install agent for XenServer that will manage all the necessary driver staging and required reboots. Hopefully it should mainly be a question of building that installer to pick up drivers from the upstream master branches rather than the internal XenServer branches. AFAIK osstest is using XenRT customized Windows images so hopefully we can use the slipstreamed XenRT agent to then fetch and run the driver installer. IIRC it sets some form of cookie in xenstore once it is done, so the rest of the test cycle would just need to wait for that to appear.

  I'll look into how to progress this when I get back from the US.

  Cheers,

    Paul

> Cheers,
> 
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Windows "heinsenbug" (WAS: Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling)

[Julien Grall]

Hi Paul,

On 09/14/2017 03:33 PM, Paul Durrant wrote:
> Julien,
> 
>    That should not be too hard. We have a driver install agent for XenServer that will manage all the necessary driver staging and required reboots. Hopefully it should mainly be a question of building that installer to pick up drivers from the upstream master branches rather than the internal XenServer branches. AFAIK osstest is using XenRT customized Windows images so hopefully we can use the slipstreamed XenRT agent to then fetch and run the driver installer. IIRC it sets some form of cookie in xenstore once it is done, so the rest of the test cycle would just need to wait for that to appear. >
>    I'll look into how to progress this when I get back from the US.

I wanted to bump the discussion. Do you have any update here?

Cheers,

-- 
Julien Grall

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

Re: Windows "heinsenbug" (WAS: Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling)

[Paul Durrant]

> -----Original Message-----
> From: Julien Grall [mailto:julien.grall@arm.com]
> Sent: 25 September 2017 22:32
> To: Paul Durrant <Paul.Durrant@citrix.com>; Ian Jackson
> <Ian.Jackson@citrix.com>; Jan Beuli ch <jbeulich@suse.com>
> Cc: Juergen Gross <jgross@suse.com>; Wei Liu <wei.liu2@citrix.com>;
> ross.philipson@gmail.com; lars.kurth.xen@gmail.com; xen-
> devel@lists.xen.org; committers@xenproject.org
> Subject: Re: [Xen-devel] Windows "heinsenbug" (WAS: Re: Notes Design
> Session: Making Releases Lessons Learned: Improving Our Release Process
> and Tooling)
> 
> Hi Paul,
> 
> On 09/14/2017 03:33 PM, Paul Durrant wrote:
> > Julien,
> >
> >    That should not be too hard. We have a driver install agent for XenServer
> that will manage all the necessary driver staging and required reboots.
> Hopefully it should mainly be a question of building that installer to pick up
> drivers from the upstream master branches rather than the internal
> XenServer branches. AFAIK osstest is using XenRT customized Windows
> images so hopefully we can use the slipstreamed XenRT agent to then fetch
> and run the driver installer. IIRC it sets some form of cookie in xenstore once
> it is done, so the rest of the test cycle would just need to wait for that to
> appear. >
> >    I'll look into how to progress this when I get back from the US.
> 
> I wanted to bump the discussion. Do you have any update here?
> 

A bit snowed for the next day or so, and unfortunately Ben (who maintains the installer) is on vacation until next week. I'll try to use a vanilla XenServer installer in a VM running on upstream and see if that works. If it does then we can probably just include running that in the osstest sequence. Using XenServer  PV drivers is probably prudent anyway, since they have already undergone extensive testing (albeit in a slightly different environment).

  Paul

> Cheers,
> 
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Windows "heinsenbug" (WAS: Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling)

[Paul Durrant]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
> Paul Durrant
> Sent: 26 September 2017 08:41
> To: 'Julien Grall' <julien.grall@arm.com>; Ian Jackson
> <Ian.Jackson@citrix.com>; Jan Beuli ch <jbeulich@suse.com>
> Cc: Juergen Gross <jgross@suse.com>; Wei Liu <wei.liu2@citrix.com>;
> ross.philipson@gmail.com; lars.kurth.xen@gmail.com; xen-
> devel@lists.xen.org; committers@xenproject.org
> Subject: Re: [Xen-devel] Windows "heinsenbug" (WAS: Re: Notes Design
> Session: Making Releases Lessons Learned: Improving Our Release Process
> and Tooling)
> 
> > -----Original Message-----
> > From: Julien Grall [mailto:julien.grall@arm.com]
> > Sent: 25 September 2017 22:32
> > To: Paul Durrant <Paul.Durrant@citrix.com>; Ian Jackson
> > <Ian.Jackson@citrix.com>; Jan Beuli ch <jbeulich@suse.com>
> > Cc: Juergen Gross <jgross@suse.com>; Wei Liu <wei.liu2@citrix.com>;
> > ross.philipson@gmail.com; lars.kurth.xen@gmail.com; xen-
> > devel@lists.xen.org; committers@xenproject.org
> > Subject: Re: [Xen-devel] Windows "heinsenbug" (WAS: Re: Notes Design
> > Session: Making Releases Lessons Learned: Improving Our Release Process
> > and Tooling)
> >
> > Hi Paul,
> >
> > On 09/14/2017 03:33 PM, Paul Durrant wrote:
> > > Julien,
> > >
> > >    That should not be too hard. We have a driver install agent for
> XenServer
> > that will manage all the necessary driver staging and required reboots.
> > Hopefully it should mainly be a question of building that installer to pick up
> > drivers from the upstream master branches rather than the internal
> > XenServer branches. AFAIK osstest is using XenRT customized Windows
> > images so hopefully we can use the slipstreamed XenRT agent to then
> fetch
> > and run the driver installer. IIRC it sets some form of cookie in xenstore
> once
> > it is done, so the rest of the test cycle would just need to wait for that to
> > appear. >
> > >    I'll look into how to progress this when I get back from the US.
> >
> > I wanted to bump the discussion. Do you have any update here?
> >
> 
> A bit snowed for the next day or so, and unfortunately Ben (who maintains
> the installer) is on vacation until next week. I'll try to use a vanilla XenServer
> installer in a VM running on upstream and see if that works. If it does then
> we can probably just include running that in the osstest sequence. Using
> XenServer  PV drivers is probably prudent anyway, since they have already
> undergone extensive testing (albeit in a slightly different environment).
> 

Happily I finally found some time to look into this and the news is good... I took the latest XenServer driver installer and ran it inside a Windows 10 VM on one of my upstream test rigs and it ran to completion (managing the necessary reboots to displace emulated devices) in non-interactive mode with no problems, so this could definitely be used in osstest to get PV drivers into Windows VMs as longs as osstest can handle waiting for the intaller's "I'm finished" flag to appear in xenstore (attr/PVAddons/Installed = 1).

  Paul

>   Paul
> 
> > Cheers,
> >
> > --
> > Julien Grall
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel