On Wed, Feb 18, 2015 at 6:18 AM, Matt Riedemann <mrie...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev