[openstack-dev] Requirements freeze exception: urllib3

Hi, Please see this: https://review.openstack.org/122993 Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][vmware] Juno update

Hi, Below is a short update of the current status of the driver in Juno. We managed to complete the following specs: * Integration with oslo.vmware (https://github.com/openstack/nova-specs/blob/master/specs/juno/use-oslo-vmware.rst) * Hot plug interface (https://github.com/openstack/no

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

Hi Ian and Donald, I've read the full thread, and couldn't help to reply to it still, even though I previously thought I shouldn't, as what I care is OpenStack, not really requests, and more largely, the topic of the wrong reasons why upstream are embedding foreign library code copies. I completel

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

On 09/18/2014 05:22 AM, Dean Troyer wrote: > On Wed, Sep 17, 2014 at 3:53 PM, Robert Collins > mailto:[email protected]>> wrote: > > On 18 September 2014 08:01, Dean Troyer > wrote: > > Interestingly enough, the distros are doing exactly what they don

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

Hi Thomas, Several people, many of whom are core contributors to other projects, have asked that this discussion not be continued in this venue. Discussion of the decisions of the core-developers of requests are not appropriate for this list. All three of us have email addresses that you can retri

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

On 09/21/2014 11:30 AM, Ian Cordasco wrote: Hi Thomas, Several people, many of whom are core contributors to other projects, have asked that this discussion not be continued in this venue. Discussion of the decisions of the core-developers of requests are not appropriate for this list. All three

Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

Querying keystone for tenant names is certainly fair game. Keystone should be considered the only source of truth for tenant names though, as they are mutable and not globally unique on their own, so other services should not stash any names from keystone into long term persistence (users, project

Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

So based on those guidelines there would be a problem with the IBM patch because it's storing the tenant name in a backend controller, right? On Sep 21, 2014 12:18 PM, "Dolph Mathews" wrote: > Querying keystone for tenant names is certainly fair game. > > Keystone should be considered the only so

[openstack-dev] devstack - horizon dashboard issues

Hi guys, trying to get a devstack up and running, on a VM, but I keep getting this: Error during template rendering In template /opt/stack/horizon/openstack_dashboard/templates/context_selection/_project_list.html, error at line *7* Reverse for ''switch_tenants'' with arguments '(u'ca0fd29936a64

Re: [openstack-dev] [Heat] naming of provider template for docs

Thanks for the suggestions, I'll give that patch another crack. -Angus On Sat, Sep 20, 2014 at 10:11 AM, Qiming Teng wrote: > On Fri, Sep 19, 2014 at 11:20:43AM +0200, Thomas Spatzier wrote: > > > From: Mike Spreitzer > > > To: "OpenStack Development Mailing List \(not for usage questions\)" >

[openstack-dev] [Heat] Announcing my candidacy for PTL

I would like to announce my candidacy for the position of Orchestration PTL. After contributing to Heat since it was created, I feel like I know what Heat is and can do. We have some really big challenges ahead to ensure that Heat is scalable and stays relevant. The big issues for Heat that I wan

Re: [openstack-dev] [nova] 2 weeks in the bug tracker

On 9/19/2014 8:13 AM, Sean Dague wrote: I've spent the better part of the last 2 weeks in the Nova bug tracker to try to turn it into something that doesn't cause people to run away screaming. I don't remember exactly where we started at open bug count 2 weeks ago (it was north of 1400, with >

Re: [openstack-dev] [nova] expected behaviour of _report_state() on rabbitmq failover

On 9/10/2014 3:33 PM, Chris Friesen wrote: On 09/10/2014 02:13 PM, Chris Friesen wrote: As it stands, it seems that waiting for the RPC call to time out blocks _report_state() from running again in report_interval seconds, which delays the service update until the RPC timeout period expires.

Re: [openstack-dev] [nova] expected behaviour of _report_state() on rabbitmq failover

On 9/21/2014 7:56 PM, Matt Riedemann wrote: On 9/10/2014 3:33 PM, Chris Friesen wrote: On 09/10/2014 02:13 PM, Chris Friesen wrote: As it stands, it seems that waiting for the RPC call to time out blocks _report_state() from running again in report_interval seconds, which delays the servic

Re: [openstack-dev] [Heat] Announcing my candidacy for PTL

confirmed On 21/09/14 08:15 PM, Angus Salkeld wrote: > I would like to announce my candidacy for the position of Orchestration PTL. > > After contributing to Heat since it was created, I feel like I know what > Heat is and can do. > We have some really big challenges ahead to ensure that Heat is

Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

On 09/19/2014 01:43 PM, Doug Hellmann wrote: On Sep 19, 2014, at 6:56 AM, David Chadwick wrote: On 18/09/2014 22:14, Doug Hellmann wrote: On Sep 18, 2014, at 4:34 PM, David Chadwick wrote: On 18/09/2014 21:04, Doug Hellmann wrote: On Sep 18, 2014, at 12:36 PM, David Chadwick wrote: O

[openstack-dev] About the question "Switch firewall_driver control from Neutron to Nova"

Dear OpenStack-dev, I've posted a question on https://ask.openstack.org/en/question/47819/switch-firewall_driver-control-f rom-neutron-to-nova/ It's suggested that I should forward this question to OpenStack-dev mailing list for discussion. Any feedback/answer would be very appreciated.

[openstack-dev] pycharm license?

Hi, Does anyone has pycharm license for openstack project development? Thanks. Regards Kanagaraj M ___ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO][elections] Not running as PTL this cycle

I'm not running as PTL for the TripleO program this cycle. There are a couple of reasons for this. Firstly, I think its good for intense multi-year efforts like we're all involved in here to have leadership spread around: for the folk wearing the leadership hat, its hard work keeping everything pa

Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

Thanks Kevin for bring it up in the ML, I was looking for a guideline or any document to clarify issues on this subject. I was told, even using keystone API in neutron is not permitted. Thanks, Nader. On Sun, Sep 21, 2014 at 12:58 PM, Kevin Benton wrote: > So based on those guidelines there w

Re: [openstack-dev] [Manila] ./run_tests issue

Thats incorrect, as i said in my original mail.. I am usign devstack+manila and it wasn't very clear to me that mysql-devel needs to be installed and it didn't get installed. I am on F20, not sure if that causes this , if yes, then we need to debug and fix this. Maybe its a good idea to put a comm

Re: [openstack-dev] [Manila] ./run_tests issue

Even better, whenever ./run_tests fail... maybe put a msg stating the following C libs needs to be installed, have the user check the same..something like that would help too. On Mon, Sep 22, 2014 at 11:59 AM, Deepak Shetty wrote: > Thats incorrect, as i said in my original mail.. I am usign > d

Re: [openstack-dev] [all] Design Summit planning

On 18/09/14 16:03, Thierry Carrez wrote: > Maish Saidel-Keesing wrote: >> On 17/09/2014 23:12, Anita Kuno wrote: >>> On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote: This looks great - but I am afraid that something might be missing. As part of the Design summit in Atlanta there w

[openstack-dev] Group-Based Policy Understanding and Queries

Hi All, Request you all to provide inputs on below understanding: Openstack: Group-based policy is a blueprint for Juno-3 release of Openstack. It will extend OpenStack Networking with policy and connectivity abstractions that enable significantly more simplified and application-oriented inter

[openstack-dev] [Zaqar] PTL Candidacy

Greetings, I'd like to announce my candidacy for the Message Program PTL position. I've been part of this program since its inception. Along with a really amazing team, I've been working on changing the openstack messaging service reality for the last 2 years. Zaqar has a set of features that I