Note, that this meeting is open to members of the Xen Project community. If you want to be invited drop me a line.
= Attendees =
* Lars Kurth )Xen Project)
* Bob Ball (Citrix)
* Michael Glasgow (Oracle)
* Stefano Stabellini (Citrix)
* Anthony Perard (Citrix)
* Jim Fehlig (Suse)
= Agenda =
Note that there are a few call to action item's in the agenda, which we could not resolve on the call.
== Transfer of account to Xen Project ==
** Accounts are set up, account name is xenlibvirtci and is registered to libvirt-openstack-ci@xxxxxxxxxxxxxx
** At last week's Advisory Board meeting we agreed to allow the transfer
Bob: Asks whether authorisation and billing is in place?
Lars: Correct, we can get the work started now
== Official OpenStack documentation ==
** We asked to backport necessary patches to Xen 4.5.1 and 4.4.3 and Lars will put together the docs
** With Xen 4.5.1 out as of today, I can get started with this
Lars asked whether anyone is willing to help with reviews of the documentation
Bob will review
Michael Glasgow: happy to have a look also, but is not yet that familiar with OpenStack
Jim: Happy to look at libvirt portion of the documentation
Bob: When also asked when we will start using Xen 4.5.1 + libvirt 1.2.15 in the CI environment vs. the baseline with patches
Bob: The proposal would be to use official packages
Anthony: Xen 4.5.1 not in any distro yet, but can this be done
[Aside, these patches will also make it into Xen 4.4.3, when it comes out in a few weeks]
** Agreement that this is the best way forward **
== Meeting Cadence ==
Meeting cadence: Bob Ball has a conflict with a bi-weekly call and and would like to change the meeting cadence to once every 4 weeks, rather than the last Wed every month
** Agreement: every 4th Wednesday in 5 weeks time, to avoid conflict **
ACTION: Lars to change invite. Next meeting: on 29th of July, then every 4 weeks
ACTION: Lars also to change from GotoMeeting to a traditional bridge, given the quality issues we had on today's call
** Note: Lars will not be able too chair the July meeting, as I will tarvelling **
== CI Maintenance ==
Expand CI maintenance beyond the UK time-zone: this would require someone not based in Europe to work with Bob initially and step in if there are CI loop failures, such that we can turn around fixing times more
quickly
Issue: right now CI maintenance is only done in the UK. Great opportunity to spread some of the knowledge to people in other timezones such that we can turn this round quickly.
Oracle would be willing to help out
ACTION: Michael to make an introduction of Alex to Bob to figure out next steps
== Open Bugs, ...==
Note, that I agreed with Stefano/Anthony that in future we will aim to send out updates on bugs prior to the meeting and CC
wg-openstack@xxxxxxxxxxxxxxxxxxxx, such that interested parties have a chance to investigate and prepare prior to the call. Walking through the bug details, without allowing others prep time prior to the
meeting, makes it hard to follow the discussion on the call.
ACTION: highlight *call to action* in this set of minutes (done)
1) Device Model not starting on time,
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg03549.html
Anthony is investigating, it looks like a genuine timeout issue. We should increase the timeout, but by how much?
Note that this is not a Nova issue, but an issue within Xen
ACTION: All follow up on xen-devel.
2) race between nova and xen vif scripts, https://bugs.launchpad.net/nova/+bug/1461642
This is a race setting up iptables, between Nova and Xen. Anthony found a Xen vif2 script that doesn't setup iptables at all.
Is using "vif2" instead of "vif" the right fix? We'll follow up on xen-devel.
ACTION: Anthony to to follow up on xen-devel and post link to this mail to help find the correct answer. Other's to chip if they have a view
3) Tempest asks to start a test with root=vda, https://bugs.launchpad.net/nova/+bug/1443898
This is the same bug I wrote about in
alpine.DEB.2.02.1506041648360.19838@xxxxxxxxxxxxxxxxxxxxxxx
Anthony is working on an update for his patch. - enable Neutron: vif name too long (see https://bugs.launchpad.net/nova/+bug/1450465)
The problem is that the Xen vif scripts add "-emu" to the vif name for HVM guests.
The vif name chosen by Neutron is already very long, adding "-emu" causes an overflow error.
ACTION: Raise the bug in libxl/xen-devel. We could need to change the "-emo" postfix but do not know whether there are any side-effects. Jim believes that there may be
** Call for action: Would anybody be willing to help? In particular, we need to establish whether changing "-emu" to something else will break exiting users. This should be fixed in libxl and the
Xen hotplug scripts. **
4) nova does not respect reserved memory for dom0, https://bugs.launchpad.net/nova/+bug/1187330
When Dom0 is started without dom0_mem on the Xen command line
Nova memory accounting is wrong. Not a critical bug, but bothersome.
People on the call din't know Nova very well
** Call for action: would anybody who is familiar with this portion of Nova be willing to help? We didn't have any Nova expert on the call this time **
== Openstack tests for OSSTest ==
OSSTest - Background
* Official CI loop for Xen Project and runs in Xen Project Test Lab. See https://blog.xenproject.org/2015/04/15/introducing-xen-projects-new-test-lab/
* Gates Xen Commits and also tests Linux and Libvirt and other dependent projects together with
* The set-up is different from the OpenStack CI loop in that it runs on different hardware
Stefano: We want to add OpenStack tests to ensure that we do not break OpenStack during ongoing Xen Development. In a nutshell we would run Tempest as part of OSSTest
Anthony: Trying to install DevStack within OSSTEST environment. Found some issues
Lars: So there are issues, but are these fixable?
Anthony: Yes
Lars: IS any action from anyone required at this stage?
Anthony: No
== Update from meeting with John Garbutt, Nova PTL ==
Had a productive meeting with John Garbutt
Now have an official tag for xen in Nova and OpenStack bugtracker
Talked about what we need to do get to the same level of support for KVM
Various angles:
* Test will need to be run most certainly by infra => to enable this tests need to be more stable than now; in other words we need to continue fixing issues
* There needs to be good correlation with existing Jenkins failures
* Need to build our relationship with the infrastructure team => this is why having better support coverage as part of running the CI is important
* Need to join IRC channels, and get to know people
* Infrastructure : to get to group A we initially need to get added to the check queue
* It is unclear at this stage whether we also need to be in gate check
* Xen and libvirt will need to be run in nested virt in another cloud, but Rackspace
* John mentioned that he is not aware of any KVM OpenStack clouds that enable nested virt. In fact he stated, that infra Jenkins doesn't for this reason test KVM, but QEMU. Even though KVM is in group A. If this
is correct, we may have an issue and will need to work with infra to find a way forward
Micheal: would it be desirable to be in gate checks?
Stefano: is not sure?
Lars: probably don't need it initially, but we shouldn't assume that getting into the gate queue is anything more than a first step
