Re: [openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo
On Mon, Feb 23, 2015 at 03:24:01PM -0500, Jay Pipes wrote: > Here's another thought: is the big-bang integrated 6-month fixed release > cycle useful any more? Can we talk about using more of a moving train model > that doesn't have these long freeze cycles? At least for some of the > projects, I think that would ease some of the minds of folks who are > dismayed at having to wait yet another 6-9 months to see their code in the > Nova release. I entirely agree - the 6 month cycle creates massive pain for contributors who think openstack is supposed to be a fast moving agile project. I have co-incidentally just proposed we switch to a 2 month cycle, since we pretty much have everything in place to achieve that with little fuss, since we already do 3 milestone releases during that 6 month cycle. http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html Lets continue discussion in the separate thread, as many people probably ignore this thread due to its [nova] tag and subject Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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
Re: [openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo
Agreed. It causes two problems: 1) 9 month delays in getting code into a release 2) Some projects consider something to be breakable, from a back compatibility point of view, until it has made a formal release, which means anybody cutting releases from anything other than final/stable is facing the possibility of tenant facing API breakage. The attitude to this seems to differ between projects and indeed PTLs within the same project, but is quite worrying for distributors who want to release something more cutting edge than final/stable. Is there any evidence that our long freeze significantly increases stability or indeed testing? Or do people just start working on their features for the next release? On 23 February 2015 at 22:45, Dan Smith wrote: > > Seriously, what is the point of 6-month releases again? We are a > > free-form open source set of projects, with a lot of intelligent > > engineers. Why are we stuck using an outdated release model? > > I've been wondering this myself for quite a while now. I'm really > interested to hear what things would look like in a no-release model. > I'm sure it would be initially met with a lot of resistance, but I think > that in the end, it makes more sense to move to that sort of model and > let vendors/deployers more flexibly decide when to roll out new stuff > based on what has changed and what they value. > > --Dan > > > __ > 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 > > -- Duncan Thomas __ 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
Re: [openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo
On 02/23/2015 04:02 PM, Sean Dague wrote: On 02/23/2015 03:45 PM, Dan Smith wrote: Seriously, what is the point of 6-month releases again? We are a free-form open source set of projects, with a lot of intelligent engineers. Why are we stuck using an outdated release model? I've been wondering this myself for quite a while now. I'm really interested to hear what things would look like in a no-release model. I'm sure it would be initially met with a lot of resistance, but I think that in the end, it makes more sense to move to that sort of model and let vendors/deployers more flexibly decide when to roll out new stuff based on what has changed and what they value. What's the alternative proposed release model? Release at-will. No pre-determined date-based releases. Smaller list of features in each tagged release. Focus on API versioning, not releases. What's the compatibility story with Glance / Neutron / Cinder in whatever that model is? Exactly the same as it is now: everything is based on the server supported API version and the python-xxxclient release that understands that server API version, and integrating support for that client release into Nova. There's really very little different at this point between our usage of python-neutronclient and our usage of the requests Python library. We should pin to a particular library version that we make use of the features from, and upgrade the pinning when we utilize functionality that is a newer release. What's the sliding upgrade window look like? Whatever we want to make it. :) With our RPC and object versioning functionality, we can drop support for some old RPC API and object versions after some arbitrary amount of time (check with operators and get sign off, then just do it). What's the stable maint story look like? the security fix story? "stable maintenance" should be entirely left up to the distributions, IMO. Security fix story should be up to the distributions to track when their products are patched. Upstream should be concerned with quick fixes into the upstream branches and coordinated communication with distributions. I get being frustrated with a thing, but there are a lot of considerations before redoing the release cycle. Understood completely. But I'm curious to see just how much grief we put ourselves through in trying to do date-based releases when our contributor community just isn't assembled in a way that makes those releases seem reasonable. Best, -jay __ 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
Re: [openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo
> What's the alternative proposed release model? I deleted a couple paragraphs of the above before sending this, thinking (like Joe) that there probably needs to be a specific discussion aimed at this topic. But: > What's the compatibility story with Glance / Neutron / Cinder in > whatever that model is? I think we end up making the tight integrations where we need to. Presumably Nova and Neutron still need to coordinate tightly. I'm not sure Nova and Glance do at this point. > What's the sliding upgrade window look like? Right now we're maintaining some level of RPC compatibility to a point far earlier than Juno. The six month releases give us the *only* points at which we can (currently, by our existing rules) break compatibility. Presumably we just need to define the minimum timeframe, and then iterate our interfaces when it makes sense (and fits a policy). Maybe that's six months; maybe longer, maybe shorter. > What's the stable maint story look like? the security fix story? Aren't you the one that wants to get rid of stable-maint? How we handle security issues is certainly something worthy of a lot of discussion. If the community only maintains a single stream, then the answer is "move forward". If the only people maintaining slower-moving streams are vendors or distros then I'd say the answer is "ask your vendor." > I get being frustrated with a thing, but there are a lot of > considerations before redoing the release cycle. Well, I'll refer to my original words: > On 02/23/2015 03:45 PM, Dan Smith wrote: >> I've been wondering this myself for quite a while now. I'm really >> interested to hear what things would look like in a no-release model. That's all. Just interested. I do think it's the sane way forward, long-term. --Dan signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo
On Mon, Feb 23, 2015 at 03:47:20PM +0100, Nikola Đipanov wrote: > On 02/20/2015 11:33 PM, Sourabh Patwardhan (sopatwar) wrote: > > 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. > > Actually the FFEs get decided by a subset of the Nova core team called > the nova-drivers. You can see it briefly mentioned here [1]. (*) > > You can see an ethepad that hosts the minutes of the meeting where > nova-drivers were deciding on FFEs at [2] which may give you more > insight into why your BP did not make the cut. Unfortunately the Cisco VIF driver was not on the list of features considered in the first place, since (AFAICT) this FFE request was only made after the FFEs had all been decided for Kilo. Personally I think the Nova FFE process is too inflexible, and thus I would support inclusion of this (and any) VIF driver into Kilo regardless of FFE status for pragmatic reasons, but this appears to be a minority view right now. > (*) On a side note this is an example of us not making the process and > the players clear to our contributors, so we should probably try to > document the role of the nova-drivers better at the very least. As a member of Nova drivers, I personally think that the team should never have existed in the first place, and should cease to exist at the soonest opportunity. That it exists at all is just an accident of history due the use of launchpad for blueprint approval. IMHO it makes no sense to restrict which cores can participate in feature review & approval - any Nova core should be able to be choose to participate as their time allows, without needing to be granted access to yet another special group. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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
Re: [openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo
On 02/20/2015 11:33 PM, Sourabh Patwardhan (sopatwar) wrote: > 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 > > Hey Sourabh, Sorry that you didn't get any responses sooner. Actually the FFEs get decided by a subset of the Nova core team called the nova-drivers. You can see it briefly mentioned here [1]. (*) You can see an ethepad that hosts the minutes of the meeting where nova-drivers were deciding on FFEs at [2] which may give you more insight into why your BP did not make the cut. Once again - apologies for any poor experience you may have had trying to contribute to Nova. N. [1] https://wiki.openstack.org/wiki/Nova [2] https://etherpad.openstack.org/p/kilo-nova-ffe-requests (*) On a side note this is an example of us not making the process and the players clear to our contributors, so we should probably try to document the role of the nova-drivers better at the very least. __ 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
Re: [openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo
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 mailto:cbky...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, February 17, 2015 at 3:34 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@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 mailto: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://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for u
Re: [openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo
On Wed, Feb 18, 2015 at 6:18 AM, Matt Riedemann 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
Re: [openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo
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? -- 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
Re: [openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo
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
[openstack-dev] [nova] Outcome of the nova FFE meeting for Kilo
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 -- Rackspace Australia __ 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
