[openstack-dev] [nova] Feature Freeze Exception Request
Hello, I would like to request feature freeze exception for the implementation of Nested Quota Driver for Nova, which does the quota management of nested projects. Blueprint https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api Addressed by, https://review.openstack.org/#/c/160605/ The patches in the order of dependency are as follows, 1. Create column allocated in Quota table https://review.openstack.org/#/c/151327/ https://review.openstack.org/#/c/151327/ 2. Set default values to sub-projects and users. https://review.openstack.org/#/c/151677/ https://review.openstack.org/#/c/151677/ 3. Modification of settable quotas of nested projects https://review.openstack.org/#/c/200342 https://review.openstack.org/#/c/200342 4. Finding parent_id and immediate child list https://review.openstack.org/#/c/200941/ https://review.openstack.org/#/c/200941/ 5. Adding v2 and v3 support https://review.openstack.org/#/c/149828/ Keystone already supports nested projects.Without Nested Quota Driver ,Nova will not be able to support nested projects,even if they exist in keystone. Nested Quota Driver is a superset of DbQuotaDriver and it supports one to N levels of projects.It can support nested as well as non-nested projects. The implementation of Nested Quota Driver is completed and the code is under review. It is supposed to become the default quota driver of nova. To avoid any potential risks,it can be deployed as an optional driver in the current release and can be made default in the subsequent release. Kindly grant freeze exception for the change.Nested projects are very important for large organizations like CERN who are waiting for this code to get merged in Liberty. Organizations like NASA, Yahoo, Federal University of Campina Grande,Brazil etc also have expressed keen interest in this feature. best regards sajeesh __ 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] Feature Freeze Exception Request - bp/libvirt-kvm-systemz
regarding the following question about this remaining nova FFE patch... https://review.openstack.org/#/c/149242/ The question is what is the impact to s390x users without this? Does this make using cinder impossible for zKVM users? The impact of this patch not beeing merged would be that s390x users could use cinder only for iSCSI attached volumes. FC-attached volumes could not be used. For developers and CI that would be an acceptable restriction, but for real s390x users/customers this would be a heavy restriction, since FibreChannel is the default and most important attachment in the enterprise market. Hope, this helps. Kind regards, Marco Pavone Matt Riedemann mrie...@linux.vnet.ibm.com wrote on 16.02.2015 22:10:35: From: Matt Riedemann mrie...@linux.vnet.ibm.com To: openstack-dev@lists.openstack.org Date: 16.02.2015 22:16 Subject: Re: [openstack-dev] [nova] Feature Freeze Exception Request - bp/libvirt-kvm-systemz On 2/10/2015 4:27 AM, Daniel P. Berrange wrote: On Mon, Feb 09, 2015 at 05:15:26PM +0100, Andreas Maier wrote: Hello, I would like to ask for the following feature freeze exceptions in Nova. The patch sets below are all part of this blueprint: https://review.openstack.org/#/q/status:open+project:openstack/nova +branch:master+topic:bp/libvirt-kvm-systemz,n,z and affect only the kvm/libvirt driver of Nova. The decision for merging these patch sets by exception can be made one by one; they are independent of each other. 1. https://review.openstack.org/149242 - FCP support Title: libvirt: Adjust Nova to support FCP on System z systems What it does: This patch set enables FCP support for KVM on System z. Impact if we don't get this: FCP attached storage does not work for KVM on System z. Why we need it: We really depend on this particular patch set, because FCP is our most important storage attachment. Additional notes: The code in the libvirt driver that is updated by this patch set is consistent with corresponding code in the Cinder driver, and it has seen review by the Cinder team. 2. https://review.openstack.org/150505 - Console support Title: libvirt: Enable serial_console feature for system z What it does: This patch set enables the backing support in Nova for the interactive console in Horizon. Impact if we don't get this: Console in Horizon does not work. The mitigation for a user would be to use the Log in Horizon (i.e. with serial_console disabled), or the virsh console command in an ssh session to the host Linux. Why we need it: We'd like to have console support. Also, because the Nova support for the Log in Horizon has been merged in an earlier patch set as part of this blueprint, this remaining patch set makes the console/log support consistent for KVM on System z Linux. 3. https://review.openstack.org/150497 - ISO/CDROM support Title: libvirt: Set SCSI as the default cdrom bus on System z What it does: This patch set enables that cdrom drives can be attached to an instance on KVM on System z. This is needed for example for cloud-init config files, but also for simply attaching ISO images to instances. The technical reason for this change is that the IDE attachment is not available on System z, and we need SCSI (just like Power Linux). Impact if we don't get this: - Cloud-init config files cannot be on a cdrom drive. A mitigation for a user would be to have such config files on a cloud-init server. - ISO images cannot be attached to instances. There is no mitigation. Why we need it: We would like to avoid having to restrict cloud-init configuration to just using cloud-init servers. We would liketo be able to support ISO images. Additional notes: This patch is a one line change (it simply extends what is already done in a platform specific case for the Power platform, to be also used for System z). I will happily sponsor exception on patches 2 3, since they are pretty trivial easily understood. I will tenatively sponsor patch 1, if other reviewers feel able to do a strong review of the SCSI stuff, since this is SCSI host setup is not something I'm particularly familiar with. Regards, Daniel 2 of the 3 changes have been merged outside of the FFE process, the only remaining one is the FCP support: https://review.openstack.org/#/c/149242/ The question is what is the impact to s390x users without this? Does this make using cinder impossible for zKVM users? -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http
Re: [openstack-dev] [nova] Feature Freeze Exception Request - bp/libvirt-kvm-systemz
On 2/10/2015 4:27 AM, Daniel P. Berrange wrote: On Mon, Feb 09, 2015 at 05:15:26PM +0100, Andreas Maier wrote: Hello, I would like to ask for the following feature freeze exceptions in Nova. The patch sets below are all part of this blueprint: https://review.openstack.org/#/q/status:open+project:openstack/nova +branch:master+topic:bp/libvirt-kvm-systemz,n,z and affect only the kvm/libvirt driver of Nova. The decision for merging these patch sets by exception can be made one by one; they are independent of each other. 1. https://review.openstack.org/149242 - FCP support Title: libvirt: Adjust Nova to support FCP on System z systems What it does: This patch set enables FCP support for KVM on System z. Impact if we don't get this: FCP attached storage does not work for KVM on System z. Why we need it: We really depend on this particular patch set, because FCP is our most important storage attachment. Additional notes: The code in the libvirt driver that is updated by this patch set is consistent with corresponding code in the Cinder driver, and it has seen review by the Cinder team. 2. https://review.openstack.org/150505 - Console support Title: libvirt: Enable serial_console feature for system z What it does: This patch set enables the backing support in Nova for the interactive console in Horizon. Impact if we don't get this: Console in Horizon does not work. The mitigation for a user would be to use the Log in Horizon (i.e. with serial_console disabled), or the virsh console command in an ssh session to the host Linux. Why we need it: We'd like to have console support. Also, because the Nova support for the Log in Horizon has been merged in an earlier patch set as part of this blueprint, this remaining patch set makes the console/log support consistent for KVM on System z Linux. 3. https://review.openstack.org/150497 - ISO/CDROM support Title: libvirt: Set SCSI as the default cdrom bus on System z What it does: This patch set enables that cdrom drives can be attached to an instance on KVM on System z. This is needed for example for cloud-init config files, but also for simply attaching ISO images to instances. The technical reason for this change is that the IDE attachment is not available on System z, and we need SCSI (just like Power Linux). Impact if we don't get this: - Cloud-init config files cannot be on a cdrom drive. A mitigation for a user would be to have such config files on a cloud-init server. - ISO images cannot be attached to instances. There is no mitigation. Why we need it: We would like to avoid having to restrict cloud-init configuration to just using cloud-init servers. We would like to be able to support ISO images. Additional notes: This patch is a one line change (it simply extends what is already done in a platform specific case for the Power platform, to be also used for System z). I will happily sponsor exception on patches 2 3, since they are pretty trivial easily understood. I will tenatively sponsor patch 1, if other reviewers feel able to do a strong review of the SCSI stuff, since this is SCSI host setup is not something I'm particularly familiar with. Regards, Daniel 2 of the 3 changes have been merged outside of the FFE process, the only remaining one is the FCP support: https://review.openstack.org/#/c/149242/ The question is what is the impact to s390x users without this? Does this make using cinder impossible for zKVM users? -- 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-dev] [nova] Feature Freeze Exception Request (DRBD for Nova) WAS: Re: [nova] Request Spec Freeze Exception (DRBD for Nova)
Re-titling the email so that it does not get missed as it does not have the right subject line. I looked at the code and it is quite straightforward - some small nits inline but other than that - no reason to keep it out. This is the first contribution to Nova by Philipp and his team, and their experience navigating our bureaucracy-meritocracy seems far from a happy one (from what I could gather on IRC at least) - one more reason to not keep this feature out. Thanks, N. On 02/16/2015 03:06 PM, Philipp Marek wrote: Hi all, Nikola just told me that I need an FFE for the code as well. Here it is: please grant a FFE for https://review.openstack.org/#/c/149244/ which is the code for the spec at https://review.openstack.org/#/c/134153/ Regards, Phil __ 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] Feature Freeze Exception Request (DRBD for Nova) WAS: Re: [nova] Request Spec Freeze Exception (DRBD for Nova)
On 02/16/2015 03:27 PM, Nikola Đipanov wrote: Re-titling the email so that it does not get missed as it does not have the right subject line. Ugh - as Daniel pointed out - the spec is not actually approved so please disregard this email - I missed that bit. Although - I still stand by the following paragraph: This is the first contribution to Nova by Philipp and his team, and their experience navigating our bureaucracy-meritocracy seems far from a happy one (from what I could gather on IRC at least) - one more reason to not keep this feature out. __ 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] Feature Freeze Exception request for x509 keypairs
I'm happy to sponsor this. I've reviewed all the patches as well and as Claudiu mentions we have this lined up as being the first api change to use microversions Regards, Chris On Thu, Feb 12, 2015 at 10:50 PM, Claudiu Belu cb...@cloudbasesolutions.com wrote: Hello. I would like to ask for a FFE for the x509 keypairs blueprint: https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates This blueprint is split up into 3 commits: [1] Database migration: previously merged, but had to be reverted because of a small issue. Everything is fixed, original reverter Johannes Erdfelt gave his +1, currently the commit has a +2. https://review.openstack.org/#/c/150800/ [2] Nova-API change: It uses the microversioning API and it has been decided to be the first microversioning commit, since it is closest to merge. Christopher Yeoh reviewed helped with this commit. https://review.openstack.org/#/c/140313/ [3] X509 keypair implementation: Simple commit, it had a +2 on a previous commit. https://review.openstack.org/#/c/136869/ I also want to point out that this blueprint targets all the drivers, not just Hyper-V. This blueprint targets all the users that desire to deploy instances with Windows guests and desire password-less authentication, the same way users can ssh into Linux-type guests. Best regards, Claudiu Belu __ 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] Feature Freeze Exception request for x509 keypairs
2015-02-12 21:20 GMT+09:00 Claudiu Belu cb...@cloudbasesolutions.com: Hello. I would like to ask for a FFE for the x509 keypairs blueprint: https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates This blueprint is split up into 3 commits: [1] Database migration: previously merged, but had to be reverted because of a small issue. Everything is fixed, original reverter Johannes Erdfelt gave his +1, currently the commit has a +2. https://review.openstack.org/#/c/150800/ [2] Nova-API change: It uses the microversioning API and it has been decided to be the first microversioning commit, since it is closest to merge. Christopher Yeoh reviewed helped with this commit. https://review.openstack.org/#/c/140313/ [3] X509 keypair implementation: Simple commit, it had a +2 on a previous commit. https://review.openstack.org/#/c/136869/ I also want to point out that this blueprint targets all the drivers, not just Hyper-V. This blueprint targets all the users that desire to deploy instances with Windows guests and desire password-less authentication, the same way users can ssh into Linux-type guests. The patches have been much reviewed and this feature will be the first microversion. so I'm happy to support this development in Kilo. Thanks Ken Ohmichi __ 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] Feature Freeze Exception Request (libvirt vhostuser vif driver)
On Mon, Feb 09, 2015 at 10:04:49AM +, Czesnowicz, Przemyslaw wrote: Hi, I would like to request FFE for vhostuser vif driver. 2 reviews : https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/libvirt-vif-vhost-user,n,z BP: https://blueprints.launchpad.net/nova/+spec/libvirt-vif-vhost-user Spec: https://review.openstack.org/138736 Blueprint was approved but it's status was changed because of FF. Vhostuser is a Qemu feature that allows fastpath into the VM for userspace vSwitches. The changes are small and mostly contained to libvirt driver. Vhostuser support was proposed for Juno by Snabb switch guys but didn't make it, this implementation supports their usecase as well . As Nikola says, this is self-contained code, and a pretty simple bit of code to understand, so should be straightforward to merge. So I'm happy to sponsor it. 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] Feature Freeze Exception request for x509 keypairs
yea, this patch is on good shape. 2015-02-13 9:05 GMT+08:00 Ken'ichi Ohmichi ken1ohmi...@gmail.com: 2015-02-12 21:20 GMT+09:00 Claudiu Belu cb...@cloudbasesolutions.com: Hello. I would like to ask for a FFE for the x509 keypairs blueprint: https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates This blueprint is split up into 3 commits: [1] Database migration: previously merged, but had to be reverted because of a small issue. Everything is fixed, original reverter Johannes Erdfelt gave his +1, currently the commit has a +2. https://review.openstack.org/#/c/150800/ [2] Nova-API change: It uses the microversioning API and it has been decided to be the first microversioning commit, since it is closest to merge. Christopher Yeoh reviewed helped with this commit. https://review.openstack.org/#/c/140313/ [3] X509 keypair implementation: Simple commit, it had a +2 on a previous commit. https://review.openstack.org/#/c/136869/ I also want to point out that this blueprint targets all the drivers, not just Hyper-V. This blueprint targets all the users that desire to deploy instances with Windows guests and desire password-less authentication, the same way users can ssh into Linux-type guests. The patches have been much reviewed and this feature will be the first microversion. so I'm happy to support this development in Kilo. Thanks Ken Ohmichi __ 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
[openstack-dev] [nova] Feature Freeze Exception request for x509 keypairs
Hello. I would like to ask for a FFE for the x509 keypairs blueprint: https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates This blueprint is split up into 3 commits: [1] Database migration: previously merged, but had to be reverted because of a small issue. Everything is fixed, original reverter Johannes Erdfelt gave his +1, currently the commit has a +2. https://review.openstack.org/#/c/150800/ [2] Nova-API change: It uses the microversioning API and it has been decided to be the first microversioning commit, since it is closest to merge. Christopher Yeoh reviewed helped with this commit. https://review.openstack.org/#/c/140313/ [3] X509 keypair implementation: Simple commit, it had a +2 on a previous commit. https://review.openstack.org/#/c/136869/ I also want to point out that this blueprint targets all the drivers, not just Hyper-V. This blueprint targets all the users that desire to deploy instances with Windows guests and desire password-less authentication, the same way users can ssh into Linux-type guests. Best regards, Claudiu Belu __ 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] Feature Freeze Exception Request
Hello, I'd like to request a feature freeze exception for the change, https://review.openstack.org/#/c/149828/ This change implements NestedQuotaDriver that does the quota management in nested projects. The specs has been merged : https://review.openstack.org/#/c/129420/ The blueprint was approved. https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api But due to Feature Freeze,its status was changed to Pending Approval . Keystone already supports nested projects. This change implements the quota management of those nested projects. Without this change(NestedQuotaDriver), Nova will not be able to support nested projects,even if they exist in keystone.NestedQuotaDriver is made by adding nested quota functionality to the existing DbQuotaDriver. It is a superset of DbQuotaDriver and its supports one to N levels of projects.That is,it can support nested as well as non-nested projects. The implementation of NestedQuotaDriver is over and the code is under review. All the use cases mentioned in the blue print have been implemented. It is supposed to become the default quota driver of nova.To avoid any potential risks,it can be deployed as an optional driver in the current release(Kilo) and can be made default in the next release(L). Kindly grant freeze exception for the change.Nested projects are very important for large organizations like CERN who are waiting for this code to get merged in Kilo.Yahoo also has expressed keen interest in this feature. best regards sajeesh __ 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] Feature Freeze Exception Request
+1 The specs has been merged through FFE request, doesn't that mean the BP is already approved? Maybe the status of the BP just need to be updated to reflect the current state. -Lin On Wed, Feb 11, 2015 at 9:26 AM, Sajeesh Cimson Sasi sajeesh...@cern.ch wrote: Hello, I'd like to request a feature freeze exception for the change, https://review.openstack.org/#/c/149828/ This change implements NestedQuotaDriver that does the quota management in nested projects. The specs has been merged :* https://review.openstack.org/#/c/129420/ https://review.openstack.org/#/c/129420/* The blueprint was approved. https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api But due to Feature Freeze,its status was changed to Pending Approval . Keystone already supports nested projects. This change implements the quota management of those nested projects. Without this change(NestedQuotaDriver), Nova will not be able to support nested projects,even if they exist in keystone.NestedQuotaDriver is made by adding nested quota functionality to the existing DbQuotaDriver. It is a superset of DbQuotaDriver and its supports one to N levels of projects.That is,it can support nested as well as non-nested projects. The implementation of NestedQuotaDriver is over and the code is under review. All the use cases mentioned in the blue print have been implemented. It is supposed to become the default quota driver of nova.To avoid any potential risks,it can be deployed as an optional driver in the current release(Kilo) and can be made default in the next release(L). Kindly grant freeze exception for the change.Nested projects are very important for large organizations like CERN who are waiting for this code to get merged in Kilo.Yahoo also has expressed keen interest in this feature. best regards sajeesh __ 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] Feature Freeze Exception Request (libvirt vhostuser vif driver)
On 02/09/2015 11:04 AM, Czesnowicz, Przemyslaw wrote: Hi, I would like to request FFE for vhostuser vif driver. 2 reviews : https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/libvirt-vif-vhost-user,n,z BP: https://blueprints.launchpad.net/nova/+spec/libvirt-vif-vhost-user Spec: https://review.openstack.org/138736 Blueprint was approved but it’s status was changed because of FF. Vhostuser is a Qemu feature that allows fastpath into the VM for userspace vSwitches. The changes are small and mostly contained to libvirt driver. Vhostuser support was proposed for Juno by Snabb switch guys but didn’t make it, this implementation supports their usecase as well . The patches are really non-invasive, and extremely contained, and have had several reviews. I cannot come up with a good reason to keep it out. This is also interesting for the NFV use-cases (mainly) so I'd like to see it happen on that account too - and thus will be happy to sponsor it. N. __ 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] Feature Freeze Exception Request
On Fri, Feb 06, 2015 at 10:47:29AM -0500, Solly Ross wrote: Hi, I would like to request a feature freeze exception for the Websockify security proxy framework blueprint [1]. The blueprint introduces a framework for defining security drivers for the connections between the websocket proxy and the hypervisor, and provides a TLS driver for VNC connections using the VeNCrypt RFB auth method. The two patches [2] have sat in place with one +2 (Dan Berrange) and multiple +1s for a while now (the first does not currently show any votes because of a merge conflict that I had to deal with recently). I'll sponsor this one obviously since I have already +2'd it. I'd really like to see this feature merged for Kilo, since we've already delayed it from merge in Juno due to lack of reviewer attention, and it'd be giving a pretty poor impression to delay it another 6 months for the same reason The feature itself does touch codepaths which impact existing code, but I think the risk is low because the feature is opt-in, so out of the box users will still be using the existing proven stable codepaths. 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] Feature Freeze Exception request for Add the Nova libvirt StorPool attachment driver.
On Tue, Feb 10, 2015 at 12:52:38PM +0200, Peter Penchev wrote: On Tue, Feb 10, 2015 at 12:34 PM, Daniel P. Berrange berra...@redhat.com wrote: On Tue, Feb 10, 2015 at 12:28:27PM +0200, Peter Penchev wrote: Hi, I'd like to request a feature freeze exception for the change: https://review.openstack.org/140733/ It's a small, self-contained driver for attaching StorPool-backed Cinder volumes to existing Nova virtual machines. It does not touch anything outside its own bailiwick (adds a new class to nova/virt/libvirt/volume.py) and is just a couple of lines of code, passing requests through to the JSON-over-HTTP StorPool API. The Cinder support for volumes created on a StorPool cluster was merged before Kilo-1, and IMVHO it would make sense to have a Nova attachment driver to actually use the Cinder support. The change was reviewed by Daniel Berrange, who posted a very reasonable suggestion for restructuring the code, which I implemented within a few days. I would be very grateful if somebody could take a look at the proposed addition and consider it for a feature freeze exception. Thanks in advance for your time, and keep up the great work! The Feature Freeze Exception process is for approving the merge of changes whose specs/blueprints are already approved. Unfortunately, IIUC, your blueprint is not approved, so it is not possible to request a FFE for merging the changes in question. The deadline for requesting Spec/Blueprint Freeze Exceptions has passed quite a while ago now. Hi, Actually, the blueprint was approved quite some time ago, and it also has a favorable comment by John Garbutt from January 26th (two days after I submitted the updated change addressing your concerns). Then on February 5th Thierry Carrez changed its status to Pending approval with a comment stating that it missed the non-priority feature freeze deadline (I think that the johnthetubaguy attribution at the end of the comment is more of a copy/paste error, since the change indeed seems to have been done by Thierry Carrez). Ok, will need John G to clarify then. I was judging from the fact that the status is Pending approval and the most recent comment says Sorry, we have now hit the non-priority feature freeze for kilo. Please resubmit your spec for the L release 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] Feature Freeze Exception request
On Tue, Feb 10, 2015 at 11:55:54AM +0200, Eduard Matei wrote: Hi, I would like to request a FFE for https://review.openstack.org/#/c/134134/ It is a change that allows a driver to use type file instead of block for local volumes. It was blocked because at that time there was no use for it. Now, we have a driver merged which currently returns loca for driver_volume_type; we would like to return driver_volume_type: file (which is the correct type) which will then result (via this change) in a disk type = file in the xml being generated. Also, this changeset doesn't remove any code, doesn't overwrite any code, only adds a new type of LibvirtVolumeDriver. I'll sponsor this on the basis that the code is self-contained and so no risk to existing libvirt features, and more importantly the cinder side has been merged for Kilo, so it would be a poor message to users if we did not merge the corresponding Nova half of the feature. 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] Feature Freeze Exception Request for Quiesce boot from volume instances
On Fri, Feb 06, 2015 at 10:20:04PM +, Tomoki Sekiyama wrote: Hello, I'd like to request a feature freeze exception for the change https://review.openstack.org/#/c/138795/ . This patch makes live volume-boot instance snapshots consistent by quiescing instances before snapshotting. Quiescing for image-boot instances are already merged in the libvirt driver, and this is a complementary part for volume-boot instances. Nikola Dipanov and Daniel Berrange actively reviewed the patch and I hope it is ready now (+1 from Nikola with a comment that he is waiting for the FFE process at this point so no +2s). Please consider approving this FFE. I'm happy to sponsor this one having given it multiple reviews You could probably even argue this feature is in fact a bug fix since it fixes the problem of inconsistent snapshots which can result in guest application data corruption in the worst case. 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] Feature Freeze Exception Request (Use libvirt storage pools)
On Fri, Feb 06, 2015 at 05:29:33PM -0500, Solly Ross wrote: Hi, I would like to request a non-priority feature freeze exception for the Use libvirt storage pools blueprint [1]. The blueprint introduces a new image backed type that uses libvirt storage pools, and is designed to supercede several of the existing image backends for Nova. Using libvirt storage pools simplifies both the maintenance of existing code and the introduction of future storage pool types (since we can support any libvirt storage pool format that supports the createXMLFrom API call). It also paves the way for potentially using the storage pool API to assist with SSH-less migration of disks (not part of this blueprint). The blueprint also provides a way to migrate disks using legacy backends to the new backend on cold migrations/resizes, reboots (soft and hard), and live block migrations. The code [2] is up and working, and is split into (hopefully) manageable chunks. Best Regards, Solly Ross [1] http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/use-libvirt-storage-pools.html [2] https://review.openstack.org/#/c/152348/ and onward P.S. I would really like to get this in, since this would be the second time that this has been deferred, and took a good bit of manual rebasing to create the Kilo version from the Juno version. Much as I'd like to see this feature in Nova, my recommendation is to reject this FFE. The image cache management code in particular has been a long term source of bugs and unexpected behaviour. While I think this series improves the code in question, the potential for causing regressions is none the less very high. An overhall of this area of code is really something that needs to get merged very early in a dev cycle (ie Kilo-1, or the start of Kilo-2) in order to allow enough opportunity to stablise it. The first posting for Kilo was only done on Jan 21, before that the previous update was Sept 7. I'm afraid this work was just far too late in Kilo to stand a reasonable chance of merging in Kilo given how complex the code in this area is. 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] Feature Freeze Exception Request for Quiesce boot from volume instances
On 02/10/2015 11:12 AM, Daniel P. Berrange wrote: On Fri, Feb 06, 2015 at 10:20:04PM +, Tomoki Sekiyama wrote: Hello, I'd like to request a feature freeze exception for the change https://review.openstack.org/#/c/138795/ . This patch makes live volume-boot instance snapshots consistent by quiescing instances before snapshotting. Quiescing for image-boot instances are already merged in the libvirt driver, and this is a complementary part for volume-boot instances. Nikola Dipanov and Daniel Berrange actively reviewed the patch and I hope it is ready now (+1 from Nikola with a comment that he is waiting for the FFE process at this point so no +2s). Please consider approving this FFE. I'm happy to sponsor this one having given it multiple reviews You could probably even argue this feature is in fact a bug fix since it fixes the problem of inconsistent snapshots which can result in guest application data corruption in the worst case. I will sponsor it too - it basically one patch that is ready to merge and has had a number of reviews. N. __ 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] Feature Freeze Exception request
Hi, I would like to request a FFE for https://review.openstack.org/#/c/134134/ It is a change that allows a driver to use type file instead of block for local volumes. It was blocked because at that time there was no use for it. Now, we have a driver merged which currently returns loca for driver_volume_type; we would like to return driver_volume_type: file (which is the correct type) which will then result (via this change) in a disk type = file in the xml being generated. Also, this changeset doesn't remove any code, doesn't overwrite any code, only adds a new type of LibvirtVolumeDriver. Thanks, Eduard -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com | eduard.ma...@cloudfounders.com *CloudFounders, The Private Cloud Software Company* Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error we request you to notify us by reply e-mail and to delete all electronic files of the message. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the content of this message, and shall have no liability for any loss or damage suffered by the user, which arise as a result of e-mail transmission. __ 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] Feature Freeze Exception request for Add the Nova libvirt StorPool attachment driver.
Hi, I'd like to request a feature freeze exception for the change: https://review.openstack.org/140733/ It's a small, self-contained driver for attaching StorPool-backed Cinder volumes to existing Nova virtual machines. It does not touch anything outside its own bailiwick (adds a new class to nova/virt/libvirt/volume.py) and is just a couple of lines of code, passing requests through to the JSON-over-HTTP StorPool API. The Cinder support for volumes created on a StorPool cluster was merged before Kilo-1, and IMVHO it would make sense to have a Nova attachment driver to actually use the Cinder support. The change was reviewed by Daniel Berrange, who posted a very reasonable suggestion for restructuring the code, which I implemented within a few days. I would be very grateful if somebody could take a look at the proposed addition and consider it for a feature freeze exception. Thanks in advance for your time, and keep up the great work! G'luck, Peter __ 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] Feature Freeze Exception Request - bp/libvirt-kvm-systemz
On Mon, Feb 09, 2015 at 05:15:26PM +0100, Andreas Maier wrote: Hello, I would like to ask for the following feature freeze exceptions in Nova. The patch sets below are all part of this blueprint: https://review.openstack.org/#/q/status:open+project:openstack/nova +branch:master+topic:bp/libvirt-kvm-systemz,n,z and affect only the kvm/libvirt driver of Nova. The decision for merging these patch sets by exception can be made one by one; they are independent of each other. 1. https://review.openstack.org/149242 - FCP support Title: libvirt: Adjust Nova to support FCP on System z systems What it does: This patch set enables FCP support for KVM on System z. Impact if we don't get this: FCP attached storage does not work for KVM on System z. Why we need it: We really depend on this particular patch set, because FCP is our most important storage attachment. Additional notes: The code in the libvirt driver that is updated by this patch set is consistent with corresponding code in the Cinder driver, and it has seen review by the Cinder team. 2. https://review.openstack.org/150505 - Console support Title: libvirt: Enable serial_console feature for system z What it does: This patch set enables the backing support in Nova for the interactive console in Horizon. Impact if we don't get this: Console in Horizon does not work. The mitigation for a user would be to use the Log in Horizon (i.e. with serial_console disabled), or the virsh console command in an ssh session to the host Linux. Why we need it: We'd like to have console support. Also, because the Nova support for the Log in Horizon has been merged in an earlier patch set as part of this blueprint, this remaining patch set makes the console/log support consistent for KVM on System z Linux. 3. https://review.openstack.org/150497 - ISO/CDROM support Title: libvirt: Set SCSI as the default cdrom bus on System z What it does: This patch set enables that cdrom drives can be attached to an instance on KVM on System z. This is needed for example for cloud-init config files, but also for simply attaching ISO images to instances. The technical reason for this change is that the IDE attachment is not available on System z, and we need SCSI (just like Power Linux). Impact if we don't get this: - Cloud-init config files cannot be on a cdrom drive. A mitigation for a user would be to have such config files on a cloud-init server. - ISO images cannot be attached to instances. There is no mitigation. Why we need it: We would like to avoid having to restrict cloud-init configuration to just using cloud-init servers. We would like to be able to support ISO images. Additional notes: This patch is a one line change (it simply extends what is already done in a platform specific case for the Power platform, to be also used for System z). I will happily sponsor exception on patches 2 3, since they are pretty trivial easily understood. I will tenatively sponsor patch 1, if other reviewers feel able to do a strong review of the SCSI stuff, since this is SCSI host setup is not something I'm particularly familiar with. 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] Feature Freeze Exception request for Add the Nova libvirt StorPool attachment driver.
On Tue, Feb 10, 2015 at 12:28:27PM +0200, Peter Penchev wrote: Hi, I'd like to request a feature freeze exception for the change: https://review.openstack.org/140733/ It's a small, self-contained driver for attaching StorPool-backed Cinder volumes to existing Nova virtual machines. It does not touch anything outside its own bailiwick (adds a new class to nova/virt/libvirt/volume.py) and is just a couple of lines of code, passing requests through to the JSON-over-HTTP StorPool API. The Cinder support for volumes created on a StorPool cluster was merged before Kilo-1, and IMVHO it would make sense to have a Nova attachment driver to actually use the Cinder support. The change was reviewed by Daniel Berrange, who posted a very reasonable suggestion for restructuring the code, which I implemented within a few days. I would be very grateful if somebody could take a look at the proposed addition and consider it for a feature freeze exception. Thanks in advance for your time, and keep up the great work! The Feature Freeze Exception process is for approving the merge of changes whose specs/blueprints are already approved. Unfortunately, IIUC, your blueprint is not approved, so it is not possible to request a FFE for merging the changes in question. The deadline for requesting Spec/Blueprint Freeze Exceptions has passed quite a while ago now. 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] Feature Freeze Exception request for Add the Nova libvirt StorPool attachment driver.
On Tue, Feb 10, 2015 at 12:34 PM, Daniel P. Berrange berra...@redhat.com wrote: On Tue, Feb 10, 2015 at 12:28:27PM +0200, Peter Penchev wrote: Hi, I'd like to request a feature freeze exception for the change: https://review.openstack.org/140733/ It's a small, self-contained driver for attaching StorPool-backed Cinder volumes to existing Nova virtual machines. It does not touch anything outside its own bailiwick (adds a new class to nova/virt/libvirt/volume.py) and is just a couple of lines of code, passing requests through to the JSON-over-HTTP StorPool API. The Cinder support for volumes created on a StorPool cluster was merged before Kilo-1, and IMVHO it would make sense to have a Nova attachment driver to actually use the Cinder support. The change was reviewed by Daniel Berrange, who posted a very reasonable suggestion for restructuring the code, which I implemented within a few days. I would be very grateful if somebody could take a look at the proposed addition and consider it for a feature freeze exception. Thanks in advance for your time, and keep up the great work! The Feature Freeze Exception process is for approving the merge of changes whose specs/blueprints are already approved. Unfortunately, IIUC, your blueprint is not approved, so it is not possible to request a FFE for merging the changes in question. The deadline for requesting Spec/Blueprint Freeze Exceptions has passed quite a while ago now. Hi, Actually, the blueprint was approved quite some time ago, and it also has a favorable comment by John Garbutt from January 26th (two days after I submitted the updated change addressing your concerns). Then on February 5th Thierry Carrez changed its status to Pending approval with a comment stating that it missed the non-priority feature freeze deadline (I think that the johnthetubaguy attribution at the end of the comment is more of a copy/paste error, since the change indeed seems to have been done by Thierry Carrez). G'luck, Peter __ 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] Feature Freeze Exception Request - bp/libvirt-kvm-systemz
On 2/9/2015 10:15 AM, Andreas Maier wrote: Hello, I would like to ask for the following feature freeze exceptions in Nova. The patch sets below are all part of this blueprint: https://review.openstack.org/#/q/status:open+project:openstack/nova +branch:master+topic:bp/libvirt-kvm-systemz,n,z and affect only the kvm/libvirt driver of Nova. The decision for merging these patch sets by exception can be made one by one; they are independent of each other. 1. https://review.openstack.org/149242 - FCP support Title: libvirt: Adjust Nova to support FCP on System z systems What it does: This patch set enables FCP support for KVM on System z. Impact if we don't get this: FCP attached storage does not work for KVM on System z. Why we need it: We really depend on this particular patch set, because FCP is our most important storage attachment. Additional notes: The code in the libvirt driver that is updated by this patch set is consistent with corresponding code in the Cinder driver, and it has seen review by the Cinder team. 2. https://review.openstack.org/150505 - Console support Title: libvirt: Enable serial_console feature for system z What it does: This patch set enables the backing support in Nova for the interactive console in Horizon. Impact if we don't get this: Console in Horizon does not work. The mitigation for a user would be to use the Log in Horizon (i.e. with serial_console disabled), or the virsh console command in an ssh session to the host Linux. Why we need it: We'd like to have console support. Also, because the Nova support for the Log in Horizon has been merged in an earlier patch set as part of this blueprint, this remaining patch set makes the console/log support consistent for KVM on System z Linux. 3. https://review.openstack.org/150497 - ISO/CDROM support Title: libvirt: Set SCSI as the default cdrom bus on System z What it does: This patch set enables that cdrom drives can be attached to an instance on KVM on System z. This is needed for example for cloud-init config files, but also for simply attaching ISO images to instances. The technical reason for this change is that the IDE attachment is not available on System z, and we need SCSI (just like Power Linux). Impact if we don't get this: - Cloud-init config files cannot be on a cdrom drive. A mitigation for a user would be to have such config files on a cloud-init server. - ISO images cannot be attached to instances. There is no mitigation. Why we need it: We would like to avoid having to restrict cloud-init configuration to just using cloud-init servers. We would like to be able to support ISO images. Additional notes: This patch is a one line change (it simply extends what is already done in a platform specific case for the Power platform, to be also used for System z). Andy Andreas Maier IBM Senior Technical Staff Member, Systems Management Architecture Design IBM Research Development Laboratory Boeblingen, Germany mai...@de.ibm.com, +49-7031-16-3654 IBM Deutschland Research Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschaeftsfuehrung: Dirk Wittkopp Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 __ 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 FWIW, I'll sponsor these changes. I'm already +2 on one and have reviewed the other two which are very close to a +2 from me, just need a little more work (but not drastic changes). -- 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-dev] [nova] Feature Freeze Exception Request - bp/libvirt-kvm-systemz
Hello, I would like to ask for the following feature freeze exceptions in Nova. The patch sets below are all part of this blueprint: https://review.openstack.org/#/q/status:open+project:openstack/nova +branch:master+topic:bp/libvirt-kvm-systemz,n,z and affect only the kvm/libvirt driver of Nova. The decision for merging these patch sets by exception can be made one by one; they are independent of each other. 1. https://review.openstack.org/149242 - FCP support Title: libvirt: Adjust Nova to support FCP on System z systems What it does: This patch set enables FCP support for KVM on System z. Impact if we don't get this: FCP attached storage does not work for KVM on System z. Why we need it: We really depend on this particular patch set, because FCP is our most important storage attachment. Additional notes: The code in the libvirt driver that is updated by this patch set is consistent with corresponding code in the Cinder driver, and it has seen review by the Cinder team. 2. https://review.openstack.org/150505 - Console support Title: libvirt: Enable serial_console feature for system z What it does: This patch set enables the backing support in Nova for the interactive console in Horizon. Impact if we don't get this: Console in Horizon does not work. The mitigation for a user would be to use the Log in Horizon (i.e. with serial_console disabled), or the virsh console command in an ssh session to the host Linux. Why we need it: We'd like to have console support. Also, because the Nova support for the Log in Horizon has been merged in an earlier patch set as part of this blueprint, this remaining patch set makes the console/log support consistent for KVM on System z Linux. 3. https://review.openstack.org/150497 - ISO/CDROM support Title: libvirt: Set SCSI as the default cdrom bus on System z What it does: This patch set enables that cdrom drives can be attached to an instance on KVM on System z. This is needed for example for cloud-init config files, but also for simply attaching ISO images to instances. The technical reason for this change is that the IDE attachment is not available on System z, and we need SCSI (just like Power Linux). Impact if we don't get this: - Cloud-init config files cannot be on a cdrom drive. A mitigation for a user would be to have such config files on a cloud-init server. - ISO images cannot be attached to instances. There is no mitigation. Why we need it: We would like to avoid having to restrict cloud-init configuration to just using cloud-init servers. We would like to be able to support ISO images. Additional notes: This patch is a one line change (it simply extends what is already done in a platform specific case for the Power platform, to be also used for System z). Andy Andreas Maier IBM Senior Technical Staff Member, Systems Management Architecture Design IBM Research Development Laboratory Boeblingen, Germany mai...@de.ibm.com, +49-7031-16-3654 IBM Deutschland Research Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschaeftsfuehrung: Dirk Wittkopp Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 __ 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] Feature Freeze Exception Request (libvirt vhostuser vif driver)
Hi, I would like to request FFE for vhostuser vif driver. 2 reviews : https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/libvirt-vif-vhost-user,n,z BP: https://blueprints.launchpad.net/nova/+spec/libvirt-vif-vhost-user Spec: https://review.openstack.org/138736 Blueprint was approved but it's status was changed because of FF. Vhostuser is a Qemu feature that allows fastpath into the VM for userspace vSwitches. The changes are small and mostly contained to libvirt driver. Vhostuser support was proposed for Juno by Snabb switch guys but didn't make it, this implementation supports their usecase as well . Thanks Przemek __ 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] Feature Freeze Exception Request
Hi all, I’d like to ask a FFE for the Hyper-V Rescue feature Patch: https://review.openstack.org/#/c/127159/ Blueprint: https://blueprints.launchpad.net/nova/+spec/hyper-v-rescue It’s a feature parity blueprint with no impact outside of the Hyper-V driver. It already received a +2 (currently lost through the usual various rebases). The blueprint priority was set to medium before the K-2 freeze. Drivers have been heavily penalized by the Juno and Kilo release cycle prioritization. It’d be great if we could have at least this feature parity patch released upstream, considering that the majority of this cycle's Hyper-V blueprints, already fully implemented, will be postponend to L. Thanks, Alessandro __ 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] Feature Freeze Exception Request for Quiesce boot from volume instances
Hello, I'd like to request a feature freeze exception for the change https://review.openstack.org/#/c/138795/ . This patch makes live volume-boot instance snapshots consistent by quiescing instances before snapshotting. Quiescing for image-boot instances are already merged in the libvirt driver, and this is a complementary part for volume-boot instances. Nikola Dipanov and Daniel Berrange actively reviewed the patch and I hope it is ready now (+1 from Nikola with a comment that he is waiting for the FFE process at this point so no +2s). Please consider approving this FFE. Best regards, Tomoki Sekiyama __ 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] Feature Freeze Exception Request (Use libvirt storage pools)
Hi, I would like to request a non-priority feature freeze exception for the Use libvirt storage pools blueprint [1]. The blueprint introduces a new image backed type that uses libvirt storage pools, and is designed to supercede several of the existing image backends for Nova. Using libvirt storage pools simplifies both the maintenance of existing code and the introduction of future storage pool types (since we can support any libvirt storage pool format that supports the createXMLFrom API call). It also paves the way for potentially using the storage pool API to assist with SSH-less migration of disks (not part of this blueprint). The blueprint also provides a way to migrate disks using legacy backends to the new backend on cold migrations/resizes, reboots (soft and hard), and live block migrations. The code [2] is up and working, and is split into (hopefully) manageable chunks. Best Regards, Solly Ross [1] http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/use-libvirt-storage-pools.html [2] https://review.openstack.org/#/c/152348/ and onward P.S. I would really like to get this in, since this would be the second time that this has been deferred, and took a good bit of manual rebasing to create the Kilo version from the Juno version. __ 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] Feature Freeze Exception Request
Hi, I would like to request a feature freeze exception for the Websockify security proxy framework blueprint [1]. The blueprint introduces a framework for defining security drivers for the connections between the websocket proxy and the hypervisor, and provides a TLS driver for VNC connections using the VeNCrypt RFB auth method. The two patches [2] have sat in place with one +2 (Dan Berrange) and multiple +1s for a while now (the first does not currently show any votes because of a merge conflict that I had to deal with recently). Best Regards, Solly Ross [1] http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/websocket-proxy-to-host-security.html [2] https://review.openstack.org/#/c/115483/ and https://review.openstack.org/#/c/115484/ __ 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] Feature Freeze Exception Request
On 2/6/2015 7:28 AM, Silvan Kaiser wrote: Hello! I am requesting a feature freeze exception for Kilo-2 milestone regarding https://review.openstack.org/#/c/110722/ . This change adds support for using the Quobyte Storage system for provisioning images in Nova. It works in conjunction with the Quobyte driver in Cinder (which was merged at Kilo-1). Refraining from merging would mean delay until L release, all the while having a largely useless Driver in Cinder. Jay Pipes, Matt Riedemann and Daniel Berrange kindly declared sponsorship for this FFE. Daniel didn't actually say he'd sponsor this, I said in the review that I *thought* he might be a possible third sponsor if it came to that. :) I did say I'd sponsor this though. It's close but had enough comments from me that I thought it warranted a -1 in it's current form. I realize this isn't a priority blueprint though and it's up to the nova-drivers team to decide on it, but FWIW it's self-contained for the most part and has been sitting around for a long time and I feel that lack of reviews shouldn't punish it in that regard (hopefully this doesn't open up a ton of other my thing has been around forever without reviews too so give me an exception also kind of precedent thing, not my intention). Please feel free to contact me regarding further FFE procedure or if there are any more questions (sil...@quobyte.com mailto:sil...@quobyte.com, kaisers/casusbelli in irc). Best regards Silvan Kaiser -- *Quobyte* GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800 - www.quobyte.com http://www.quobyte.com/ Amtsgericht Berlin-Charlottenburg, HRB 149012B management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender __ 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 -- 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] Feature Freeze Exception Request
On Fri, Feb 06, 2015 at 09:55:42AM -0600, Matt Riedemann wrote: On 2/6/2015 7:28 AM, Silvan Kaiser wrote: Hello! I am requesting a feature freeze exception for Kilo-2 milestone regarding https://review.openstack.org/#/c/110722/ . This change adds support for using the Quobyte Storage system for provisioning images in Nova. It works in conjunction with the Quobyte driver in Cinder (which was merged at Kilo-1). Refraining from merging would mean delay until L release, all the while having a largely useless Driver in Cinder. Jay Pipes, Matt Riedemann and Daniel Berrange kindly declared sponsorship for this FFE. Daniel didn't actually say he'd sponsor this, I said in the review that I *thought* he might be a possible third sponsor if it came to that. :) Actually Silvan asked me in a private email just before this one and I agreed. I realize this isn't a priority blueprint though and it's up to the nova-drivers team to decide on it, but FWIW it's self-contained for the most part and has been sitting around for a long time and I feel that lack of reviews shouldn't punish it in that regard (hopefully this doesn't open up a ton of other my thing has been around forever without reviews too so give me an exception also kind of precedent thing, not my intention). Personally I'm fine as it is self-contained and would have merged already if you hadn't added some small -1s at the last minute ;-P 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] Feature Freeze Exception Request
On 02/06/2015 08:28 AM, Silvan Kaiser wrote: Hello! I am requesting a feature freeze exception for Kilo-2 milestone regarding https://review.openstack.org/#/c/110722/ . This change adds support for using the Quobyte Storage system for provisioning images in Nova. It works in conjunction with the Quobyte driver in Cinder (which was merged at Kilo-1). Refraining from merging would mean delay until L release, all the while having a largely useless Driver in Cinder. Jay Pipes, Matt Riedemann and Daniel Berrange kindly declared sponsorship for this FFE. Please feel free to contact me regarding further FFE procedure or if there are any more questions (sil...@quobyte.com mailto:sil...@quobyte.com, kaisers/casusbelli in irc). Ack'd. I will sponsor this. Patch is smallish, well-defined, and complete. -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
[openstack-dev] [nova] Feature Freeze Exception Request
Hello! I am requesting a feature freeze exception for Kilo-2 milestone regarding https://review.openstack.org/#/c/110722/ . This change adds support for using the Quobyte Storage system for provisioning images in Nova. It works in conjunction with the Quobyte driver in Cinder (which was merged at Kilo-1). Refraining from merging would mean delay until L release, all the while having a largely useless Driver in Cinder. Jay Pipes, Matt Riedemann and Daniel Berrange kindly declared sponsorship for this FFE. Please feel free to contact me regarding further FFE procedure or if there are any more questions (sil...@quobyte.com, kaisers/casusbelli in irc). Best regards Silvan Kaiser -- -- *Quobyte* GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800 - www.quobyte.com Amtsgericht Berlin-Charlottenburg, HRB 149012B management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender __ 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] Feature Freeze Exception Request
Of course i asked Daniel directly prior to publicly declaring him a sponsor!!! :-) 2015-02-06 16:55 GMT+01:00 Matt Riedemann mrie...@linux.vnet.ibm.com: On 2/6/2015 7:28 AM, Silvan Kaiser wrote: Hello! I am requesting a feature freeze exception for Kilo-2 milestone regarding https://review.openstack.org/#/c/110722/ . This change adds support for using the Quobyte Storage system for provisioning images in Nova. It works in conjunction with the Quobyte driver in Cinder (which was merged at Kilo-1). Refraining from merging would mean delay until L release, all the while having a largely useless Driver in Cinder. Jay Pipes, Matt Riedemann and Daniel Berrange kindly declared sponsorship for this FFE. Daniel didn't actually say he'd sponsor this, I said in the review that I *thought* he might be a possible third sponsor if it came to that. :) I did say I'd sponsor this though. It's close but had enough comments from me that I thought it warranted a -1 in it's current form. I realize this isn't a priority blueprint though and it's up to the nova-drivers team to decide on it, but FWIW it's self-contained for the most part and has been sitting around for a long time and I feel that lack of reviews shouldn't punish it in that regard (hopefully this doesn't open up a ton of other my thing has been around forever without reviews too so give me an exception also kind of precedent thing, not my intention). Please feel free to contact me regarding further FFE procedure or if there are any more questions (sil...@quobyte.com mailto:sil...@quobyte.com, kaisers/casusbelli in irc). Best regards Silvan Kaiser -- *Quobyte* GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800 - www.quobyte.com http://www.quobyte.com/ Amtsgericht Berlin-Charlottenburg, HRB 149012B management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender __ 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 -- 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 -- -- *Quobyte* GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800 - www.quobyte.com Amtsgericht Berlin-Charlottenburg, HRB 149012B management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender __ 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