Re: [openstack-dev] [Heat] Multi region support for Heat

2013-07-24 Thread Clint Byrum
Excerpts from Adrian Otto's message of 2013-07-23 21:22:14 -0700: Clint, On Jul 23, 2013, at 10:03 AM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Steve Baker's message of 2013-07-22 21:43:05 -0700: On 07/23/2013 10:46 AM, Angus Salkeld wrote: On 22/07/13 16:52 +0200, Bartosz

[openstack-dev] Validating Flavor IDs

2013-07-24 Thread Karajgi, Rohit
Hi, Referring to https://bugs.launchpad.net/nova/+bug/1202136, it seems that the novaclient validates the flavor ID to be either an integer or a UUID string. This check does not exist in Nova, so currently strings are also accepted as flavor IDs by Nova when direct restful API calls are made.

[openstack-dev] [savanna] use openstack-dev mailing list

2013-07-24 Thread Sergey Lukjanov
Hi folks, We decided to use openstack-dev@lists.openstack.org mailing list instead of savanna-...@lists.launchpad.net for all savanna-related communication. The old one will be closed and we’ll monitor it and forward all emails from it to the correct mailing list. Additionally it means that

Re: [openstack-dev] [Nova] support for multiple active scheduler policies/drivers

2013-07-24 Thread Day, Phil
Hi Alex, I'm inclined to agree with others that I'm not sure you need the complexity that this BP brings to the system.If you want to provide a user with a choice about how much overcommit they will be exposed to then doing that in flavours and the aggregate_instance_extra_spec filter

Re: [openstack-dev] [Swift] Swift Auth systems and Delay Denial

2013-07-24 Thread David Hadas
Clay, It sounds like a bad idea to remove delay_denial support (at least in the near term). Authorizing up front seem to have certain advantages: 1. Flexibility - as it allows authenticating based on any attribute returned from the get_info() (without changes to Swift). 2. Security - a single

Re: [openstack-dev] [barbican]

2013-07-24 Thread Jarret Raim
It seems KMIP is getting lots of enterprise attention, so I think it may be good candidate for future (as you already mentioned in your email below) Barbican feature, as per the link below it seems our community also expects KMIP to be integrated with OpenStack line of products.

Re: [openstack-dev] KMIP client for volume encryption key management

2013-07-24 Thread Jarret Raim
· Agreed that there isn¹t an existing KMIP client in python. We are offering to port the needed functionality from our current java KMIP client to python and contribute it to openstack. Are you taking about porting to Python or having python call a Java wrapper? · Good points about the common

Re: [openstack-dev] [keystone] Extending policy checking to include target entities

2013-07-24 Thread Henry Nash
I think we should transfer this discussion to the etherpad for this blueprint: https://etherpad.openstack.org/api_policy_on_target I have summarised the views of this thread there already, so let's make any further comments there, rather than here. Henry On 24 Jul 2013, at 00:29, Simo Sorce

[openstack-dev] Quick README? (Re: [vmware] VMwareAPI sub-team status update 2013-07-22)

2013-07-24 Thread Davanum Srinivas
Shawn, or others involved in this effort, Is there a quick README or equivalent on how to use the latest code say with devstack and vCenter to get a simple deploy working? thanks, -- dims On Mon, Jul 22, 2013 at 9:15 PM, Shawn Hartsock hartso...@vmware.com wrote: ** No meeting this week **

Re: [openstack-dev] Discussing Amazon API compatibility [Nova][Swift]

2013-07-24 Thread Monty Taylor
On 07/24/2013 08:51 AM, Stefano Maffulli wrote: Hello I have seen lots of discussions on blogs and twitter heating up around Amazon API compatibility and OpenStack. This seems like a recurring topic, often raised by pundits and recently joined by members of the community. I think it's

Re: [openstack-dev] Python 3

2013-07-24 Thread Monty Taylor
On 07/23/2013 03:02 PM, Brian Curtin wrote: On Jul 23, 2013, at 3:51 PM, Eric Windisch e...@cloudscaling.com mailto:e...@cloudscaling.com wrote: On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton lo...@bacoosta.com mailto:lo...@bacoosta.com wrote: I'm sure this has been asked

Re: [openstack-dev] [Nova] support for multiple active scheduler policies/drivers

2013-07-24 Thread Russell Bryant
On 07/24/2013 05:39 AM, Day, Phil wrote: Hi Alex, I'm inclined to agree with others that I'm not sure you need the complexity that this BP brings to the system.If you want to provide a user with a choice about how much overcommit they will be exposed to then doing that in flavours

Re: [openstack-dev] [savanna] use openstack-dev mailing list

2013-07-24 Thread Russell Bryant
On 07/24/2013 04:49 AM, Sergey Lukjanov wrote: Hi folks, We decided to use openstack-dev@lists.openstack.org mailing list instead of savanna-...@lists.launchpad.net for all savanna-related communication. The old one will be closed and we’ll monitor it and forward all emails from it to

Re: [openstack-dev] Discussing Amazon API compatibility [Nova][Swift]

2013-07-24 Thread Russell Bryant
On 07/24/2013 11:57 AM, Monty Taylor wrote: On 07/24/2013 08:51 AM, Stefano Maffulli wrote: Hello I have seen lots of discussions on blogs and twitter heating up around Amazon API compatibility and OpenStack. This seems like a recurring topic, often raised by pundits and recently joined

[openstack-dev] [Oslo] Blocker for API translation changes

2013-07-24 Thread Luis A. Garcia
Hi Oslos, I have a refactoring for common code needed to implement REST API translations. The change is a bit of a blocker for multiple other changes across various components, and would just like to see if it could get bumped up a bit in your review queues.

Re: [openstack-dev] A simple way to improve nova scheduler

2013-07-24 Thread Russell Bryant
On 07/23/2013 06:00 PM, Clint Byrum wrote: This is really interesting work, thanks for sharing it with us. The discussion that has followed has brought up some thoughts I've had for a while about this choke point in what is supposed to be an extremely scalable cloud platform (OpenStack). I

Re: [openstack-dev] Python 3

2013-07-24 Thread Alex Gaynor
I believe Red Hat's new Software Collections things address this issue, this is to the point which Django (which has historically used RHEL as a barometer for when we could drop Pythons) will drop 2.6 in our next release. Alex On Wed, Jul 24, 2013 at 9:00 AM, Monty Taylor mord...@inaugust.com

Re: [openstack-dev] Julien Danjou and Ben Nemec now on oslo-core

2013-07-24 Thread Davanum Srinivas
Welcome Ben and Julien! On Wed, Jul 24, 2013 at 11:42 AM, Mark McLoughlin mar...@redhat.com wrote: Hey I just wanted to welcome Ben and Julien to oslo-core. They have both been doing a lot of high quality reviews lately and it's much appreciated. Welcome to the team! Cheers, Mark.

Re: [openstack-dev] Quick README? (Re: [vmware] VMwareAPI sub-team status update 2013-07-22)

2013-07-24 Thread Dan Wendlandt
If you are a developer using devstack, see: https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide If you are a user deploying from packages, see: http://docs.openstack.org/trunk/openstack-compute/admin/content/vmware.html Dan On Wed, Jul 24, 2013 at 8:22 AM, Davanum Srinivas

Re: [openstack-dev] [nova] [baremetal] Mixed bare-metal + hypervisor cloud using grizzly

2013-07-24 Thread Clint Byrum
First off, welcome! :) FYI, this is the development mailing list. Questions like the one below may find more helpful answers on the general OpenStack users' mailing list. I have CC'd that list so that this response can be seen there, too, I suggest you re-send your original message there as well.

Re: [openstack-dev] Quick README? (Re: [vmware] VMwareAPI sub-team status update 2013-07-22)

2013-07-24 Thread Shawn Hartsock
I am trying to put everything here for now: https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide Let me know if you need more. # Shawn Hartsock Davanum Srinivas dava...@gmail.com wrote: Shawn, or others involved in this effort, Is there a quick README or equivalent on how to use the

Re: [openstack-dev] Quick README? (Re: [vmware] VMwareAPI sub-team status update 2013-07-22)

2013-07-24 Thread Davanum Srinivas
Thanks Dan and Shawn. Those links are exactly what i was needed. -- dims On Wed, Jul 24, 2013 at 1:10 PM, Shawn Hartsock hartso...@vmware.com wrote: I am trying to put everything here for now: https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide Let me know if you need more. # Shawn

Re: [openstack-dev] Python 3

2013-07-24 Thread Mark McLoughlin
On Wed, 2013-07-24 at 09:31 -0700, Alex Gaynor wrote: I believe Red Hat's new Software Collections things address this issue, this is to the point which Django (which has historically used RHEL as a barometer for when we could drop Pythons) will drop 2.6 in our next release. Yep, that's a very

Re: [openstack-dev] Discussing Amazon API compatibility [Nova][Swift]

2013-07-24 Thread Mark McLoughlin
On Wed, 2013-07-24 at 08:51 -0700, Stefano Maffulli wrote: Hello I have seen lots of discussions on blogs and twitter heating up around Amazon API compatibility and OpenStack. This seems like a recurring topic, often raised by pundits and recently joined by members of the community. I think

Re: [openstack-dev] Discussing Amazon API compatibility [Nova][Swift]

2013-07-24 Thread Chmouel Boudjnah
On Wed, Jul 24, 2013 at 8:51 AM, Stefano Maffulli stef...@openstack.org wrote: Do you think OpenStack should have an ongoing effort to imitate Amazon's API? If you think it should, how would you lead the effort? We (Swift) moved the S3 compatibiliy middleware out of core swift for quite some in

Re: [openstack-dev] Discussing Amazon API compatibility [Nova][Swift]

2013-07-24 Thread Sean Dague
On 07/24/2013 01:43 PM, Mark McLoughlin wrote: On Wed, 2013-07-24 at 08:51 -0700, Stefano Maffulli wrote: Hello I have seen lots of discussions on blogs and twitter heating up around Amazon API compatibility and OpenStack. This seems like a recurring topic, often raised by pundits and recently

[openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Chuck Short
Hi, The use of mox (https://pypi.python.org/pypi/mox/0.5.3) across the test suites in the Openstack project is quite extensive. This is probably due to the fact that it is the most familiar mocking object framework for most python developers. However there is big drawback with using mox across

Re: [openstack-dev] Python 3

2013-07-24 Thread Brian Curtin
On Jul 23, 2013, at 4:32 PM, Doug Hellmann doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com wrote: On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton lo...@bacoosta.commailto:lo...@bacoosta.com wrote: I'm sure this has been asked before, but what exactly is the plan for Python

Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Alex Gaynor
I think moving towards mock is a better long term strategy: a) I don't you're correct that it's the most familiar for most python developers. By PyPi installs (A TERRIBLE METRIC, but it's all we have). Mock has 24k in the last week, mox has 3.5k b) mock is a part of the standard library starting

Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Jay Pipes
On 07/24/2013 02:19 PM, Alex Gaynor wrote: I think moving towards mock is a better long term strategy: a) I don't you're correct that it's the most familiar for most python developers. By PyPi installs (A TERRIBLE METRIC, but it's all we have). Mock has 24k in the last week, mox has 3.5k b)

Re: [openstack-dev] Python 3

2013-07-24 Thread Eric Windisch
Speaking of preferred ways to port, has there been any discussion about which version takes precedence when we have to do different things? For example, with imports, should we be trying the 2.x name first and falling back to 3.x on ImportError, or vice versa? Are we having it now? My belief

Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Kevin L. Mitchell
On Wed, 2013-07-24 at 14:12 -0400, Chuck Short wrote: 1. Change mox usage to more python3 friendly such as mock. (https://pypi.python.org/pypi/mock/1.0.1). However this will cause alot of code churn in the projects as we move away from mox to mock. 2. Use the python3 fork called pymox

Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Alex Meade
+1 I prefer mock over mox as well. It's more readable and intuitive. I've had a number of bad mox experiences lately so I'm a tad biased. -Alex -Original Message- From: Jay Pipes jaypi...@gmail.com Sent: Wednesday, July 24, 2013 2:24pm To: openstack-dev@lists.openstack.org Subject: Re:

Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Brian Curtin
On Jul 24, 2013, at 1:12 PM, Chuck Short chuck.sh...@canonical.commailto:chuck.sh...@canonical.com wrote: Hi, The use of mox (https://pypi.python.org/pypi/mox/0.5.3) across the test suites in the Openstack project is quite extensive. This is probably due to the fact that it is the most

Re: [openstack-dev] Python 3

2013-07-24 Thread Brian Curtin
On Jul 24, 2013, at 1:27 PM, Eric Windisch e...@cloudscaling.commailto:e...@cloudscaling.com wrote: Speaking of preferred ways to port, has there been any discussion about which version takes precedence when we have to do different things? For example, with imports, should we be trying the

Re: [openstack-dev] A simple way to improve nova scheduler

2013-07-24 Thread Joe Gordon
On Wed, Jul 24, 2013 at 12:24 PM, Russell Bryant rbry...@redhat.com wrote: On 07/23/2013 06:00 PM, Clint Byrum wrote: This is really interesting work, thanks for sharing it with us. The discussion that has followed has brought up some thoughts I've had for a while about this choke point in

Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Russell Bryant
On 07/24/2013 02:32 PM, Kevin L. Mitchell wrote: On Wed, 2013-07-24 at 14:12 -0400, Chuck Short wrote: 1. Change mox usage to more python3 friendly such as mock. (https://pypi.python.org/pypi/mock/1.0.1). However this will cause alot of code churn in the projects as we move away from mox to

Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-24 Thread Alex Meade
+1 to everything Russell just said and of course Blueprints for this. One for #3 (changing from mox - Mock) would be good so that anyone who is bored or finds this urgent can collaborate. Also, we need to make sure reviewers are aware (Hopefully they are reading this). -Alex -Original

Re: [openstack-dev] [keystone] Extending policy checking to include target entities

2013-07-24 Thread Adam Young
On 07/23/2013 03:56 PM, David Chadwick wrote: On 23/07/2013 18:36, Adam Young wrote: On 07/23/2013 01:17 PM, David Chadwick wrote: Of course the tricky thing is knowing which object attributes to fetch for which user API requests. In the general case you cannot assume that Keystone knows the

Re: [openstack-dev] A simple way to improve nova scheduler

2013-07-24 Thread Boris Pavlovic
Hi Mike, On Wed, Jul 24, 2013 at 1:01 AM, Mike Wilson geekinu...@gmail.com wrote: Again I can only speak for qpid, but it's not really a big load on the qpidd server itself. I think the issue is that the updates come in serially into each scheduler that you have running. We don't process

Re: [openstack-dev] [Swift] erasure codes, digging deeper

2013-07-24 Thread Pete Zaitcev
On Thu, 18 Jul 2013 12:31:02 -0500 Chuck Thier cth...@gmail.com wrote: I'm with Chmouel though. It seems to me that EC policy should be chosen by the provider and not the client. For public storage clouds, I don't think you can make the assumption that all users/clients will understand the

[openstack-dev] [Ceilometer] Meeting agenda for Thu Jul 25th at 1500 UTC

2013-07-24 Thread Julien Danjou
The Ceilometer project team holds a meeting in #openstack-meeting, see https://wiki.openstack.org/wiki/Meetings/MeteringAgenda for more details. Next meeting is on Thu Jul 25th at 1500 UTC Please add your name with the agenda item, so we know who to call on during the meeting. * Action from

[openstack-dev] Program Description for OpenStack Documentation

2013-07-24 Thread Anne Gentle
Program Name: OpenStack Documentation PTL: Anne Gentle Mission Statement: Provide documentation for core OpenStack projects to promote OpenStack. Develop and maintain tools and processes to ensure quality, accurate documentation. Treat documentation like OpenStack code. Details: Documentation is

Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.

2013-07-24 Thread Aaron Rosen
On Wed, Jul 24, 2013 at 12:42 AM, Samuel Bercovici samu...@radware.comwrote: Hi, ** ** This might be apparent but not to me. Can you point to how broadcast can be turned on a network/port? There is currently no way to prevent it so it's on by default. ** ** As for

Re: [openstack-dev] [tripleo] removing sudoers.d rules from disk-image-builder

2013-07-24 Thread Derek Higgins
+1 to removing the suders rules we have, there adding overhead and contain enough wildcards that all they do is give people a false sense of security On 23/07/13 17:39, Chris Jones wrote: Hi On 23 July 2013 10:52, Robert Collins robe...@robertcollins.net mailto:robe...@robertcollins.net

Re: [openstack-dev] [Nova] support for multiple active scheduler policies/drivers

2013-07-24 Thread Alex Glikson
Day, Phil philip@hp.com wrote on 24/07/2013 12:39:16 PM: If you want to provide a user with a choice about how much overcommit they will be exposed to then doing that in flavours and the aggregate_instance_extra_spec filter seems the more natural way to do this, since presumably you'd

Re: [openstack-dev] A simple way to improve nova scheduler

2013-07-24 Thread Joshua Harlow
As far as the send only when you have to. That reminds me of this piece of work that could be resurrected that slowed down the periodic updates when nothing was changing. https://review.openstack.org/#/c/26291/ Could be brought back, the concept still feels useful imho. But maybe not to

Re: [openstack-dev] [Nova] support for multiple active scheduler policies/drivers

2013-07-24 Thread Alex Glikson
Russell Bryant rbry...@redhat.com wrote on 24/07/2013 07:14:27 PM: I really like your point about not needing to set things up via a config file. That's fairly limiting since you can't change it on the fly via the API. True. As I pointed out in another response, the ultimate goal would be

Re: [openstack-dev] [networking] quantum...oops neutron unit tests

2013-07-24 Thread Jian Wen
Hello, I had trouble with run-tests.sh. `tox -epy27` works. On Fri, Jun 21, 2013 at 12:32 AM, Armando Migliaccio amigliac...@nicira.com wrote: Folks, Is anyone having troubles running the units tests locally on a clean venv with both run-tests.sh and tox? I found out that this is

Re: [openstack-dev] [Stackalytics] 0.1 release

2013-07-24 Thread Alex Freedland
Roman, Thank you for your comment. I agree that is should not be the only way to look at the statistics and that is why Stackalytics also measures the number of contributions and soon will add the number of reviews. I do, however, think it a useful statistic as because not all commits are created

Re: [openstack-dev] Discussing Amazon API compatibility [Nova][Swift]

2013-07-24 Thread Joshua Harlow
I think its still useful to have both, although I have a feeling that something like the 'AWSOME' conversion layer from EC2 might still be a pretty useful project to have to allow for a robust EC2 api which has a dedicated group of people to support it. Never was quite sure what happened to that

Re: [openstack-dev] [networking] quantum...oops neutron unit tests

2013-07-24 Thread Eugene Nikanorov
Hi Armando, That happens from time to time. Thanks, Eugene. On Thu, Jul 25, 2013 at 5:22 AM, Jian Wen jian@canonical.com wrote: Hello, I had trouble with run-tests.sh. `tox -epy27` works. On Fri, Jun 21, 2013 at 12:32 AM, Armando Migliaccio amigliac...@nicira.com wrote: Folks,

Re: [openstack-dev] [savanna] scalable architecture

2013-07-24 Thread Matthew Farrellee
On 07/23/2013 12:32 PM, Sergey Lukjanov wrote: Hi evereyone, We’ve started working on upgrading Savanna architecture in version 0.3 to make it horizontally scalable. The most part of information is in the wiki page - https://wiki.openstack.org/wiki/Savanna/NextGenArchitecture. Additionally

Re: [openstack-dev] [Openstack-dev][nova] Disable per-user rate limiting by default

2013-07-24 Thread Joshua Harlow
I would personally like it off, since it appears to me to offer a false sense of security for the reasons mentioned in that review (doesn't stop DOS, doesn't work across processes/API nodes). Even though, I would recommend/think before its turned off that there should be a detailed document on