=Attendees =
LK: Lars Kurth
AM: Antony Messerli
BB: Bob Ball
SS: Stefano Stabellini
JF: Jim Fehlig
AP: Anthony Perard
JK: Josh Kearney
= Status Update =
== Test Failures ==
BB:
* Everything looking good
* AP created some new debian packages that contain all the necessary changes for the CI loop
* We manually disabled 2 tests (iSCSI related):
** 1 known upstream issue with Tempest Test Harness: we don't know how to fix it - and need input on an appropriate fix from the OpenStack community (SCSI specific)
** 2nd test, don't know yet why failing - AP is investigating
* We disabled those two tests
* With those tests disabled we get a nice pass-rate
== Running Tests in Parallel ==
BB: The Tempest Test suite is now running jobs in parallel
LK: Did you do the usage analysis since we are running in parallel for Advisory Board costing?
BB: Too early, we have only be running in parallel for 1 day
ACTION: BB look at VM usage in a week once we ran for a week in parallel
ACTION: LK to report back to Advisory Board
== Voting on Nova Changes ==
BB:
* Have agreement to switch voting on
* Done some quick analysis
* We are failing for approx. 10% of the changes submitted to Nova
* This does not mean that these are caused by us. They could be legitimate failures due to "bad" commits
* Have not yet performed cross-analysis whether these failures match Jenkins failures (aka are caused by "bad" commits to Nova)
* The decision when to switch voting on lies with us
* Right now the set-up is to comment on changes that have passed only
* Future Nova PL has given us permission to switch on voting also
ACTION: BB / AP to verify whether failures are caused by us or Jenkins OpenStack
AP: Believes that some of the issues are failing in our CI (could be spurious or infrastructure issues)
BB: Some at least do not fail in Jenkins OpenStack
LK: I did a number of cross-checks today and all the ones I looked at matched Jenkins failures in official OpenStack CI
BB: In the last 24 hours no single test has caused problems
BB: 18 failures in the last 24 hours, of which the most frequent ones only occurred 3 times
SS: is concerned that if we have spurious issues due to our Jenkins set-up, we may lose voting status and trust
SS: is also concerned about verifying changes to Jenkins, e.g. if we changed the baseline against which we are testing
BB: Typically Nova team would get frustrated within 24 hours if we do submit wrong votes
BB: Our CI would be disabled with appropriate mails to Nova lists and 3rd party lists
BB: We would then be expected to fix the issue, on our timer, and report back
BB: At which point we would be added back to the voting list
SS: Should we enable the two failing tests with issues?
BB: The infrastructure is sufficiently flexible to allow for having some tests removed
BB: In other words, we don't have to wait for the 2 remaining tests to be fixed
LK: If we are confident that we don't create spurious issues, we should enable voting
BB: The jobs that are running that do not run those two tests
BB: We can easily run those two jobs and mark a job as non-voting
BB: This would allow us to see the failures, but not create any problems for Nova
SS: addresses my concern
LK: Created
http://wiki.xenproject.org/wiki/OpenStack_CI_Loop_for_Xen-Libvirt for Xen Developer community
== Other ==
LK:
* We have a BoF at the Summit, "Lessons learned 3rd from setting up a 3rd party CI"
* Don't know the time yet when it will be scheduled (will voice preference for Wednesday)
* SS noted that he is travelling back to the UK on Friday afternoon
= Next Steps =
== Verify Stability and switch on Voting ==
BB: Verify whether failures are caused by us or Jenkins OpenStack
ALL: Make a decision when to switch on voting
*Agreement: send an email to this list (cc-ing xen-devel) and get ACK from the members on this call
== PR ==
Lars planning two blog posts on blog.xenproject.org (and push it to the OpenStack planet)
* Introducing Xen Project Jenkins
* Another one at the point we go voting
= OpenStack Summit sync =
Going: LK, BB, AP, SS
Not going: AM, JK, JF
LK: asks how the summits work
BB: in previous summits user and dev summits were split.
BB: Mon - Thu was User Summit
BB: Tue - Fri was Developer Summit (when all the Design sessions happen)
BB: Did we submit design sessions? NO, neither did SS and AP
AM: We can tag onto libvirt sessions - can bring up Xen as well
ACTION: LK, BB, SS, AP to attend libvirt session (assuming there is one) - if there is a lot of ground to cover, there is often another session
BB: Schedule for design summit has not yet been published, will check submission deadlines
ACTION: BB check submission deadlines and get back to the group
AM: stated that he is disappointed that we didn't get any Xen / XenServer sessions besides the BoF
ACTION: Lars follow up with SUSE on sponsored Xen sessions - there is still potential for a joint session
= Libvirt Update =
JF: 3 missing libvirt patches have been committed
JF: next Friday or Saturday there will be a new libvirt version (a release that includes all the necessary work) - version number is not yet complete
ACTION: JF to drop Lars a mail on the libvirt release
ACTION: AP, SS - if there any new libxl / libvirt issues then CC JF
AM: will have a go at the bleeding edge Xen and Libvirt version and verify it works
JF: also offered that he can help investigate Nova issues
= AOB =
No
