Re: [openstack-dev] [Trove] Should we stop using wsgi-intercept, now that it imports from mechanize? this is really bad!

2014-07-27 Thread Thomas Goirand
On 07/27/2014 12:22 AM, Denis Makogon wrote: суббота, 26 июля 2014 г. пользователь Thomas Goirand написал: At this point, I gave-up with mechanize. But then, this makes me wonder: can we continue to use wsgi-intercept if it depends on such a bad Python module. If we are to

Re: [openstack-dev] [Neutron][LBaaS] DB layer - Specific exceptions when resource cant be found. Do they have any added value?

2014-07-27 Thread Avishay Balderman
The same applies for the ‘XInUse’ exception – we have specific exception for each entity that is ‘inUse’ Examples: HealthMonitorInUse PoolInUse etc I think that EnityInUse exception is good enough Avishay From: Avishay Balderman Sent: Thursday, July 24, 2014 10:20 AM To: OpenStack Development

Re: [openstack-dev] [neutron][SR-IOV]: RE: ML2 mechanism driver for SR-IOV capable NIC based switching, ...

2014-07-27 Thread Irena Berezovsky
Hi Robert, Please see inline -Original Message- From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Friday, July 25, 2014 12:44 AM To: mest...@mestery.com; Irena Berezovsky Cc: Akihiro Motoki; Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Neutron][LBaaS] new common module for Barbican TLS containers interaction

2014-07-27 Thread Evgeny Fedoruk
Carlos, The module skeleton, including API functions and their brief description, was committed at https://review.openstack.org/#/c/109849/ checkContainerExistance -should be used by LBaaS API, I will merge it into TLS implementation change.

Re: [openstack-dev] [Trove] Should we stop using wsgi-intercept, now that it imports from mechanize? this is really bad!

2014-07-27 Thread Chris Dent
On Sun, 27 Jul 2014, Thomas Goirand wrote: I don't think you get it. The question isn't to fix Trove to be ready for Py3.4, we're very far from that. The question is: how can I maintain the python-wsgi-intercept package in Debian, when it now depends on a very bad package in the newer version

Re: [openstack-dev] [tc][rally][qa] Application for a new OpenStack Program: Performance and Scalability

2014-07-27 Thread Sean Dague
On 07/26/2014 05:51 PM, Hayes, Graham wrote: On Tue, 2014-07-22 at 12:18 -0400, Sean Dague wrote: On 07/22/2014 11:58 AM, David Kranz wrote: On 07/22/2014 10:44 AM, Sean Dague wrote: Honestly, I'm really not sure I see this as a different program, but is really something that should be folded

Re: [openstack-dev] [Trove] Should we stop using wsgi-intercept, now that it imports from mechanize? this is really bad!

2014-07-27 Thread Thomas Goirand
On 07/27/2014 09:54 PM, Chris Dent wrote: I maintain wsgi-intercept, and I'm happy to remove mechanize if that's really necessary. I didn't want it in there but when someone asked for it to be back in there was insufficient objection so back in it went.

Re: [openstack-dev] [Neutron] minimal device driver for VPN

2014-07-27 Thread Julio Carlos Barrera Juez
I have in my q-svc log this line: 2014-07-27 19:46:02.243 DEBUG neutron.service [-] service_providers.service_provider = ['VPN:fake_junos_vpnaas:neutron.services.vpn.service_drivers.fake_service_driver.FakeServiceDriver:default'] from (pid=2770) log_opt_values

Re: [openstack-dev] [Trove] Should we stop using wsgi-intercept, now that it imports from mechanize? this is really bad!

2014-07-27 Thread Chris Dent
On Mon, 28 Jul 2014, Thomas Goirand wrote: That's exactly the version which I've been looking at. The thing is, when I run the unit test with that version, it just bombs on me because mechanize isn't there. How would you feel about it being optionally available and for the tests for mechanize

[openstack-dev] [nova]Blueprint update: a lightweight proposal for fast booting many homogeneous virtual machines

2014-07-27 Thread quanyongf

[openstack-dev] [Neutron][LBaaS][Tempest] LBaaS V2 testing, partial results

2014-07-27 Thread Miguel Lavalle
Hi, I spent a few hours deploying LBaaS V2 to my devstack instance and tested it with the Tempest api test developed a couple of week ago during the Neutron code sprint. This is a list of the findings so far: 1) POST operations on loadbalancers, healthmonitors and listeners work fine 2) POST

Re: [openstack-dev] debug logs and defaults was (Thoughts on the patch test failure rate and moving forward)

2014-07-27 Thread Tom Fifield
On 25/07/14 06:05, Robert Collins wrote: On 25 July 2014 08:01, Sean Dague s...@dague.net wrote: I'd like us to think about whether they is anything we can do to make life easier in these kind of hard debugging scenarios where the regular logs are not sufficient. Agreed. Honestly, though we

Re: [openstack-dev] debug logs and defaults was (Thoughts on the patch test failure rate and moving forward)

2014-07-27 Thread Robert Collins
On 28 July 2014 13:11, Tom Fifield t...@openstack.org wrote: If a starting point is needed, the last discussion we had around 'reasonable' defaults is here: https://etherpad.openstack.org/p/juno-summit-ops-reasonabledefaults Thanks Tom! I note that logging isn't in there, so either its not

Re: [openstack-dev] debug logs and defaults was (Thoughts on the patch test failure rate and moving forward)

2014-07-27 Thread Tom Fifield
On 28/07/14 09:18, Robert Collins wrote: On 28 July 2014 13:11, Tom Fifield t...@openstack.org wrote: If a starting point is needed, the last discussion we had around 'reasonable' defaults is here: https://etherpad.openstack.org/p/juno-summit-ops-reasonabledefaults Thanks Tom! I note that

Re: [openstack-dev] debug logs and defaults was (Thoughts on the patch test failure rate and moving forward)

2014-07-27 Thread Robert Collins
On 28 July 2014 13:47, Tom Fifield t...@openstack.org wrote: Logging discussion is at: https://etherpad.openstack.org/p/juno-summit-ops-monitoringlogging Ah, awesome. So - reading through that, I don't see any captured discussion of changing our defaults to match what folk are doing (though

Re: [openstack-dev] [Neutron] [Spec freeze exception] Support Stateful and Stateless DHCPv6 by dnsmasq

2014-07-27 Thread Xuhan Peng
Thanks Kyle and everyone for supporting this! Will try the best to make the code ready for Juno-3. Xu Han  — Sent from Mailbox for iPhone On Fri, Jul 25, 2014 at 11:06 PM, Kyle Mestery mest...@mestery.com wrote: On Thu, Jul 24, 2014 at 8:46 PM, CARVER, PAUL pc2...@att.com wrote: Collins,

Re: [openstack-dev] [Nova] [Gantt] Scheduler split status (updated)

2014-07-27 Thread Robert Collins
On 16 July 2014 03:45, Debojyoti Dutta ddu...@gmail.com wrote: https://etherpad.openstack.org/p/SchedulerUseCases [08:43:35] n0ano #action all update the use case etherpad athttps://etherpad.openstack.org/p/SchedulerUseCases Please update your use cases here .. Added. -Rob -- Robert

Re: [openstack-dev] [oslo.cfg] Dynamically load in options/groups values from the configuration files

2014-07-27 Thread Baohua Yang
Dear all Thanks for all the responses! First, I threw the question actually wanting to hear other voices of the similar requirements of dynamic parsing. Glad to get all supports and also questions. The scenario is that sometime we might define some groups in the config file with

[openstack-dev] Fwd: OPENDAYLIGHT : OVSDB - NEUTRON INTEGRATION with OPENSTACK

2014-07-27 Thread Sharath V
Hi, I have done OVSDB-Neutron integration with Openstack on Ubuntu with two compute nodes, I have blogged the procedure to make integration successful and blog details mentioned below.

Re: [openstack-dev] [Neutron][LBaaS][Tempest] LBaaS V2 testing, partial results

2014-07-27 Thread Brandon Logan
Hey Miguel! Thanks for doing this. I'll look into the pool issue ASAP and get back to you. Thanks, Brandon On Sun, 2014-07-27 at 19:24 -0500, Miguel Lavalle wrote: Hi, I spent a few hours deploying LBaaS V2 to my devstack instance and tested it with the Tempest api test developed a

Re: [openstack-dev] [Neutron][LBaaS][Tempest] LBaaS V2 testing, partial results

2014-07-27 Thread Brandon Logan
Hey Miguel, I just tried to reproduce what you got but couldn't. Have you pulled down code recently? I believe new code hit on Friday that probably fixed the issue you encountered. Let me know. Thanks, Brandon On Sun, 2014-07-27 at 19:24 -0500, Miguel Lavalle wrote: Hi, I spent a few