Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

2013-06-28 Thread Nachi Ueno
Hi Russell Your tool is awesome. I have also two idea (I believe it's not crazy :P ). 1) Show LOC of the review Long patch takes long time.. 2) Show priority of the review If it shows priority of the review, it wil be more useful, because we should work on the order of the priorities. The prior

Re: [openstack-dev] [nova] Nova API extensions NOT to be ported to v3

2013-06-28 Thread Anne Gentle
On Fri, Jun 28, 2013 at 7:31 AM, Christopher Yeoh wrote: > Hi, > > The following is a list of API extensions for which there are no plans to > port. Please shout if you think any of them needs to be! > What does "no plans to port" mean for people already using Floating IPs and Cloudpipe via API

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

2013-06-28 Thread Monty Taylor
On 06/28/2013 05:43 PM, Russell Bryant wrote: > On 06/28/2013 03:44 PM, Boris Pavlovic wrote: >> Russell, >> >> I have some crazy Idea, about how to make reviewing more stable. >> And how to avoid old patches at all. >> >> "Old" means that last update was more then N days ago. >> >> If there a

Re: [openstack-dev] [Nova] Nominating John Garbutt for nova-core

2013-06-28 Thread Armando Migliaccio
I think he's got enough +1...but here's mine: +1 On Thu, Jun 27, 2013 at 3:10 AM, Bob Ball wrote: > +1 from me too. > > From: Russell Bryant [rbry...@redhat.com] > Sent: 26 June 2013 16:09 > To: OpenStack Development Mailing List > Subject: [openstack-de

Re: [openstack-dev] [Networking] Allocation of IPs

2013-06-28 Thread Edgar Magana
Actually, the implementation for that method in our case will just simple return an empty value (if that is possible) because I can't tale which IP address the DHCP will assign. I could tell the DHCP server which IP assign to the specific MAC but I could not have that kind of functionality. After t

Re: [openstack-dev] [Networking] Allocation of IPs

2013-06-28 Thread Armando Migliaccio
I guess the other question is: is this the right approach? I think your use case may be beneficial to other plugins, so in my view having a plugin-specific override is not the best fit. On Fri, Jun 28, 2013 at 2:42 PM, Edgar Magana wrote: > Got it!!! I knew it could be possible.. > > Thanks, >

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

2013-06-28 Thread Russell Bryant
On 06/28/2013 03:44 PM, Boris Pavlovic wrote: > Russell, > > I have some crazy Idea, about how to make reviewing more stable. > And how to avoid old patches at all. > > "Old" means that last update was more then N days ago. > > If there are patches that are older then N days: > we just hide "

Re: [openstack-dev] [Networking] Allocation of IPs

2013-06-28 Thread Edgar Magana
Got it!!! I knew it could be possible.. Thanks, Edgar From: Aaron Rosen Reply-To: OpenStack List Date: Friday, June 28, 2013 2:19 PM To: OpenStack List Subject: Re: [openstack-dev] [Networking] Allocation of IPs Gotcha, The part that was confusing was: >Could it be possible to add a f

Re: [openstack-dev] [nova] Nova API extensions NOT to be ported to v3

2013-06-28 Thread Russell Bryant
On 06/28/2013 03:46 PM, Andrew Laski wrote: > On 06/28/13 at 10:01pm, Christopher Yeoh wrote: >> Hi, >> >> The following is a list of API extensions for which there are no plans to >> port. Please shout if you think any of them needs to be! >> >> baremetal_nodes.py >> os_networks.py >> networks_ass

Re: [openstack-dev] [Networking] Allocation of IPs

2013-06-28 Thread Aaron Rosen
Gotcha, The part that was confusing was: >Could it be possible to add a flag to disable the allocation for the IP? >If the "no allocation" flag is enabled, all ports will have an empty value for IPs. So what you are looking to do is to provide the IP address from the plugin and not the db_base cl

[openstack-dev] [barbican] Barbican Client Version 0.2

2013-06-28 Thread Arash Ghoreyshi
Hi all, The latest version of python-barbicanclient is now available via pip. You can get it using: pip install python-barbicanclient This version includes the new command line interface, keep. Here's its documentation: https://github.com/cloudkeep/python-barbicanclient/wiki/Command-Line-Clien

Re: [openstack-dev] Question about locking

2013-06-28 Thread Ben Nemec
On 2013-06-26 12:07, Rosa, Andrea (HP Cloud Services) wrote: Hi all, What happens if a greenthread, after acquiring a lock (not external), it dies? For example: A thread is performing the "do_terminate_instance", it has the lock and before terminating the process it dies, what happens at the

Re: [openstack-dev] [nova] Nova API extensions NOT to be ported to v3

2013-06-28 Thread Andrew Laski
On 06/28/13 at 10:01pm, Christopher Yeoh wrote: Hi, The following is a list of API extensions for which there are no plans to port. Please shout if you think any of them needs to be! baremetal_nodes.py os_networks.py networks_associate.py os_tenant_networks.py virtual_interfaces.py createserver

Re: [openstack-dev] [Networking] Allocation of IPs

2013-06-28 Thread Edgar Magana
Aaron, You are totally right, the point is that I don't want to loose the IPAM info in Neutron because that is the moment when the backend plugin deploys a new DHCP server into the Virtual Networking Infrastruture. So, every time that a user creates a subnet and enables DHCP our plugin deploys a n

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

2013-06-28 Thread Boris Pavlovic
Russell, I have some crazy Idea, about how to make reviewing more stable. And how to avoid old patches at all. "Old" means that last update was more then N days ago. If there are patches that are older then N days: we just hide "review" button for all patches except old patches. When they are re

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

2013-06-28 Thread Matt Joyce
review response time matches up to accepted practices in infosec for quantifying risk exposure in terms of incident response times. so this is actually a suggest best practice in other areas. -matt On Fri, Jun 28, 2013 at 10:30 AM, Russell Bryant wrote: > On 06/28/2013 12:18 PM, Matt Riedeman

Re: [openstack-dev] [keystone] More on inherited domain roles

2013-06-28 Thread Henry Nash
Hi Adam, It's a valid debatethe thing I would add is that we should make the way group roles are handled consistently with whatever we do for inherited roles. Group roles are a kind of inheritance (i.e. because I am a member of Group X, I inherit all the role assignments that Group X has..

Re: [openstack-dev] [Networking] Allocation of IPs

2013-06-28 Thread Aaron Rosen
Hi Edgar, I'm still not following. In your original question you asked how to you create a port and not allocate an ip address to it at all so that you can leverage a real dhcp server to do that. In order to do that you can create a network without a subnet but then you loose the ipam info in quan

Re: [openstack-dev] [keystone] More on inherited domain roles

2013-06-28 Thread David Chadwick
Hi Adam if you do it at role assignment time, I think the newly assigned role should be marked as implicit/inherited to differentiate it from an explicitly assigned role. In this way, if the inheritance is subsequently removed, then the inherited assignment can also be deleted at the same tim

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

2013-06-28 Thread Russell Bryant
On 06/28/2013 12:18 PM, Matt Riedemann wrote: > Hey I made the list! > > _https://review.openstack.org/#/c/25355/_ > > Just wanted to point out for nova in longest-waiting reviews based on > first revision: > > > 1.94 days, 12 hours, 49 minutes > - _https://review.openstack.org/25355_ (

Re: [openstack-dev] [networking] A consideration about config files and deployment issues

2013-06-28 Thread Jay Pipes
On 06/28/2013 01:26 PM, Armando Migliaccio wrote: Folks, I appreciate that there is a strong awareness within the dev community to ensure that OpenStack gets easier and easier to be deployed, upgraded and maintained, however I would like to invite core reviewers to think (even) harder about the

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

2013-06-28 Thread Russell Bryant
On 06/28/2013 08:24 AM, Christopher Yeoh wrote: > How about time since first revision or -1 applied (but not including -1s > by Jenkins due to gate flakiness), whichever is shorter. That eliminates > non trivial rebases which I've found are often required after about 7 > days but doesn't push out t

[openstack-dev] [networking] A consideration about config files and deployment issues

2013-06-28 Thread Armando Migliaccio
Folks, I appreciate that there is a strong awareness within the dev community to ensure that OpenStack gets easier and easier to be deployed, upgraded and maintained, however I would like to invite core reviewers to think (even) harder about the implications that changes to config files may have f

Re: [openstack-dev] [Openstack] CLI command to figure out security-group's association to particular tenant/user

2013-06-28 Thread Rick Jones
On 06/28/2013 01:55 AM, Rahul Sharma wrote: Thanks Aaron for your kind help. It worked. Is there any doc which lists all the possible commands and their usage for quantum? because --help doesn't help in identifying all the parameters, is there any reference which one can use to get the complete c

Re: [openstack-dev] Http library usage by clients

2013-06-28 Thread Flavio Percoco
On 26/06/13 12:55 -0400, Adam Young wrote: Glance: - Uses httplib for communication - Uses keystoneclient within cli - Checks that socket is patched before importing eventlet for httplib. FWIW, we're working on the migration to requests. Cheers, FF -- @flaper87 Flavio Percoco __

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

2013-06-28 Thread Matt Riedemann
Hey I made the list! https://review.openstack.org/#/c/25355/ Just wanted to point out for nova in longest-waiting reviews based on first revision: 1. 94 days, 12 hours, 49 minutes - https://review.openstack.org/25355 (PowerVM resize and migrate test cases) This one is a bit skewed beca

Re: [openstack-dev] [keystone] More on inherited domain roles

2013-06-28 Thread Adam Young
Since I will be gone next week, and I know you want to move on with this, just wanted to confirm that I am OK with Henry's approach. I would like to suggest that we contemplate doing to inheritance mechanism at assignment time as opposed to token creation time as an optimization. What would t

Re: [openstack-dev] [Networking] Allocation of IPs

2013-06-28 Thread Edgar Magana
Thanks Mark! Edgar From: Mark McClain Reply-To: OpenStack List Date: Monday, June 24, 2013 7:04 AM To: OpenStack List Subject: Re: [openstack-dev] [Networking] Allocation of IPs Here's the blueprintŠ https://blueprints.launchpad.net/quantum/+spec/configurable-ip-allocation On Jun 21,

Re: [openstack-dev] [Networking] Allocation of IPs

2013-06-28 Thread Edgar Magana
Aaron, Because the create create_subnet API is the one that enables/disables the DHCP: quantum subnet-create--enable_dhcp False Besides, the CIDR is actually the information that is sent to the DHCP to locate IP Addresses. Thanks, Edgar From: Aaron Rosen Reply-To: OpenStack List

Re: [openstack-dev] Http library usage by clients

2013-06-28 Thread Adam Young
On 06/27/2013 10:35 AM, Thierry Carrez wrote: Adam Young wrote: Right now Keystone provides so called bearer tokens: This means that whoever has a token can do whatever the token entitles him to do. If I manage to get somebody's token I can do whatever this person is able to do. Right. Tokens

[openstack-dev] [Networking] Basic Bug Etiquette

2013-06-28 Thread Maru Newby
I'd like to reminder all Neutron contributors that if you are not the assignee for a bug, you should be consulting the assignee before you consider reassigning the bug to yourself or others. Failing to do so is not only disrespectful, but may also result in unnecessary work. It could be that t

Re: [openstack-dev] [oslo] Sample config file location inconsistency

2013-06-28 Thread Flavio Percoco
On 25/06/13 11:03 +0800, Zhongyue Luo wrote: Hi team I'm currently trying to move the generate_sample.sh script in nova to oslo. Before pushing the patch to gerrit, I wanted to give the output directory a default value if it was not stated so I was wondering where projects put their sample conf

Re: [openstack-dev] [PTLs] Proposed simplification around blueprint tracking

2013-06-28 Thread Flavio Percoco
On 19/06/13 15:51 +0200, Thierry Carrez wrote: Thoughts ? Although it is not an integrated project - not even incubated - we've been doing this for Marconi as well and it's been quite a pain. Also, I've been following how Glance's blueprints have evolved and again, I've noticed how hard it is

Re: [openstack-dev] Http library usage by clients

2013-06-28 Thread Adam Young
On 06/27/2013 10:45 PM, Simo Sorce wrote: On Thu, 2013-06-27 at 17:49 -0700, Clint Byrum wrote: On 2013-06-27 16:28, Jamie Lennox wrote: On Fri, 2013-06-28 at 07:01 +1200, Robert Collins wrote: On 27 June 2013 04:55, Adam Young wrote: Right now Keystone provides so called bearer tokens: This

[openstack-dev] Rating engine for BillingStack

2013-06-28 Thread Endre Karlson
Hi, I would like to get some input on what kind of rating rules engine we could use for BS. Basically there are two alternatives as we see it now: Drools as a service besides the Python components in BS using https://github.com/droolsjbpm/drools-wb as a UI and interact with it as a webservice Pyth

Re: [openstack-dev] Http library usage by clients

2013-06-28 Thread Chmouel Boudjnah
On Fri, Jun 28, 2013 at 10:12 AM, Steven Hardy wrote: > Obviously long-term a keystone native way to sign requests would be great, > and could be used by Heat, and e.g Swift which has it's own method for > generating pre-signed URLs. fyi: only when you are using the temporary url feature you are

[openstack-dev] [nova] Nova API extensions NOT to be ported to v3

2013-06-28 Thread Christopher Yeoh
Hi, The following is a list of API extensions for which there are no plans to port. Please shout if you think any of them needs to be! baremetal_nodes.py os_networks.py networks_associate.py os_tenant_networks.py virtual_interfaces.py createserverext.py floating_ip_dns.py floating_ip_pools.py flo

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

2013-06-28 Thread Christopher Yeoh
On Fri, Jun 28, 2013 at 12:12 PM, Russell Bryant wrote:The results are much better than I was afraid of. On average across all > projects, patches waiting for review have an age of just under 14 days > since they were first posted. Nova is below average, sitting at an > average of just over 10 d

Re: [openstack-dev] [Keystone] Unified logging and Eventlet conflict

2013-06-28 Thread Doug Hellmann
On Thu, Jun 27, 2013 at 11:35 PM, Adam Young wrote: > On 06/27/2013 08:43 AM, Davanum Srinivas wrote: > >> Lance, Doug, >> Looks like eventlet.patcher.is_monkey_**patched(thread) is a reasonable >> check to switch to to a thread-local implementation. >> > > Doesn't it make more sense to have anyt

Re: [openstack-dev] [PTLs] Proposed simplification around blueprint tracking

2013-06-28 Thread Thierry Carrez
Thierry Carrez wrote: > Thierry Carrez wrote: >> A script will automatically and regularly align "series goal" with >> "target milestone", so that the series and milestone views are >> consistent (if someone sets target milestone to "havana-3" then the >> series goal will be set to "havana"). > >

Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats

2013-06-28 Thread John Garbutt
Interesting, thanks for trying that. I think this is the time people "feel" the most. It should help set expectations on how long it will take to get your change into trunk. It seems, on average, to take two weeks. Hopefully it is useful to spot reviews that are proving tricky to get in, and they

Re: [openstack-dev] [Nova]Discussion about resize and migrate status separation

2013-06-28 Thread John Garbutt
I am not sure its worth the extra calls. Hopefully once we have live-migrate and cold-migrate/resize refactor done we can add a new single API that better combines the different approaches, which should remove the confusion. Thinking about it, that should sove the issue about the different states

Re: [openstack-dev] [Openstack] CLI command to figure out security-group's association to particular tenant/user

2013-06-28 Thread Akihiro MOTOKI
The detail parameters are described in the API reference. It is the best document to know the parameters'detail at the moment. http://docs.openstack.org/api/openstack-network/2.0/content/security-groups-ext.html In general options of quantum command can be mapped to API attributes one to one. Aki

Re: [openstack-dev] [Openstack] CLI command to figure out security-group's association to particular tenant/user

2013-06-28 Thread Rahul Sharma
Thanks Aaron for your kind help. It worked. Is there any doc which lists all the possible commands and their usage for quantum? because --help doesn't help in identifying all the parameters, is there any reference which one can use to get the complete command syntax? -Regards Rahul Sharma On Fri

Re: [openstack-dev] [Nova]Discussion about resize and migrate status separation

2013-06-28 Thread guohliu
On 06/27/2013 07:05 PM, John Garbutt wrote: I haven't seen any plans to change this. The way I see it, the states make most sense for resize, which is the end-user facing operation. Personally I see migrate as a more admin focused operation. So to help simplify the code, I am OK with slightly c

Re: [openstack-dev] Http library usage by clients

2013-06-28 Thread Steven Hardy
On Thu, Jun 27, 2013 at 05:49:00PM -0700, Clint Byrum wrote: > On 2013-06-27 16:28, Jamie Lennox wrote: > >On Fri, 2013-06-28 at 07:01 +1200, Robert Collins wrote: > >>On 27 June 2013 04:55, Adam Young wrote: > >>>Right now Keystone provides so called bearer tokens: This > >>>means that whoever >

Re: [openstack-dev] [Openstack] CLI command to figure out security-group's association to particular tenant/user

2013-06-28 Thread Aaron Rosen
On Thu, Jun 27, 2013 at 10:51 PM, Rahul Sharma wrote: > Hi Aaron, > > Thanks for the CLI. I have a query related to that. I have a multinode > openstack-deployment. To allow all the ports of VM accessible from outside, > I need to add a rule "*TCP port-range 1-65535 Allow*" using Horizon > dashboa