[openstack-dev] [nova] Feature Freeze Exception Request

2015-08-03 Thread Sajeesh Cimson Sasi
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

2015-02-17 Thread Marco Pavone
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

2015-02-16 Thread Matt Riedemann



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)

2015-02-16 Thread Nikola Đipanov
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)

2015-02-16 Thread Nikola Đipanov
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

2015-02-12 Thread Christopher Yeoh
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 Thread Ken'ichi Ohmichi
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)

2015-02-12 Thread Daniel P. Berrange
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

2015-02-12 Thread Alex Xu
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

2015-02-12 Thread Claudiu Belu

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

2015-02-11 Thread Sajeesh Cimson Sasi
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

2015-02-11 Thread Lin Hua Cheng
+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)

2015-02-11 Thread Nikola Đipanov
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

2015-02-10 Thread Daniel P. Berrange
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.

2015-02-10 Thread Daniel P. Berrange
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

2015-02-10 Thread Daniel P. Berrange
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

2015-02-10 Thread Daniel P. Berrange
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)

2015-02-10 Thread Daniel P. Berrange
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

2015-02-10 Thread Nikola Đipanov
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

2015-02-10 Thread Eduard Matei
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.

2015-02-10 Thread Peter Penchev
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

2015-02-10 Thread Daniel P. Berrange
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.

2015-02-10 Thread Daniel P. Berrange
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.

2015-02-10 Thread Peter Penchev
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

2015-02-09 Thread Matt Riedemann



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

2015-02-09 Thread Andreas Maier

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)

2015-02-09 Thread Czesnowicz, Przemyslaw
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

2015-02-06 Thread Alessandro Pilotti
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

2015-02-06 Thread Tomoki Sekiyama
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)

2015-02-06 Thread Solly Ross
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

2015-02-06 Thread Solly Ross
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

2015-02-06 Thread Matt Riedemann



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

2015-02-06 Thread Daniel P. Berrange
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

2015-02-06 Thread Jay Pipes

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

2015-02-06 Thread Silvan Kaiser
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

2015-02-06 Thread Silvan Kaiser
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