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

Hi, This might be apparent but not to me. Can you point to how broadcast can be turned on a network/port? As for the https://github.com/openstack/neutron/blob/master/neutron/extensions/portsecurity.py, in NVP, does this totally disable port security on a port/network or it just disable the MAC

[openstack-dev] Validating Flavor IDs

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

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 the

Re: [openstack-dev] Python 3

On this same topic, is https://launchpad.net/~openstack-py3-team description still accurate? I see no trace of recent meetings. That could/should be updated. I've been working on Python 3 effort recently, I've also started a wiki page at https://wiki.openstack.org/wiki/Python3 to track progress.

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

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 seems

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

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 poin

Re: [openstack-dev] [barbican]

> >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. > >https:

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

>· 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 com

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

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 wro

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

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 wrote: > > ** No meeting this week ** > > I have a conflict

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

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. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org ht

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

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 time to bring the discussions inside our community to our es

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

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'

Re: [openstack-dev] Python 3

On 07/23/2013 03:02 PM, Brian Curtin wrote: > > On Jul 23, 2013, at 3:51 PM, Eric Windisch > > wrote: > >> >> >> >> On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton > > wrote: >> >> I'm sure this has been asked before, but what exa

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

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 > flavou

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

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]

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 rece

[openstack-dev] [Heat] Meeting agenda for Wed July 24th at 2000 UTC

The Heat team holds a weekly meeting in #openstack-meeting, see https://wiki.openstack.org/wiki/Meetings/HeatAgenda for more details The next meeting is on Wed July 24th at 2000 UTC Current topics for discussion: - Review last week's actions - Documentation - h3 blueprint milestone and priori

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

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. https://review.openstack.org/#/

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

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). >

Re: [openstack-dev] Python 3

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 wrote: > > > On 07/

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

Welcome Ben and Julien! On Wed, Jul 24, 2013 at 11:42 AM, Mark McLoughlin 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)

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 wrote: > Sha

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

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)

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 wrote: Shawn, or others involved in this effort, Is there a quick README or equivalent on how to use the latest code say with

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

Thanks Dan and Shawn. Those links are exactly what i was needed. -- dims On Wed, Jul 24, 2013 at 1:10 PM, Shawn Hartsock 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 Hartsock > > Dav

Re: [openstack-dev] Python 3

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

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

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

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

On Wed, Jul 24, 2013 at 8:51 AM, Stefano Maffulli 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 its own github repo

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

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.

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 a

Re: [openstack-dev] Python 3

On Jul 23, 2013, at 4:32 PM, Doug Hellmann mailto:doug.hellm...@dreamhost.com>> wrote: On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton mailto:lo...@bacoosta.com>> wrote: I'm sure this has been asked before, but what exactly is the plan for Python 3 support? Is the plan to support 2 and

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

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 w

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

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) mock

Re: [openstack-dev] Python 3

> 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 be

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

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.

+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" Sent: Wednesday, July 24, 2013 2:24pm To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] U

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

On Jul 24, 2013, at 1:12 PM, Chuck Short mailto: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 familiar mocking object fram

Re: [openstack-dev] Python 3

On Jul 24, 2013, at 1:27 PM, Eric Windisch mailto: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 2.x name first and fa

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

On Wed, Jul 24, 2013 at 12:24 PM, Russell Bryant 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 what is sup

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

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

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

+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 Mes

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

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

Hi Mike, On Wed, Jul 24, 2013 at 1:01 AM, Mike Wilson 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 those quickly > enoug

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

We had this discussion in Ironic a while back, and part of the use of mox going forward was familiarity amongst most of the coders currently submitting patches thus enhancing speed of development, a situation that falls under your observations, Chuck. Would it be possible to create a wiki page

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

On Thu, 18 Jul 2013 12:31:02 -0500 Chuck Thier 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 > storage/laten

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

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 prev

[openstack-dev] Program Description for OpenStack Documentation

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 a

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

On Wed, Jul 24, 2013 at 12:42 AM, Samuel Bercovici wrote: > 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 the > htt

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

+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 > wrote: > > So I'd l

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

"Day, Phil" 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 want to cha

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

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 others

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

Russell Bryant 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 to have policie

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

I have added my proposal @ https://etherpad.openstack.org/api_policy_on_target. Thanks, Arvind -Original Message- From: Henry Nash [mailto:hen...@linux.vnet.ibm.com] Sent: Wednesday, July 24, 2013 8:46 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [keystone] Exte

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

Hi all I have proposed a patch to disable per-user rate limiting by default: https://review.openstack.org/#/c/34821/. And on Russell's request does anyone care or prefer this to be enabled by default? Here is some more context: Earlier rate limiting discussion: http://www.gossamer-threads.com/l

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

Hello, I had trouble with run-tests.sh. `tox -epy27` works. On Fri, Jun 21, 2013 at 12:32 AM, Armando Migliaccio 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 relevant to the issue I a

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

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]

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 pr

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

Hi Armando, That happens from time to time. Thanks, Eugene. On Thu, Jul 25, 2013 at 5:22 AM, Jian Wen 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, >> >> Is any

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

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 the

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

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