Re: [openstack-dev] question of vcpu-memory-hotplug progress

2014-01-18 Thread Wangshen (Peter)
-Original Message- From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] Sent: Friday, January 17, 2014 1:01 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Jinbo (Justin) Subject: Re: [openstack-dev] question of vcpu-memory-hotplug progress Can you

Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra

2014-01-18 Thread Andrew Hutchings
On 17 Jan 2014, at 19:53, Jay Pipes jaypi...@gmail.com wrote: On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote: On 17 Jan 2014, at 16:10, Jay Pipes jaypi...@gmail.com wrote: On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote: Hi all, I've been looking at Neutron default

Re: [openstack-dev] [qa] [Tempest - Stress Test] : implement a full SSH connection on ssh_floating.py and improve it

2014-01-18 Thread Koderer, Marc
Hello Julien, maybe my blog post helps you with some more details: http://telekomcloud.github.io/2013/09/11/new-ways-of-tempest-stress-testing.html You can run single test if you add a new json file with the test function you want to test. Like:

Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra

2014-01-18 Thread Andrew Hutchings
Hi, I haven’t read through those (need to go spend time with family so replying quickly) but given the dates the planning phases for Quantum/Neutron LBaaS and Libra LBaaS were at the same time. There was an internal evaluation of the current LBaaS solutions done at the time and it was

Re: [openstack-dev] a common client library

2014-01-18 Thread Doug Hellmann
On Fri, Jan 17, 2014 at 11:03 PM, John Utz john@wdc.com wrote: Outlook Web MUA, forgive the top post. :-( While a single import line that brings all the good stuff in at one shot is very convenient for the creation of an application, it would muddy the security picture *substantially*

Re: [openstack-dev] a common client library

2014-01-18 Thread Doug Hellmann
I like the idea of a fresh start, but I don't think that's incompatible with the other work to clean up the existing clients. That cleanup work could help with creating the backwards compatibility layer, if a new library needs to include one, for example. As far as namespace packages and separate

Re: [openstack-dev] a common client library

2014-01-18 Thread Jesse Noller
On Jan 17, 2014, at 10:03 PM, John Utz john@wdc.com wrote: Outlook Web MUA, forgive the top post. :-( While a single import line that brings all the good stuff in at one shot is very convenient for the creation of an application, it would muddy the security picture *substantially*

Re: [openstack-dev] a common client library

2014-01-18 Thread Jesse Noller
On Jan 18, 2014, at 8:13 AM, Doug Hellmann doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com wrote: I like the idea of a fresh start, but I don't think that's incompatible with the other work to clean up the existing clients. That cleanup work could help with creating the

Re: [openstack-dev] a common client library

2014-01-18 Thread Jesse Noller
On Jan 18, 2014, at 12:00 AM, Jamie Lennox jamielen...@redhat.com wrote: I can't see any reason that all of these situations can't be met. We can finally take the openstack pypi namespace, move keystoneclient - openstack.keystone and similar for the other projects. Have them all based

Re: [openstack-dev] a common client library

2014-01-18 Thread Sean Dague
On 01/18/2014 01:06 AM, Robert Collins wrote: On 17 January 2014 09:22, Renat Akhmerov rakhme...@mirantis.com wrote: Since it’s pretty easy to get lost among all the opinions I’d like to clarify/ask a couple of things: Keeping all the clients physically separate/combining them in to a single

Re: [openstack-dev] [Diesel] Proposal for new project

2014-01-18 Thread Adrian Otto
Rob, Please contact me, You have completely misunderstood the Solum project. Thanks, Adrian On Jan 17, 2014, at 9:31 PM, Raymond, Rob rob.raym...@hp.com wrote: Hi Raj As I see it, Solum is a set of utilities aimed at developers to use OpenStack clouds but will not be part of OpenStack

Re: [openstack-dev] a common client library

2014-01-18 Thread Donald Stufft
On Jan 18, 2014, at 12:58 AM, Robert Collins robe...@robertcollins.net wrote: Out of interest - whats the overhead of running tls compression against compressed data? Is it really noticable? The overhead doesn’t really matter much as you want TLS Compression disabled because of CRIME anyways.

Re: [openstack-dev] a common client library

2014-01-18 Thread Donald Stufft
On Jan 18, 2014, at 9:58 AM, Jesse Noller jesse.nol...@rackspace.com wrote: On Jan 18, 2014, at 12:00 AM, Jamie Lennox jamielen...@redhat.com wrote: I can't see any reason that all of these situations can't be met. We can finally take the openstack pypi namespace, move keystoneclient -

Re: [openstack-dev] [Diesel] Proposal for new project

2014-01-18 Thread Jay Pipes
On Sat, 2014-01-18 at 03:31 +, Raymond, Rob wrote: I would like to gauge interest in a new project named Diesel. https://wiki.openstack.org/wiki/Diesel If you are already familiar with Savanna, the best way to describe it is: Savanna is to map reduce applications as Diesel is to web

Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra

2014-01-18 Thread Jay Pipes
On Sat, 2014-01-18 at 09:06 +, Andrew Hutchings wrote: On 17 Jan 2014, at 19:53, Jay Pipes jaypi...@gmail.com wrote: On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote: On 17 Jan 2014, at 16:10, Jay Pipes jaypi...@gmail.com wrote: On Fri, 2014-01-17 at 14:34 +0100,

Re: [openstack-dev] [keystone] domain admin role query

2014-01-18 Thread Florent Flament
Hi, Following-up on this thread (although late), I have detailed the steps allowing to have Keystone with multiple domains properly set: http://www.florentflament.com/blog/setting-keystone-v3-domains.html I hope that it may be useful for people willing to play with the Identity v3 API and

Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra

2014-01-18 Thread Jay Pipes
On Fri, 2014-01-17 at 13:12 -0800, Alex Freedland wrote: Andrew, Jay and all, Thank you for bringing this topic up. Incidentally, just a month ago at OpenStack Israel I spoke to Monty and other HP folks about getting the Libra initiatives integrated into LBaaS. I am happy that this

Re: [openstack-dev] [ironic] Disk Eraser

2014-01-18 Thread Pádraig Brady
On 01/15/2014 02:42 PM, Alexei Kornienko wrote: If you are working on linux system following can help you: dd if=/dev/urandom of=/dev/sda bs=4k That's going to be slow. The shred tool should be already installed on most Linux systems, and uses an internal PRNG to write either zeros or random

Re: [openstack-dev] a common client library

2014-01-18 Thread Robert Collins
On 19 January 2014 04:48, Sean Dague s...@dague.net wrote: On 01/18/2014 01:06 AM, Robert Collins wrote: Launchpadlib which builds on wadllib did *exactly* that. It worked fairly well with the one caveat that it fell into the ORM trap - just in time lookups for everything with crippling

Re: [openstack-dev] [rally] Naming of a deployment

2014-01-18 Thread Yuriy Taraday
Hi all. I might be a little out of context, but isn't that thing deployed on some kind of cloud? * cluster -- is too generic, but also has connotations in HPC and various other technologies (databases, MQs, etc). * installation -- reminds me of a piece of performance art ;) * instance --

Re: [openstack-dev] [Neutron] Relationship between Neutron LBaaS and Libra

2014-01-18 Thread Clint Byrum
Excerpts from Jay Pipes's message of 2014-01-18 11:02:12 -0800: Cutting to the chase... have there been any discussions about the long-term direction of Libra and Neutron LBaaS. I see little point having two OpenStack endpoints that implement the same basic load balancing functionality. Is

Re: [openstack-dev] [wsme] Undefined attributes in WSME

2014-01-18 Thread Yuriy Taraday
On Tue, Jan 14, 2014 at 6:09 PM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Mon, Jan 13, 2014 at 9:36 PM, Jamie Lennox jamielen...@redhat.comwrote: On Mon, 2014-01-13 at 10:05 -0500, Doug Hellmann wrote: What requirement(s) led to keystone supporting this feature? I've got no idea

[openstack-dev] [wsme] Undefined attributes in WSME

2014-01-18 Thread Morgan Fainberg
Yes, this feature is used in real deployments just as Yuriy described. I really want to avoid a new API version since we're just now getting solidly into V3 being used more extensively. Is it unreasonable to have wsme allow extra values in some manner? (I think that is the crux, is it something

[openstack-dev] [savanna] paramiko requirement of = 1.9.0?

2014-01-18 Thread Matthew Farrellee
jon, please confirm a suspicion of mine. the neutron-private-net-provisioning bp impl added a sock= parameter to the ssh.connect call in remote.py (https://github.com/openstack/savanna/commit/9afb5f60). we currently require paramiko = 1.8.0, but it looks like the sock param was only added

Re: [openstack-dev] [qa][Neutron][Tempest][Network] Break down NetworkBasicOps to smaller test cases

2014-01-18 Thread Yair Fried
MT:Is your issue here that it's just called basic ops and you don't think that's reflective of what is being tested in that file anymore No. My issue is, that the current scenario is, in fact, at least 2 separate scenarios: 1. original basic_ops 2. reassociate_floating_ip to which I would like

Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

2014-01-18 Thread Irena Berezovsky
Hi Robert, Yonhong, Although network XML solution (option 1) is very elegant, it has one major disadvantage. As Robert mentioned, the disadvantage of the network XML is the inability to know what SR-IOV PCI device was actually allocated. When neutron is responsible to set networking

Re: [openstack-dev] [rally] Naming of a deployment

2014-01-18 Thread Oleg Gelbukh
Yuriy, the idea is to choose something more or less general. 'Overcloud' would be very specific to my taste. It could also create confusion for users who want to depoy tests targets with other tools, like Fuel or Devstack. -- Best regards, Oleg Gelbukh On Sun, Jan 19, 2014 at 1:17 AM, Yuriy