Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Kevin Benton
Can you link to the etherpad you mentioned? In the mean time, apologies for another analogy in advance. :-) If I give you an API to sort a list, I'm free to implement it however I want as long as I return a sorted list. However, there is no way me to know based on a call to this API that you

[openstack-dev] [nova] About response of Get server details API v2

2014-08-08 Thread Kanno, Masaki
Hi all, Jclouds put out a stack trace when I tried Get server details of API v2 by jclouds. I looked into a response body of the API, and found that a value of image was an empty string as follows. I think the value of image should be an empty dictionary like Get server details of API v3. What

[openstack-dev] [gerrit] Preparing a patch that has dependency to more than one code under review

2014-08-08 Thread Nader Lahouti
Hi, Is it possible to send a patch for review (i.e. A) on gerrit based on multiple commit under the review (i.e. B and C)? Based on the wiki page to add dependency these command should be used: A-B, A-C (no dependency between B and C) #fetch change under review and check out branch based on that

[openstack-dev] [HEAT] Is there any line length limitation in paste deploy configuration file?

2014-08-08 Thread Baohua Yang
Hi, Recently I have noticed the api-paste. ini file in heat has some very long lines (over the popular 80c). Wondering if there's recommended length limitation on it? Sometime, users have to read the file and change the configuration value, so I think it should be kept readable.

Re: [openstack-dev] [all] The future of the integrated release

2014-08-08 Thread Nikola Đipanov
On 08/08/2014 12:12 AM, Stefano Maffulli wrote: On 08/07/2014 01:41 PM, Eoghan Glynn wrote: My point was simply that we don't have direct control over the contributors' activities This is not correct and I've seen it repeated too often to let it go uncorrected: we (the OpenStack project as

Re: [openstack-dev] introducing cyclops

2014-08-08 Thread Piyush Harsh
Dear Eoghan, Thanks for your comments. Although you are correct that rating, charging, and billing policies are commercially sensitive to the operators, still if an operator has an openstack installation, I do not see why the stack could not offer a service that supports ways for the operator to

Re: [openstack-dev] [devstack] Core team proposals

2014-08-08 Thread Chmouel Boudjnah
On Thu, Aug 7, 2014 at 8:09 PM, Dean Troyer dtro...@gmail.com wrote: Please respond in the usual manner, +1 or concerns. +1, I would be happy to see Ian joining the team. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Neutron] Neutron Ryu status

2014-08-08 Thread YAMAMOTO Takashi
just an update: the Neutron Ryu CI is getting stable now. please let me know if you noticed any problems. thank you. YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [gerrit] Preparing a patch that has dependency to more than one code under review

2014-08-08 Thread Sylvain Bauza
Hi Nader, Le 08/08/2014 09:23, Nader Lahouti a écrit : Hi, Is it possible to send a patch for review (i.e. A) on gerrit based on multiple commit under the review (i.e. B and C)? Based on the wiki page to add dependency these command should be used: A-B, A-C (no dependency between B and C)

Re: [openstack-dev] [Neutron] how to deprecate a plugin

2014-08-08 Thread YAMAMOTO Takashi
On Thu, Jul 31, 2014 at 1:43 AM, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: On Wed, Jul 30, 2014 at 12:17 PM, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: hi, what's the right procedure to deprecate a plugin? we (ryu team) are considering deprecating ryu plugin, in favor of ofagent.

[openstack-dev] Further discussions on Cyclops

2014-08-08 Thread Piyush Harsh
Dear Andre, I have not been an active user or IRC, but I have just now started using it, I use the handle PH7_0 on irc://rajaniemi.freenode.net ... Tell me the time and date and we can discuss more on cyclops. Cheers, Piyush. ___ Dr. Piyush Harsh, Ph.D.

[openstack-dev] use of compute node as a storage

2014-08-08 Thread shailendra acharya
i made 4 vm 1 controller, 1 network and 2 compute and i want 1 compute to run as a storage so plz help how can i do such ? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

2014-08-08 Thread Liyi Meng
Hi John, I have some comments as well. see blow :) _On 6 August 2014 18:54, Jay Pipes jaypipes at gmail.com wrote: So, Liyi Meng has an interesting patch up for Nova: https://review.openstack.org/#/c/104876 1) We should just deprecate both the options, with a note in the

Re: [openstack-dev] introducing cyclops

2014-08-08 Thread Stephane Albert
On Thu, Aug 07, 2014 at 12:01:04PM +0200, Piyush Harsh wrote: Dear All, Let me use my first post to this list to introduce Cyclops and initiate a discussion towards possibility of this platform as a future incubated project in OpenStack. We at Zurich university of Applied Sciences have a

Re: [openstack-dev] [all] The future of the integrated release

2014-08-08 Thread Thierry Carrez
Michael Still wrote: [...] I think an implied side effect of the runway system is that nova-drivers would -2 blueprint reviews which were not occupying a slot. (If we start doing more -2's I think we will need to explore how to not block on someone with -2's taking a vacation. Some sort of

Re: [openstack-dev] [all] The future of the integrated release

2014-08-08 Thread Thierry Carrez
Eoghan Glynn wrote: On 08/07/2014 01:41 PM, Eoghan Glynn wrote: My point was simply that we don't have direct control over the contributors' activities This is not correct and I've seen it repeated too often to let it go uncorrected: we (the OpenStack project as a whole) have a lot of

Re: [openstack-dev] [all] The future of the integrated release

2014-08-08 Thread Nikola Đipanov
On 08/08/2014 11:37 AM, Thierry Carrez wrote: Personally I think we just need to get better at communicating the downstream expectations, so that if we create waste, it's clearly upstream fault rather than downstream. Currently it's the lack of communication that makes developers produce more

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

2014-08-08 Thread Matthew Booth
On 07/08/14 18:54, Kevin L. Mitchell wrote: On Thu, 2014-08-07 at 17:46 +0100, Matthew Booth wrote: In any case, the operative point is that CONF.attribute must always be evaluated inside run-time code, never at module load time. ...unless you call register_opts() safely, which is what I'm

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

2014-08-08 Thread Matthew Booth
On 07/08/14 19:02, Kevin L. Mitchell wrote: On Thu, 2014-08-07 at 17:41 +0100, Matthew Booth wrote: ... or arg is an object which defines __nonzero__(), or defines __getattr__() and then explodes because of the unexpected lookup of a __nonzero__ attribute. Or it's False (no quotes when printed

Re: [openstack-dev] backport fixes to old branches

2014-08-08 Thread Osanai, Hisashi
Hi, On Tuesday, August 05, 2014 8:57 PM, Ihar Hrachyshka wrote: Thanks. To facilitate quicker backport, you may also propose the patch for review yourself. It may take time before stable maintainers or other interested parties get to the bug and do cherry-pick. I did cherry-pick for

Re: [openstack-dev] [devstack] Core team proposals

2014-08-08 Thread chandankumar
On 08/08/2014 01:05 PM, Chmouel Boudjnah wrote: On Thu, Aug 7, 2014 at 8:09 PM, Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com wrote: Please respond in the usual manner, +1 or concerns. +1, I would be happy to see Ian joining the team. +1 Chmouel

Re: [openstack-dev] [ceilometer] [swift] Improving ceilometer.objectstore.swift_middleware

2014-08-08 Thread Osanai, Hisashi
Hi, Is there any way to proceed ahead the following topic? Best Regards, Hisashi Osanai On Friday, August 01, 2014 7:32 PM, Hisashi Osanai wrote: I would like to follow this discussion so I picked up points. - There are two way to collect info from swift, one is pollster and the other

Re: [openstack-dev] Which program for Rally

2014-08-08 Thread Neependra Kumar Khare
- Original Message - From: Thierry Carrez thie...@openstack.org To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Sent: Wednesday, August 6, 2014 4:00:35 PM Subject: [openstack-dev] Which program for Rally 1. Rally as an essential QA tool Performance testing (and

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

2014-08-08 Thread Matthew Booth
On 08/08/14 11:04, Matthew Booth wrote: On 07/08/14 18:54, Kevin L. Mitchell wrote: On Thu, 2014-08-07 at 17:46 +0100, Matthew Booth wrote: In any case, the operative point is that CONF.attribute must always be evaluated inside run-time code, never at module load time. ...unless you call

[openstack-dev] [Manila] Debug data for the NFS v4 hang issue

2014-08-08 Thread Deepak Shetty
Per yesterday's IRC meeting, I have updated the debug data I had collected in the github issue @ https://github.com/csabahenk/cirros/issues/9 It has data for both : 32bit nfs client accessing 64bit cirros nfs server 64bit nfs client accessing 64bit cirros nfs server thanx, deepak

Re: [openstack-dev] ceilometer] [ft] Improving ceil.objectstore.swift_middleware

2014-08-08 Thread Chris Dent
On Fri, 8 Aug 2014, Osanai, Hisashi wrote: Is there any way to proceed ahead the following topic? There are three active reviews that are somewhat related to this topic: Use a FakeRequest object to test middleware: https://review.openstack.org/#/c/110302/ Publish samples on other threads:

Re: [openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

2014-08-08 Thread Nikola Đipanov
On 08/06/2014 07:54 PM, Jay Pipes wrote: I bring this up on the mailing list because I think Liyi's patch offers an interesting future direction to the way that we think about our retry approach in Nova. Instead of having hard-coded or configurable interval times, I think Liyi's approach of

[openstack-dev] [Ceilometer] Question on decorators in Ceilometer pecan framework

2014-08-08 Thread Pendergrass, Eric
Hi, We have been struggling to get a decorator working for proposed new RBAC functionality in ceilometer-api. We're hitting a problem where GET request query parameters are mucked up by our decorator. Here's an example call: curl -H X-Auth-Token:$TOKEN

Re: [openstack-dev] [Neutron][Nova] API design and usability

2014-08-08 Thread Andrew Laski
On 08/07/2014 07:57 AM, Mathieu Gagné wrote: On 2014-08-06 7:58 PM, Robert Collins wrote: I'm astounded by this proposal - it doesn't remove the garbage collection complexity at all - it transfers it from our code - Nova - onto end users. So rather than one tested and consolidated

Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

2014-08-08 Thread Russell Bryant
On 08/07/2014 08:06 PM, Michael Still wrote: It seems to me that the tension here is that there are groups who would really like to use features in newer libvirts that we don't CI on in the gate. Is it naive to think that a possible solution here is to do the following: - revert the

[openstack-dev] [neutron] [third-party] Freescale CI log site is being blocked

2014-08-08 Thread Kyle Mestery
Trinath: In looking at your FWaaS review [1], I noticed the site you are using for log storage is being blacklisted again, at least by Cisco WSA appliances. Thus, I cannot see the logs for it. Did you change the location of your log storage again? Is anyone else seeing this issue? Thanks, Kyle

Re: [openstack-dev] [Ceilometer] Question on decorators in Ceilometer pecan framework

2014-08-08 Thread Pendergrass, Eric
Sorry, wrong BP review link below. Here is the correct one: https://review.openstack.org/#/c/112127/3. Please disregard the wiki link. From: Pendergrass, Eric Sent: Friday, August 08, 2014 6:50 AM To: openstack-dev@lists.openstack.org Cc: Giannetti, Fabio Subject: [Ceilometer] Question on

Re: [openstack-dev] [oslo.db]A proposal for DB read/write separation

2014-08-08 Thread Roman Podoliaka
Hi Li, How are you going to make this separation transparent? I mean, generally, in a function code, you can't know in advance if the transaction will be read-only or it will contain an INSERT/UPDATE/DELETE statement. On the other hand, as a developer, you could analyze the DB queries that can be

Re: [openstack-dev] [Ceilometer] Question on decorators in Ceilometer pecan framework

2014-08-08 Thread Pendergrass, Eric
Wrong link again, this is embarrassing :( https://review.openstack.org/#/c/112137/3 From: Pendergrass, Eric Sent: Friday, August 08, 2014 7:15 AM To: openstack-dev@lists.openstack.org Subject: RE: [Ceilometer] Question on decorators in Ceilometer pecan framework Sorry, wrong BP review link

Re: [openstack-dev] [all] The future of the integrated release

2014-08-08 Thread Philip Cheong
This thread couldn't help but make me wonder what kind of problems people hit developing on the linux kernel. I discovered this pretty incredible article which seemed to have enough relevant information in it to post it, but also give me the hopes that Openstack and it's contributors are

Re: [openstack-dev] [oslo.db]A proposal for DB read/write separation

2014-08-08 Thread Mike Bayer
On Aug 8, 2014, at 12:03 AM, Li Ma skywalker.n...@gmail.com wrote: So, I'd like to propose a transparent read/write separation method for oslo.db that every project may happily takes advantage of it without any code modification. A single transaction begins, which is to emit a series of

Re: [openstack-dev] [Ceilometer] Question on decorators in Ceilometer pecan framework

2014-08-08 Thread David Stanek
It looks like maybe WSME or Pecan is inspecting the method signature. Have you tried to change the order of the decorators? On Aug 8, 2014, at 9:16, Pendergrass, Eric eric.pendergr...@hp.com wrote: Wrong link again, this is embarrassing L https://review.openstack.org/#/c/112137/3 From:

Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

2014-08-08 Thread Russell Bryant
On 08/08/2014 01:46 AM, Luke Gorrie wrote: On 8 August 2014 02:06, Michael Still mi...@stillhq.com mailto:mi...@stillhq.com wrote: 1: I think that ultimately should live in infra as part of check, but I'd be ok with it starting as a third party if that delivers us something

Re: [openstack-dev] [all] The future of the integrated release

2014-08-08 Thread Chris Dent
On Fri, 8 Aug 2014, Nikola Đipanov wrote: To me the runway approach seems like yet another set of arbitrary hoops that we will put in place so that we don't have to tell people that we don't have bandwidth/willingness to review and help their contribution in. I pretty much agree with this. As

Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

2014-08-08 Thread Luke Gorrie
On 8 August 2014 15:27, Russell Bryant rbry...@redhat.com wrote: It sounds like what you're working on is a separate thing. Roger. Just wanted to check if our work could have some broader utility, but as you say we do have a specific use case in mind. Cheers! -Luke

[openstack-dev] [oslo] usage patterns for oslo.config

2014-08-08 Thread Coles, Alistair
I've been looking at the implications of applying oslo.config in Swift, and I have a question about the best pattern for registering options. Looking at how keystone uses oslo.config, the pattern seems to be to have all options declared and registered 'up-front' in a single place

Re: [openstack-dev] [all] The future of the integrated release

2014-08-08 Thread Kyle Mestery
On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon joe.gord...@gmail.com wrote: On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, With the incredible growth of OpenStack, our development community is facing complex challenges. How we handle those might

Re: [openstack-dev] [all] The future of the integrated release

2014-08-08 Thread Kyle Mestery
On Fri, Aug 8, 2014 at 4:06 AM, Thierry Carrez thie...@openstack.org wrote: Michael Still wrote: [...] I think an implied side effect of the runway system is that nova-drivers would -2 blueprint reviews which were not occupying a slot. (If we start doing more -2's I think we will need to

Re: [openstack-dev] [cinder] Bug#1231298 - size parameter for volume creation

2014-08-08 Thread Dean Troyer
On Fri, Aug 8, 2014 at 12:36 AM, Ganapathy, Sandhya sandhya.ganapa...@hp.com wrote: This is to discuss Bug #1231298 – https://bugs.launchpad.net/cinder/+bug/1231298 ... Conclusion reached with this bug is that, we need to modify cinder client in order to accept optional size parameter (as

Re: [openstack-dev] [all] The future of the integrated release

2014-08-08 Thread Russell Bryant
On 08/08/2014 05:06 AM, Thierry Carrez wrote: Michael Still wrote: [...] I think an implied side effect of the runway system is that nova-drivers would -2 blueprint reviews which were not occupying a slot. (If we start doing more -2's I think we will need to explore how to not block on

Re: [openstack-dev] [devstack] Core team proposals

2014-08-08 Thread Gary Kotton
+1 From: chandankumar chandankumar.093...@gmail.commailto:chandankumar.093...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, August 8, 2014 at 2:14 PM To: OpenStack List

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Wuhongning
Does it make sense to move all advanced extension out of ML2, like security group, qos...? Then we can just talk about advanced service itself, without bothering basic neutron object (network/subnet/port) Traditionally, SG is applied in CN, and FWaas is applied in NN (bound to L3 agent),

Re: [openstack-dev] Which program for Rally

2014-08-08 Thread Anne Gentle
On Wed, Aug 6, 2014 at 5:30 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, At the TC meeting yesterday we discussed Rally program request and incubation request. We quickly dismissed the incubation request, as Rally appears to be able to live happily on top of OpenStack and

[openstack-dev] [qa] Do I need a spec for testing the compute os-networks API?

2014-08-08 Thread Matt Riedemann
This came up while reviewing the fix for bug 1327406 [1]. Basically the os-networks API behaves differently depending on your backing network manager in nova-network. We run Tempest in the gate with the FlatDHCPManager, which has the bug; if you try to list networks as a non-admin user it

Re: [openstack-dev] [qa] Do I need a spec for testing the compute os-networks API?

2014-08-08 Thread Andrea Frittoli
Thanks Matt for bringing this up/ There is a tiny start in flight here [0] - if you plan to work on providing full testing coverage for the n-net api you may want to create a spec with a link to an etherpad to help track / split the work. andrea [0] https://review.openstack.org/#/c/107552/21

Re: [openstack-dev] [qa] Do I need a spec for testing the compute os-networks API?

2014-08-08 Thread Matt Riedemann
On 8/8/2014 9:50 AM, Andrea Frittoli wrote: Thanks Matt for bringing this up/ There is a tiny start in flight here [0] - if you plan to work on providing full testing coverage for the n-net api you may want to create a spec with a link to an etherpad to help track / split the work. andrea

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

2014-08-08 Thread Jay Pipes
On 08/07/2014 01:17 PM, Ronak Shah wrote: Hi, Following a very interesting and vocal thread on GBP for last couple of days and the GBP meeting today, GBP sub-team proposes following name changes to the resource. policy-point for endpoint policy-group for endpointgroup (epg) Please reply if

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread CARVER, PAUL
Wuhongning [mailto:wuhongn...@huawei.com] wrote: Does it make sense to move all advanced extension out of ML2, like security group, qos...? Then we can just talk about advanced service itself, without bothering basic neutron object (network/subnet/port) A modular layer 3 (ML3) analogous to ML2

[openstack-dev] [Glance] Image upload/download bandwidth cap

2014-08-08 Thread Tomoki Sekiyama
Hi all, I'm considering how I can apply image download/upload bandwidth limit for glance for network QoS. There was a review for the bandwidth limit, however it is abandoned. * Download rate limiting https://review.openstack.org/#/c/21380/ Was there any discussion in the past summit about

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Kevin Benton
The existing constructs will not change. On Aug 8, 2014 9:49 AM, CARVER, PAUL pc2...@att.com wrote: Wuhongning [mailto:wuhongn...@huawei.com] wrote: Does it make sense to move all advanced extension out of ML2, like security group, qos...? Then we can just talk about advanced service itself,

Re: [openstack-dev] [Neutron][Nova] API design and usability

2014-08-08 Thread Mathieu Gagné
On 2014-08-08 8:54 AM, Andrew Laski wrote: On 08/07/2014 07:57 AM, Mathieu Gagné wrote: IMO, moving the burden of such orchestration (and garbage collection) to the end users would be a mistake. It's not a good UX at all. I could say that removing auto-creation is like having to create your

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Ivar Lazzaro
Hi Paul, Don't need to worry, you are perfectly right, GBP API is not replacing anything :). Also thanks for sharing your opinion on this matter. Thanks, Ivar. On Fri, Aug 8, 2014 at 5:46 PM, CARVER, PAUL pc2...@att.com wrote: Wuhongning [mailto:wuhongn...@huawei.com] wrote: Does it make

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Akash Gangil
Quick Question: From what I understand, GBP is a high level declarative way of configuring the network which ultimately gets mapped to basic Neutron API's via some business logic. Why can't it be in a module of it own? In that way users who want to use it can just install that and use it as an

[openstack-dev] testing performance/latency of various components?

2014-08-08 Thread Chris Friesen
Is there a straightforward way to determine where the time is going when I run a command from novaclient? For instance, if I run nova list, that's going to run novaclient, which will send a message to nova-api, which wakes up and does some processing and sends a message to nova-conductor,

Re: [openstack-dev] testing performance/latency of various components?

2014-08-08 Thread Boris Pavlovic
Chris, We working on cross service project profiler OSprofiler [1] and integrating it in all projects (including gates) Please join discussion here: https://review.openstack.org/#/c/103825/ If everting goes well we will get this feature in Juno. So we will be able to trace request cross

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Jay Pipes
On 08/08/2014 08:55 AM, Kevin Benton wrote: The existing constructs will not change. A followup question on the above... If GPB API is merged into Neutron, the next logical steps (from what I can tell) will be to add drivers that handle policy-based payloads/requests. Some of these

Re: [openstack-dev] [all] The future of the integrated release

2014-08-08 Thread Devananda van der Veen
On Fri, Aug 8, 2014 at 2:06 AM, Thierry Carrez thie...@openstack.org wrote: Michael Still wrote: [...] I think an implied side effect of the runway system is that nova-drivers would -2 blueprint reviews which were not occupying a slot. (If we start doing more -2's I think we will need

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Ivar Lazzaro
Hi Jay, You can choose. The whole purpose of this is about flexibility, if you want to use GBP API 'only' with a specific driver you just can. Additionally, given the 'ML2 like' architecture, the reference mapping driver can ideally run alongside by filling the core Neutron constructs without

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Salvatore Orlando
It might be because of the wording used, but it seems to me that you're making it sound like the group policy effort could have been completely orthogonal to neutron as we know it now. What I understood is that the declarative abstraction offered by group policy could do without any existing

[openstack-dev] What's happening with stable release management?

2014-08-08 Thread Thomas Goirand
Hi, For updating keystone from 2014.1.1 to 2014.1.2, I had to: - Upgrade oslo-config from 1.2.1 to 1.4.0.0~a3 - Upgrade oslo.messaging from 1.3.0~a9 to 1.4.0.0~a3 - Upgrade python-six from 1.6 to 1.7 - Upgrade python-pycadf from 0.4 to 0.5.1 - Add python-ldappool - Add python-oslo.db - Add

Re: [openstack-dev] [oslo] usage patterns for oslo.config

2014-08-08 Thread Vishvananda Ishaya
Hi Alistair, Modules can register their own options and there is no need to call reload_config_files. The config files are parsed and values stored in case the option is later declared. The only time you need to reload files is if you add new config files in the new module. See the example

Re: [openstack-dev] [cinder] Bug#1231298 - size parameter for volume creation

2014-08-08 Thread Vishvananda Ishaya
On Aug 8, 2014, at 6:55 AM, Dean Troyer dtro...@gmail.com wrote: On Fri, Aug 8, 2014 at 12:36 AM, Ganapathy, Sandhya sandhya.ganapa...@hp.com wrote: This is to discuss Bug #1231298 – https://bugs.launchpad.net/cinder/+bug/1231298 ... Conclusion reached with this bug is that, we need

[openstack-dev] [Neutron] Is network ordering of vNICs guaranteed?

2014-08-08 Thread CARVER, PAUL
I'm hearing friend of a friend that people have looked at the code and determined that the order of networks on a VM is not guaranteed. Can anyone confirm whether this is true? If it is true, is there any reason why this is not considered a bug? I've never seen it happen myself. To elaborate,

Re: [openstack-dev] [all] The future of the integrated release

2014-08-08 Thread Stefano Maffulli
On 08/08/2014 02:37 AM, Thierry Carrez wrote: I agree with Eoghan here. The main goal of an agile/lean system is to maximize a development team productivity. The main goal of Open source project management is not to maximize productivity. It’s to maximize contributions. I wrote about that a

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Kevin Benton
There is an enforcement component to the group policy that allows you to use the current APIs and it's the reason that group policy is integrated into the neutron project. If someone uses the current APIs, the group policy plugin will make sure they don't violate any policy constraints before

Re: [openstack-dev] [neutron] [third-party] Freescale CI log site is being blocked

2014-08-08 Thread Kevin Benton
Does your log server allow anonymous uploads that caused it to host malware or something that led to it being blocked? On Fri, Aug 8, 2014 at 7:12 AM, Kyle Mestery mest...@mestery.com wrote: Trinath: In looking at your FWaaS review [1], I noticed the site you are using for log storage is

Re: [openstack-dev] introducing cyclops

2014-08-08 Thread Doug Hellmann
On Aug 8, 2014, at 3:34 AM, Piyush Harsh h...@zhaw.ch wrote: Dear Eoghan, Thanks for your comments. Although you are correct that rating, charging, and billing policies are commercially sensitive to the operators, still if an operator has an openstack installation, I do not see why the

Re: [openstack-dev] [Ceilometer] Question on decorators in Ceilometer pecan framework

2014-08-08 Thread Pendergrass, Eric
From: David Stanek [mailto:dsta...@dstanek.com] Sent: Friday, August 08, 2014 7:25 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ceilometer] Question on decorators in Ceilometer pecan framework It looks like maybe WSME or Pecan is

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Maru Newby
On Aug 8, 2014, at 10:56 AM, Kevin Benton blak...@gmail.com wrote: There is an enforcement component to the group policy that allows you to use the current APIs and it's the reason that group policy is integrated into the neutron project. If someone uses the current APIs, the group policy

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Kevin Benton
The only issue with the separate service proxying API calls is that it can't receive requests between the service and core plugins. What kind of stability requirements were you concerned about? A response change would be similar to having a custom policy.json file where things that violate

Re: [openstack-dev] What's happening with stable release management?

2014-08-08 Thread Thierry Carrez
Thomas Goirand wrote: Hi, For updating keystone from 2014.1.1 to 2014.1.2, I had to: - Upgrade oslo-config from 1.2.1 to 1.4.0.0~a3 - Upgrade oslo.messaging from 1.3.0~a9 to 1.4.0.0~a3 - Upgrade python-six from 1.6 to 1.7 - Upgrade python-pycadf from 0.4 to 0.5.1 - Add python-ldappool

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Sumit Naiksatam
Hi Jay, To extend Ivar's response here, the core resources and core plugin configuration does not change with the addition of these extensions. The mechanism to implement the GBP extensions is via a service plugin. So even in a deployment where a GBP service plugin is deployed with a driver which

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Jay Pipes
On 08/08/2014 12:29 PM, Sumit Naiksatam wrote: Hi Jay, To extend Ivar's response here, the core resources and core plugin configuration does not change with the addition of these extensions. The mechanism to implement the GBP extensions is via a service plugin. So even in a deployment where a

Re: [openstack-dev] [neutron] [third-party] Freescale CI log site is being blocked

2014-08-08 Thread Sumit Naiksatam
Actually I am able to access the logs in this CI over the internet and through my service provider. I have copy-pasted the log from the latest freescale run here (to validate if this is indeed the latest run): http://paste.openstack.org/show/92229/ But good point Kevin, when I was trying to post

Re: [openstack-dev] [oslo] usage patterns for oslo.config

2014-08-08 Thread Doug Hellmann
On Aug 8, 2014, at 1:30 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hi Alistair, Modules can register their own options and there is no need to call reload_config_files. The config files are parsed and values stored in case the option is later declared. The only time you need to

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

2014-08-08 Thread Sumit Naiksatam
Thanks Jay for your constructive feedback on this. I personally think that 'policy-target' is a good option. I am not sure what the rest of the team thinks, perhaps they can chime in. On Fri, Aug 8, 2014 at 8:43 AM, Jay Pipes jaypi...@gmail.com wrote: On 08/07/2014 01:17 PM, Ronak Shah wrote:

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Armando M.
On 8 August 2014 10:56, Kevin Benton blak...@gmail.com wrote: There is an enforcement component to the group policy that allows you to use the current APIs and it's the reason that group policy is integrated into the neutron project. If someone uses the current APIs, the group policy plugin

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

2014-08-08 Thread Ryan Moats
+1 Sumit Naiksatam sumitnaiksa...@gmail.com wrote on 08/08/2014 02:44:55 PM: From: Sumit Naiksatam sumitnaiksa...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 08/08/2014 02:45 PM Subject: Re: [openstack-dev]

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

2014-08-08 Thread Stephen Wong
policy target sounds good. +1 On Fri, Aug 8, 2014 at 12:44 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Thanks Jay for your constructive feedback on this. I personally think that 'policy-target' is a good option. I am not sure what the rest of the team thinks, perhaps they can chime

Re: [openstack-dev] [Ceilometer] Question on decorators in Ceilometer pecan framework

2014-08-08 Thread Doug Hellmann
On Aug 8, 2014, at 8:49 AM, Pendergrass, Eric eric.pendergr...@hp.com wrote: Hi, We have been struggling to get a decorator working for proposed new RBAC functionality in ceilometer-api. We’re hitting a problem where GET request query parameters are mucked up by our decorator. Here’s

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Sumit Naiksatam
On Fri, Aug 8, 2014 at 12:45 PM, Armando M. arma...@gmail.com wrote: On 8 August 2014 10:56, Kevin Benton blak...@gmail.com wrote: There is an enforcement component to the group policy that allows you to use the current APIs and it's the reason that group policy is integrated into the neutron

Re: [openstack-dev] [Glance] Image upload/download bandwidth cap

2014-08-08 Thread Jay Pipes
On 08/08/2014 08:49 AM, Tomoki Sekiyama wrote: Hi all, I'm considering how I can apply image download/upload bandwidth limit for glance for network QoS. There was a review for the bandwidth limit, however it is abandoned. * Download rate limiting https://review.openstack.org/#/c/21380/

[openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree

2014-08-08 Thread Robert Kukura
[Note - I understand there are ongoing discussion that may lead to a proposal for an out-of-tree incubation process for new Neutron features. This is a complementary proposal that describes how our existing development process can be used to stabilize new features in-tree over the time frame

Re: [openstack-dev] [Glance] Image upload/download bandwidth cap

2014-08-08 Thread Russell Bryant
On 08/08/2014 04:17 PM, Jay Pipes wrote: On 08/08/2014 08:49 AM, Tomoki Sekiyama wrote: Hi all, I'm considering how I can apply image download/upload bandwidth limit for glance for network QoS. There was a review for the bandwidth limit, however it is abandoned. * Download rate limiting

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Prasad Vellanki
GBP is about networking policy and hence limited to networking constructs. It enhances the networking constructs. Since it follows more or less the plugin model, it is not in one monolithic module but fans out to the policy module and is done via extension. On Fri, Aug 8, 2014 at 12:45 PM,

Re: [openstack-dev] [Glance] Image upload/download bandwidth cap

2014-08-08 Thread Arnaud Legendre
+1, That’s what suggested in the blueprint a year ago: https://blueprints.launchpad.net/glance/+spec/transfer-rate-limiting It looks like consensus during summit discussion that rate limiting should be a separate facility running as a proxy in front of glance.” Thanks, Arnaud On Aug 8, 2014,

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

2014-08-08 Thread Ivar Lazzaro
That's ok for me as well! +1 On Aug 8, 2014 10:04 PM, Prasad Vellanki prasad.vella...@oneconvergence.com wrote: It sounds good +1 On Fri, Aug 8, 2014 at 12:44 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Thanks Jay for your constructive feedback on this. I personally think that

Re: [openstack-dev] [Glance] Image upload/download bandwidth cap

2014-08-08 Thread Tomoki Sekiyama
On 8/8/14 16:28 , Arnaud Legendre alegen...@vmware.commailto:alegen...@vmware.com wrote: +1, That’s what suggested in the blueprint a year ago: https://blueprints.launchpad.net/glance/+spec/transfer-rate-limiting It looks like consensus during summit discussion that rate limiting should be a

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis

2014-08-08 Thread Brent Eagles
On Wed, Aug 06, 2014 at 01:40:28PM +0800, Tom Fifield wrote: snip/ While DB migrations are running things like the nova metadata service can/will misbehave - and user code within instances will be affected. Thats arguably VM downtime. OTOH you could define it more narrowly as 'VMs are not

Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

2014-08-08 Thread Russell Bryant
On 08/08/2014 09:06 AM, Russell Bryant wrote: - instead implement a third party CI with the latest available libvirt release [1] As for the general idea of doing CI, absolutely. That was discussed earlier in the thread, though nobody has picked up the ball yet. I can work on it, though.

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

2014-08-08 Thread Henry Fourie
+1 for policy-target -Original Message- From: Sumit Naiksatam [mailto:sumitnaiksa...@gmail.com] Sent: Friday, August 08, 2014 12:45 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming Thanks Jay

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis

2014-08-08 Thread Russell Bryant
On 08/06/2014 01:41 PM, Jay Pipes wrote: On 08/06/2014 01:40 AM, Tom Fifield wrote: On 06/08/14 13:30, Robert Collins wrote: On 6 August 2014 17:27, Tom Fifield t...@openstack.org wrote: On 06/08/14 13:24, Robert Collins wrote: What happened to your DB migrations then? :) Sorry if I

Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree

2014-08-08 Thread Ivar Lazzaro
Hi Robert, I think this is a great proposal. Easy to understand and (at a first glance) easy to implement. Also, it seems the perfect compromise for those who wanted GBP (as a representative for this kind of extension) in tree, and those who wanted it to be more mature first. Fwiw, You have my

Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree

2014-08-08 Thread Sumit Naiksatam
On Fri, Aug 8, 2014 at 1:21 PM, Robert Kukura kuk...@noironetworks.com wrote: [Note - I understand there are ongoing discussion that may lead to a proposal for an out-of-tree incubation process for new Neutron features. This is a complementary proposal that describes how our existing

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Armando M.
Adding the GBP extension to Neutron does not change the nature of the software architecture of Neutron making it more or less monolithic. I agree with this statement...partially: the way GBP was developed is in accordance to the same principles and architectural choices made for the service

  1   2   >