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

Like the policy-group naming. The policy-target is better than policy-point, but still feel there's some little confusing, as the target is usually meaning what it's for, but not what it's on. Hence, the policy-endpoint might be more exact. On Fri, Aug 8, 2014 at 11:43 PM, Jay Pipes wrote: >

Re: [openstack-dev] Get Tenant Details in novaclient

this spec has some thought on functionality to validate the tenant or user that is consumed by nova, not sure whether it's what you want, FYI https://review.openstack.org/#/c/92507/ Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: j

Re: [openstack-dev] [neutron] [third-party] Update on third party CI in Neutron

Hi, Mellanox CI was also failing due to the same issue, https://bugs.launchpad.net/neutron/+bug/1355780 (apparently duplicated bug for https://bugs.launchpad.net/neutron/+bug/1353309) We currently fixed the issue locally, by patching the server side RPC version support to 1.3. BR, Irena From:

Re: [openstack-dev] [Nova] PCI support

Hi Gary, I understand your concern. I think CI is mandatory to ensure that code is not broken. While unit tests provide great value, it may end up with the code that does not work... I am not sure how this code can be checked for validity without running the neutron part. Probably our CI job sho

[openstack-dev] Get Tenant Details in novaclient

Hi, nova --os-tenant-name admin list --tenant c40ad5830e194f2296ad11a96cefc487 --all-tenants 1 - Works Fine and returns all the servers available where "c40ad5830e194f2296ad11a96cefc487 " is the id of the demo tenant whereas nova --os-tenant-name admin list --tenant demo --all-tenants 1 - Retur

Re: [openstack-dev] [neutron] [third-party] Update on third party CI in Neutron

Anita, Yes, I'm the contact for One Convergence CI. Thanks, -hemanth On Tue, Aug 12, 2014 at 3:12 PM, Anita Kuno wrote: > On 08/12/2014 03:23 PM, Hemanth Ravi wrote: > > Kyle, > > > > One Convergence third-party CI is failing due to > > https://bugs.launchpad.net/neutron/+bug/1353309. > > > >

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

On Wed, Aug 13, 2014 at 4:26 AM, Eoghan Glynn wrote: > >> It seems like this is exactly what the slots give us, though. The core review >> team picks a number of slots indicating how much work they think they can >> actually do (less than the available number of blueprints), and then >> blueprints

Re: [openstack-dev] [nova] Retrospective veto revert policy

On Wed, Aug 13, 2014 at 11:36 AM, Russell Bryant wrote: >> On Aug 12, 2014, at 5:10 PM, Michael Still wrote: >> >> This looks reasonable to me, with a slight concern that I don't know >> what step five looks like... What if we can never reach a consensus on >> an issue? > > In an extreme case, th

Re: [openstack-dev] Openstack Capacity Planning

Hi Adam, Please refer this https://wiki.openstack.org/wiki/Blazar. Hope it's helpful. Cheers. On 13/08/14 12:54, Adam Lawson wrote: > Something was presented at a meeting recently which had me curious: > what sort of capacity planning tools/capabilities are being developed > as an Openstack progr

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

hi GBPer, I couldn't have been at the IRC meeting for the time difference, are there any conclusion for this topic, or is it still open? I've tried to collect main concerns from previous posts (if something is lost or mistaken, just let me know): Concern 1: GBP is too heavy to be merged into N

Re: [openstack-dev] [nova] Retrospective veto revert policy

> On Aug 12, 2014, at 5:10 PM, Michael Still wrote: > > This looks reasonable to me, with a slight concern that I don't know > what step five looks like... What if we can never reach a consensus on > an issue? In an extreme case, the PTL has the authority to make the call. In general I would

Re: [openstack-dev] [nova] Retrospective veto revert policy

On 8/12/2014 4:03 PM, Michael Still wrote: This looks reasonable to me, with a slight concern that I don't know what step five looks like... What if we can never reach a consensus on an issue? Michael On Wed, Aug 13, 2014 at 12:56 AM, Mark McLoughlin wrote: Hey (Terrible name for a policy,

Re: [openstack-dev] [nova] Retrospective veto revert policy

Actually, thinking on this more -- the lack of consensus is on the attempt to re-add the patch, so I guess we'd handle that just like we do for a contentious patch now. Michael On Wed, Aug 13, 2014 at 7:03 AM, Michael Still wrote: > This looks reasonable to me, with a slight concern that I don't

[openstack-dev] Openstack Capacity Planning

Something was presented at a meeting recently which had me curious: what sort of capacity planning tools/capabilities are being developed as an Openstack program? It's another area where non-proprietary cloud control is needed and would be another way to kick a peg away from the stool of cloud resi

Re: [openstack-dev] introducing cyclops

I am also highly interested. A very large adoption inhibitor has been the ability to control cloud consumption with charge-back and/or cost center billing support. Would love to talk about this. *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-fre

Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase

On Tuesday, August 12, 2014 10:14 PM, Julien Danjou wrote: > The py33 gate shouldn't be activated for the stable/icehouse. I'm no > infra-config expert, but we should be able to patch it for that (hint?). Thank you for the response. Now we have two choices: (1) deter to activate the py33 gate (

[openstack-dev] [Infra] Minesweeper behaving badly

Hi, VMware minesweeper caused havoc today causing exhaustion of the upstream node pool. The account has been disabled so things are back to normal now. The root cause of the issue was super easy once we realized we missed [1]. I would like to apologise to the whole community on behalf of the VMwa

Re: [openstack-dev] [OpenStack-Dev] [Cinder] 3'rd party CI systems

I forked jaypipe’s repos & working on extending it to support nodepool, log server, etc. Still WIP but generally working. If you need help, ping me on IRC #openstack-cinder (asselin) Ramy From: Jesse Pretorius [mailto:jesse.pretor...@gmail.com] Sent: Monday, August 11, 2014 11:33 PM To: OpenSta

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

On Tue, Aug 12, 2014 at 12:23 AM, Mark McLoughlin wrote: > On Mon, 2014-08-11 at 15:25 -0700, Joe Gordon wrote: > > > > > > > > On Sun, Aug 10, 2014 at 11:59 PM, Mark McLoughlin > > wrote: > > On Fri, 2014-08-08 at 09:06 -0400, Russell Bryant wrote: > > > On 08/07/2014 08:06 PM,

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Eric, If you can give us some more information about your end goal, independent of the implementation, maybe we can propose an alternate technique to achieve the same thing. Doug On Aug 12, 2014, at 6:21 PM, Ryan Petrello wrote: > Yep, you're right, this doesn't seem to work. The issue is t

Re: [openstack-dev] [TripleO][Heat] reverting the HOT migration? // dealing with lockstep changes

On 13 August 2014 11:05, Robert Collins wrote: > I've reproduced the problem with zane's fix for the validation error - > and it does indeed still break: > "| stack_status_reason | StackValidationFailed: Property error : > NovaCompute6: > | | key_name Value must be a string

Re: [openstack-dev] [TripleO][Heat] reverting the HOT migration? // dealing with lockstep changes

On 12 August 2014 10:46, Robert Collins wrote: > On 12 August 2014 07:24, Dan Prince wrote: >> On Tue, 2014-08-12 at 06:58 +1200, Robert Collins wrote: >>> Hi, so shortly after the HOT migration landed, we hit >>> https://bugs.launchpad.net/tripleo/+bug/1354305 which is that on even >>> quite rec

[openstack-dev] [nova][core] Expectations of core reviewers

Hi. One of the action items from the nova midcycle was that I was asked to make nova's expectations of core reviews more clear. This email is an attempt at that. Nova expects a minimum level of sustained code reviews from cores. In the past this has been generally held to be in the order of two c

Re: [openstack-dev] [UX] [Horizon] [Heat] Merlin project (formerly known as cross-project UI library for Heat/Mistral/Murano/Solum) plans for PoC and more

On 8/6/14, 1:41 PM, "Timur Sufiev" wrote: >Hi, folks! > >Two months ago there was an announcement in ML about gathering the >requirements for cross-project UI library for >Heat/Mistral/Murano/Solum [1]. The positive feedback in related >googledoc [2] and some IRC chats and emails that followed co

[openstack-dev] [Neutron] Ryu plugin deprecation

hi, As announced in the last neutron meeting [1], the Ryu plugin is being deprecated. Juno is the last release to support Ryu plugin. The Ryu team will be focusing on the ofagent going forward. btw, i'll be mostly offline from Aug 16 to Aug 31. sorry for inconvenience. [1] http://eavesdrop.ope

[openstack-dev] [TripleO] lists and merges

Just ran into a merge conflict with https://review.openstack.org/#/c/105878/ which looks like this: - name: nova_osapi port: 8774 net_binds: *public_binds - name: nova_metadata port: 8775 net_binds: *public_binds

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Yep, you're right, this doesn't seem to work. The issue is that security is enforced at routing time (while the controller is still actually being discovered). In order to do this sort of thing with the `check_permissions`, we'd probably need to add a feature to pecan. On 08/12/14 06:38 PM, Pend

Re: [openstack-dev] [OpenStack][Docker][HEAT] Cloud-init and docker container

Thanks Eric for the confirmation ;-) 2014-08-12 23:30 GMT+08:00 Eric Windisch : > > > > On Tue, Aug 12, 2014 at 5:53 AM, Jay Lau wrote: > >> I did not have the environment set up now, but by reviewing code, I think >> that the logic should be as following: >> 1) When using nova docker driver, w

Re: [openstack-dev] [neutron] [third-party] Update on third party CI in Neutron

On 08/12/2014 03:23 PM, Hemanth Ravi wrote: > Kyle, > > One Convergence third-party CI is failing due to > https://bugs.launchpad.net/neutron/+bug/1353309. > > Let me know if we should turn off the CI logs until this is fixed or if we > need to fix anything on the CI end. I think one other third-

Re: [openstack-dev] [nova] Retrospective veto revert policy

Should subsequent patches be reverted as well that depended on the change in question? On Tue, Aug 12, 2014 at 7:56 AM, Mark McLoughlin wrote: > Hey > > (Terrible name for a policy, I know) > > From the version_cap saga here: > > https://review.openstack.org/110754 > > I think we need a bette

Re: [openstack-dev] [neutron] [third-party] Update on third party CI in Neutron

Kyle, One Convergence third-party CI is failing due to https://bugs.launchpad.net/neutron/+bug/1353309. Let me know if we should turn off the CI logs until this is fixed or if we need to fix anything on the CI end. I think one other third-party CI (Mellanox) is failing due to the same issue. Reg

Re: [openstack-dev] [Heat] SoftwareDeployment resource is always in progress

On 11/08/14 20:42, david ferahi wrote: > Hello, > > I 'm trying to create a simple stack with heat (Icehouse release). > The template contains SoftwareConfig, SoftwareDeployment and a single > server resources. > > The problem is that the SoftwareDeployment resource is always in > progress ! > So f

Re: [openstack-dev] [Nova] Nominating Jay Pipes for nova-core

On Wed, 2014-07-30 at 14:02 -0700, Michael Still wrote: > Greetings, > > I would like to nominate Jay Pipes for the nova-core team. > > Jay has been involved with nova for a long time now. He's previously > been a nova core, as well as a glance core (and PTL). He's been around > so long that the

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

On Tue, Aug 12, 2014 at 11:08 AM, Doug Hellmann wrote: > > On Aug 12, 2014, at 1:44 PM, Dolph Mathews > wrote: > > > On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon > wrote: > >> >> >> >> On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery wrote: >> >>> On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon >>> wr

Re: [openstack-dev] [nova] so what do i do about libvirt-python if i'm on precise?

On Wed, 2014-07-30 at 15:34 -0700, Clark Boylan wrote: > On Wed, Jul 30, 2014, at 03:23 PM, Jeremy Stanley wrote: > > On 2014-07-30 13:21:10 -0700 (-0700), Joe Gordon wrote: > > > While forcing people to move to a newer version of libvirt is > > > doable on most environments, do we want to do that

Re: [openstack-dev] [nova] Retrospective veto revert policy

This looks reasonable to me, with a slight concern that I don't know what step five looks like... What if we can never reach a consensus on an issue? Michael On Wed, Aug 13, 2014 at 12:56 AM, Mark McLoughlin wrote: > Hey > > (Terrible name for a policy, I know) > > From the version_cap saga here

Re: [openstack-dev] [nova] Retrospective veto revert policy

On Tue, Aug 12, 2014 at 9:56 AM, Mark McLoughlin wrote: > Hey > > (Terrible name for a policy, I know) > > From the version_cap saga here: > > https://review.openstack.org/110754 > > I think we need a better understanding of how to approach situations > like this. > > Here's my attempt at docum

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Le 12/08/2014 18:54, Nikola Đipanov a écrit : On 08/12/2014 04:49 PM, Sylvain Bauza wrote: (sorry for reposting, missed 2 links...) Hi Nikola, Le 12/08/2014 12:21, Nikola Đipanov a écrit : Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need

Re: [openstack-dev] [nova] Retrospective veto revert policy

Dan Smith wrote: >> Looks reasonable to me. > > +1 +1 -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

On 08/12/2014 03:40 PM, Kashyap Chamarthy wrote: > On Mon, Aug 11, 2014 at 08:05:26AM -0400, Russell Bryant wrote: >> On 08/11/2014 07:58 AM, Russell Bryant wrote: >>> On 08/11/2014 05:53 AM, Daniel P. Berrange wrote: There is work to add support for this in devestack already which I pref

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

On 08/12/2014 01:16 PM, Edgar Magana wrote: > Henry, > > That makes a lot of sense to me. > If the code will be remove in Juno, then there is nothing else to discuss. > > Thank you so much for providing detailed information and sorry for > bothering you with this issue. > > Edgar I don't think i

[openstack-dev] [Octavia] Agenda for 13 Aug 2014 meeting

Hi folks! This is what I have for my tentative agenda for tomorrow's Octavia meeting. Please e-mail me if you want anything else added to this list. (Also, I will start putting these weekly agendas in the wiki in the near future.) * Discuss future of Octavia in light of Neutron-incubator project

[openstack-dev] [NFV] Meeting cancelled and time for next week.

Hi all, I am not available to run the meeting tomorrow and was not able to identify someone to step in, given this I think it makes sense to cancel for this week. For next week I would like to trial the new alternate time we discussed, 1600 UTC on a Thursday, and assuming there is reasonable a

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

On Mon, Aug 11, 2014 at 08:05:26AM -0400, Russell Bryant wrote: > On 08/11/2014 07:58 AM, Russell Bryant wrote: > > On 08/11/2014 05:53 AM, Daniel P. Berrange wrote: > >> There is work to add support for this in devestack already which I > >> prefer since it makes it easy for developers to get an e

Re: [openstack-dev] [Neutron][LBaaS] Use cases with regards to VIP and routers

>From the perspective of Blue Box: * Load balancing appliances will often (usually?) live outside the same subnet as back-end member VMs. * The network in which the load balancing appliances live will usually have a default router (gateway) * We don't anticipate the need for using extra_routes at

[openstack-dev] [Neutron] [LBaaS] Followup on Service Ports and IP Allocation - IPAM from LBaaS Mid Cycle meeting

Hi Mark, Going through the notes from our midcycle meeting (see https://etherpad.openstack.org/p/juno-lbaas-mid-cycle-hackathon) I noticed your name next to the Service Port and IPAM: Service Ports * Owner: Mark * Nova hacks * Nova port that nova borrows but doesn't

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

Henry, That makes a lot of sense to me. If the code will be remove in Juno, then there is nothing else to discuss. Thank you so much for providing detailed information and sorry for bothering you with this issue. Edgar On 8/12/14, 11:49 AM, "Henry Gessau" wrote: >On 8/12/2014 2:04 PM, Jeremy

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

On Tue, Aug 12, 2014 at 1:08 PM, Doug Hellmann wrote: > > On Aug 12, 2014, at 1:44 PM, Dolph Mathews > wrote: > > > On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon > wrote: > >> >> >> >> On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery wrote: >> >>> On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon >>> wro

Re: [openstack-dev] [nova] 9 days until feature proposal freeze

On 08/12/2014 04:13 AM, Michael Still wrote: Hi, this is just a friendly reminder that we are now 9 days away from feature proposal freeze for nova. If you think your blueprint isn't going to make it in time, then now would be a good time to let me know so that we can defer it until Kilo. That w

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

On 8/12/2014 2:04 PM, Jeremy Stanley wrote: > On 2014-08-12 16:35:18 + (+), Edgar Magana wrote: >> If this plugin will be deprecated in Juno it means that the code >> will be there for this release, I will expect to have the CI still >> running for until the code is completely removed from

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Sure, here's the decorated method from v2.py: class MetersController(rest.RestController): """Works on meters.""" @pecan.expose() def _lookup(self, meter_name, *remainder): return MeterController(meter_name), remainder @wsme_pecan.wsexpose([Meter],

Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

On 8/12/2014 1:53 PM, Ihar Hrachyshka wrote: > On 12/08/14 17:12, Henry Gessau wrote: >> On 8/12/2014 10:27 AM, Ihar Hrachyshka wrote: >>> as per [1], Cisco Nexus ML2 plugin requires a patched version of >>> ncclient from github. I wonder: >>> >>> - - whether this information is still current; >>

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

> It seems like this is exactly what the slots give us, though. The core review > team picks a number of slots indicating how much work they think they can > actually do (less than the available number of blueprints), and then > blueprints queue up to get a slot based on priorities and turnaround

[openstack-dev] [Horizon] Feature Proposal Freeze date Aug 14

It came to my attention today that I've only communicated this in Horizon team meetings. Due to the high number of blueprints already targeting Juno-3 and the resource contention of reviewers, I have set the Horizon Feature Proposal Deadline at August 14 (August 12 actually, but since I didn't inc

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

On Aug 12, 2014, at 11:08 AM, Doug Hellmann wrote: > > On Aug 12, 2014, at 1:44 PM, Dolph Mathews wrote: > >> >> On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon wrote: >> >> >> >> On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery wrote: >> On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon wrote: >> >

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

On Tue, Aug 12, 2014 at 10:44 AM, Dolph Mathews wrote: > > On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon wrote: >> >> Slow review: by limiting the number of blueprints up we hope to focus our >> efforts on fewer concurrent things >> slow code turn around: when a blueprint is given a slot (runway)

Re: [openstack-dev] [Neutron][QA] Enabling full neutron Job

And just when the patch was only missing a +A, another bug slipped in! The nova patch to fix it is available at [1] And while we're there, it won't be a bad idea to also push the neutron full job, as non-voting, into the integrated gate [2] Thanks in advance, (especially to the nova and infra cor

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

On Aug 12, 2014, at 1:44 PM, Dolph Mathews wrote: > > On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon wrote: > > > > On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery wrote: > On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon wrote: > > > > > > > > On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez > > wro

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

On 2014-08-12 16:35:18 + (+), Edgar Magana wrote: > If this plugin will be deprecated in Juno it means that the code > will be there for this release, I will expect to have the CI still > running for until the code is completely removed from the Neutron > tree. > > Anyway, Infra guys will

Re: [openstack-dev] [nova] Retrospective veto revert policy

On Tue, Aug 12, 2014 at 03:56:44PM +0100, Mark McLoughlin wrote: > Hey > > (Terrible name for a policy, I know) > > From the version_cap saga here: > > https://review.openstack.org/110754 > > I think we need a better understanding of how to approach situations > like this. > > Here's my atte

Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/08/14 17:12, Henry Gessau wrote: > On 8/12/2014 10:27 AM, Ihar Hrachyshka wrote: >> as per [1], Cisco Nexus ML2 plugin requires a patched version of >> ncclient from github. I wonder: >> >> - - whether this information is still current; > >

Re: [openstack-dev] Which program for Rally

On Mon, Aug 11, 2014 at 07:06:11PM -0400, Zane Bitter wrote: > On 11/08/14 16:21, Matthew Treinish wrote: > >I'm sorry, but the fact that the > >docs in the rally tree has a section for user testimonials [4] I feel speaks > >a > >lot about the intent of the project. > > What... does that even mea

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

On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon wrote: > > > > On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery wrote: > >> On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon wrote: >> > >> > >> > >> > On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez >> > wrote: >> >> >> >> Hi everyone, >> >> >> >> With the in

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Can you share some code? What do you mean by, "is there a way for the decorator code to know it was called by MetersController.get_all" On 08/12/14 04:46 PM, Pendergrass, Eric wrote: > Thanks Ryan, but for some reason the controller attribute is None: > > (Pdb) from pecan.core import state > (Pd

Re: [openstack-dev] [keystone] Configuring protected API functions to allow public access

On Tue, Aug 12, 2014 at 10:30 AM, Yee, Guang wrote: > Hi Kristy, > > Have you try the "[]" or "@" rule as mentioned here? > That still requires valid authentication though, just not any specific authorization. I don't think we have a way to express truly public resources in oslo.policy. > > >

Re: [openstack-dev] [neutron] Feature Proposal Freeze is 9 days away

If you know it won't make it, please let me know so I can remove your BP from the LP milestone. Thanks! Kyle On Tue, Aug 12, 2014 at 11:18 AM, Mohammad Banikazemi wrote: > What would be the best practice for those who realize their work will not > make it in Juno? Is it enough to not submit co

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

On 08/12/2014 04:49 PM, Sylvain Bauza wrote: > (sorry for reposting, missed 2 links...) > > Hi Nikola, > > Le 12/08/2014 12:21, Nikola Đipanov a écrit : >> Hey Nova-istas, >> >> While I was hacking on [1] I was considering how to approach the fact >> that we now need to track one more thing (NUMA

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Thanks Ryan, but for some reason the controller attribute is None: (Pdb) from pecan.core import state (Pdb) state.__dict__ {'hooks': [, , , ], 'app': , 'request': http://localhost:8777/v2/meters>, 'controller': None, 'response': } > -Original Message- > From: Ryan Petrello [mailto:rya

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

If this plugin will be deprecated in Juno it means that the code will be there for this release, I will expect to have the CI still running for until the code is completely removed from the Neutron tree. Anyway, Infra guys will have the last word here! Edgar On 8/11/14, 5:38 PM, "Anita Kuno" wr

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

This should give you what you need: from pecan.core import state state.controller On 08/12/14 04:08 PM, Pendergrass, Eric wrote: > Hi, I'm trying to use the built in secure decorator in Pecan for access > control, and I'ld like to get the name of the method that is wrapped from > within the dec

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

On 11 August 2014 21:03, Dean Troyer wrote: > On Mon, Aug 11, 2014 at 5:34 PM, Duncan Thomas > wrote: >> >> Making an previously mandatory parameter optional, at least on the >> command line, does break backward compatibility though, does it? >> Everything that worked before will still work. > >

Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Do u know if ceilometer is using six.wraps? If so, that helper adds in the `__wrapped__` attribute to decorated methods (which can be used to find the original decorated function). If just plain functools are used (and python3.x isn't used) then it will be pretty hard afaik to find the origin

Re: [openstack-dev] [Neutron][LBaaS] Continuing on "Calling driver interface on every API request"

Hi, I think we are debating some edge-case. An important part of the flavor framework is the ability of me the operator to say failover from Octavia to an F5. So as an operator I would ensure to only offer the features in that flavor which both support. So in order to arrive at Brandon’s exampl

Re: [openstack-dev] [neutron] Feature Proposal Freeze is 9 days away

What would be the best practice for those who realize their work will not make it in Juno? Is it enough to not submit code for review? Would it be better to also request a change in milestone? Thanks, Mohammad From: Kyle Mestery To: "OpenStack Development Mailing List (not for usage q

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

Per the blueprint spec [1], what has been proposed are optional extensions which complement the existing Neutron core resources' model: " The main advantage of the extensions described in this blueprint is that they allow for an application-centric interface to Neutron that complements the existin

Re: [openstack-dev] [nova] Retrospective veto revert policy

On Tue, Aug 12, 2014 at 8:46 AM, Jay Pipes wrote: > On 08/12/2014 10:56 AM, Mark McLoughlin wrote: > >> Hey >> >> (Terrible name for a policy, I know) >> >> From the version_cap saga here: >> >>https://review.openstack.org/110754 >> >> I think we need a better understanding of how to approac

[openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?

Hi, I'm trying to use the built in secure decorator in Pecan for access control, and I'ld like to get the name of the method that is wrapped from within the decorator. For instance, if I'm wrapping MetersController.get_all with an @secure decorator, is there a way for the decorator code to know

Re: [openstack-dev] [nova] Retrospective veto revert policy

On Tue, Aug 12, 2014 at 9:56 AM, Mark McLoughlin wrote: > Hey > > (Terrible name for a policy, I know) > > From the version_cap saga here: > > https://review.openstack.org/110754 > > I think we need a better understanding of how to approach situations > like this. > > Here's my attempt at docume

Re: [openstack-dev] introducing cyclops

On Tue, Aug 12, 2014 at 05:47:49PM +1200, Fei Long Wang wrote: > Our suggestion for the first IRC meeting is 25/August 8PM-10PM UTC time on > Freenodes's #openstack-rating channel. > > Thoughts? Please reply with the best date/time for you so we can figure out a > time to start. > I'll like to p

Re: [openstack-dev] [nova] Retrospective veto revert policy

On 08/12/2014 10:56 AM, Mark McLoughlin wrote: Hey (Terrible name for a policy, I know) From the version_cap saga here: https://review.openstack.org/110754 I think we need a better understanding of how to approach situations like this. Here's my attempt at documenting what I think we're

Re: [openstack-dev] [keystone] Configuring protected API functions to allow public access

Hi Kristy, Have you try the "[]" or "@" rule as mentioned here? https://github.com/openstack/keystone/blob/master/keystone/openstack/common/ policy.py#L71 Guang > -Original Message- > From: K.W.S.Siu [mailto:k.w.s@kent.ac.uk] > Sent: Tuesday, August 12, 2014 3:44 AM > To: opensta

Re: [openstack-dev] [OpenStack][Docker][HEAT] Cloud-init and docker container

On Tue, Aug 12, 2014 at 5:53 AM, Jay Lau wrote: > I did not have the environment set up now, but by reviewing code, I think > that the logic should be as following: > 1) When using nova docker driver, we can use cloud-init or/and CMD in > docker images to run post install scripts. > myapp: >

Re: [openstack-dev] Gantt project

Thanks for the info. It does seem like most OpenStack projects have some concept of a "scheduler", as you mentioned. Perhaps that's expected in any distributed system. Is it expected or assumed that Gantt will become the common scheduler for all OpenStack projects? That is, is Gantt's plan and/

Re: [openstack-dev] [nova] Retrospective veto revert policy

> Looks reasonable to me. +1 --Dan signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

On 8/12/2014 10:27 AM, Ihar Hrachyshka wrote: > as per [1], Cisco Nexus ML2 plugin requires a patched version of > ncclient from github. I wonder: > > - - whether this information is still current; Please see: https://review.openstack.org/112175 But we need to do backports before updating the wi

Re: [openstack-dev] [nova] Retrospective veto revert policy

On 08/12/2014 10:56 AM, Mark McLoughlin wrote: > Hey > > (Terrible name for a policy, I know) > > From the version_cap saga here: > > https://review.openstack.org/110754 > > I think we need a better understanding of how to approach situations > like this. > > Here's my attempt at documenting

[openstack-dev] [nova] Retrospective veto revert policy

Hey (Terrible name for a policy, I know) >From the version_cap saga here: https://review.openstack.org/110754 I think we need a better understanding of how to approach situations like this. Here's my attempt at documenting what I think we're expecting the procedure to be: https://etherpad

Re: [openstack-dev] [oslo] oslo.concurrency repo review

On Tue, Aug 12 2014, Joshua Harlow wrote: […] > What do u think about waiting until pylockfile is ready and avoiding 1-4 > from above? At least if taskflow uses tooz I surely don't want taskflow to > have to deal with #1-4 (which it will inherit from tooz if taskflow starts > to use tooz by the v

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

(sorry for reposting, missed 2 links...) Hi Nikola, Le 12/08/2014 12:21, Nikola Đipanov a écrit : Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need to track one more thing (NUMA node utilization) in our resources. I went with - "I'll add it

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Hi Nikola, Le 12/08/2014 12:21, Nikola Đipanov a écrit : Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need to track one more thing (NUMA node utilization) in our resources. I went with - "I'll add it to compute nodes table" thinking it's a fu

Re: [openstack-dev] [oslo] oslo.concurrency repo review

Sure, thats great as to why a feature like it might exist (and I think such a feature is great to have, for cases when a bigger *distributed* system isn't desired). Just the one there taken from lockutils has some issues that IMHO I think tooz would be better to avoid for the time-being (until

[openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hey all, as per [1], Cisco Nexus ML2 plugin requires a patched version of ncclient from github. I wonder: - - whether this information is still current; - - why don't we depend on ncclient thru our requirements.txt file. [1]: https://wiki.openstac

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

These changes have been completed. Welcome Ian! dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Implications of moving functional tests to projects (was Re: Which program for Rally)

Changing subject line to continue thread about new $subj On 08/12/2014 08:56 AM, Doug Hellmann wrote: On Aug 11, 2014, at 12:00 PM, David Kranz > wrote: On 08/06/2014 05:48 PM, John Griffith wrote: I have to agree with Duncan here. I also don't know if I fully und

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

On 08/12/2014 05:54 AM, Daniel P. Berrange wrote: >> I am less concerned about the contents of this patch, and more concerned >> with how such a big de facto change in nova policy (we accept untested code >> sometimes) without any discussion or consensus. In your comment on the >> revert [2], you s

Re: [openstack-dev] [Nova] PCI support

Thanks, the concern is for the code in Nova and not in Neutron. That is, there is quite a lot of PCI code being added and no way of knowing that it actually works (unless we trust the developers working on it :)). Thanks Gary From: Irena Berezovsky mailto:ire...@mellanox.com>> Date: Tuesday, Aug

Re: [openstack-dev] [Ceilometer] Add a pollster plugin

On Aug 12, 2014, at 4:11 AM, Duan, Li-Gong (Gary@HPServers-Core-OE-PSC) wrote: > Hi Folks, > > Is there any best practices or good way to debug whether new pollster plugin > work fine for ceilometer? > > I’d like to add a new pollster plugin into Ceilometer by > - adding a new item un

Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase

On Tue, Aug 12 2014, Osanai, Hisashi wrote: > I did cherry-pick for "https://bugs.launchpad.net/ceilometer/+bug/1326250"; > and > executed git review (https://review.openstack.org/#/c/112806/). > > In review phase I got the error message from Jenkins. > The reason of the error is happybase-0.8 (

Re: [openstack-dev] [oslo] oslo.concurrency repo review

On Mon, Aug 11 2014, Joshua Harlow wrote: > Sounds great, I've been wondering why > https://github.com/stackforge/tooz/commit/f3e11e40f9871f8328 happened/merged > (maybe it should be changed?). For the simple reason that there's people wanting to use a lock distributed against several processes w

[openstack-dev] [neutron] Feature Proposal Freeze is 9 days away

Just a reminder that Neutron observes FPF [1], and it's 9 days away. We have an incredible amount of BPs which do not have code submitted yet. My suggestion to those who own one of these BPs would be to think hard about whether or not you can realistically land this code in Juno before jamming thin

  1   2   >