[openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo

Sourabh Patwardhan (sopatwar) sopatwar at cisco.com
Fri Feb 20 22:33:16 UTC 2015


Nova core reviewers,

May I request an FFE for Cisco VIF driver:
https://review.openstack.org/#/c/157616/

This is a small isolated change similar to the vhostuser / open contrail vif drivers for which FFE has been granted.

Thanks,
Sourabh


From: Christopher Yeoh <cbkyeoh at gmail.com<mailto:cbkyeoh at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tuesday, February 17, 2015 at 3:34 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo



On Wed, Feb 18, 2015 at 6:18 AM, Matt Riedemann <mriedem at linux.vnet.ibm.com<mailto:mriedem at linux.vnet.ibm.com>> wrote:


On 2/16/2015 9:57 PM, Jay Pipes wrote:
Hi Mikal, sorry for top-posting. What was the final decision regarding
the instance tagging work?

Thanks,
-jay

On 02/16/2015 09:44 PM, Michael Still wrote:
Hi,

we had a meeting this morning to try and work through all the FFE
requests for Nova. The meeting was pretty long -- two hours or so --
and we did in in the nova IRC channel in an attempt to be as open as
possible. The agenda for the meeting was the list of FFE requests at
https://etherpad.openstack.org/p/kilo-nova-ffe-requests

I recognise that this process is difficult for all, and that it is
frustrating when your FFE request is denied. However, we have tried
very hard to balance distractions from completing priority tasks and
getting as many features into Kilo as possible. I ask for your
patience as we work to finalize the Kilo release.

That said, here's where we ended up:

Approved:

     vmware: ephemeral disk support
     API: Keypair support for X509 public key certificates

We were also presented with a fair few changes which are relatively
trivial (single patch, not very long) and isolated to a small part of
the code base. For those, we've selected the ones with the greatest
benefit. These ones are approved so long as we can get the code merged
before midnight on 20 February 2015 (UTC). The deadline has been
introduced because we really are trying to focus on priority work and
bug fixes for the remainder of the release, so I want to time box the
amount of distraction these patches cause.

Those approved in this way are:

     ironic: Pass the capabilities to ironic node instance_info
     libvirt: Nova vif driver plugin for opencontrail
     libvirt: Quiescing filesystems with QEMU guest agent during image
snapshotting
     libvirt: Support vhost user in libvirt vif driver
     libvirt: Support KVM/libvirt on System z (S/390) as a hypervisor
platform

It should be noted that there was one request which we decided didn't
need a FFE as it isn't feature work. That may proceed:

     hyperv: unit tests refactoring

Finally, there were a couple of changes we were uncomfortable merging
this late in the release as we think they need time to "bed down"
before a release we consider stable for a long time. We'd like to see
these merge very early in Liberty:

     libvirt: use libvirt storage pools
     libvirt: Generic Framework for Securing VNC and SPICE
Proxy-To-Compute-Node Connections

Thanks again to everyone with their patience with our process, and
helping to make Kilo an excellent Nova release.

Michael


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


There are notes in the etherpad,

https://etherpad.openstack.org/p/kilo-nova-ffe-requests

but I think we wanted to get cyeoh and Ken'ichi's thoughts on the v2 and/or v2.1 question about the change, i.e. should it be v2.1 only with microversions or if that is going to block it, is it fair to keep out the v2 change that's already in the patch?


So if it can be fully merged by end of week I'm ok with it going into v2 and v2.1. Otherwise I think it needs to wait for microversions. I'd like to see v2.1 enabled next Monday (I don't want it go in just before a weekend). And the first microversion change (which is ready to go) a couple of days after). And we want a bit of an API freeze while that is happening.

Chris



--

Thanks,

Matt Riedemann



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150220/ee778a94/attachment.html>


More information about the OpenStack-dev mailing list