Re: [openstack-dev] [Octavia] Question about where to render haproxy configurations

Hi German, Comments in-line On Sun, 2014-09-07 at 04:49 +, Eichberger, German wrote: > Hi Steven, > > > > Thanks for taking the time to lay out the components clearly. I think > we are pretty much on the same pageJ > > > > Driver vs, Driver-less > > I strongly believe that REST is a

[openstack-dev] [Neutron] - reading router external IPs

Hello, The code allowing external IPs to be set and read on external router interfaces was not merged.[1] As I understand it, feature freeze exceptions are already oversubscribed. I don't think setting IPs was critical for anyone; however, not being able to read them is a blocker for VPNaaS.[2] Te

Re: [openstack-dev] [Octavia] Question about where to render haproxy configurations

Hi German and Brandon, Responses in-line: On Sun, Sep 7, 2014 at 12:21 AM, Brandon Logan wrote: > Hi German, > > Comments in-line > > On Sun, 2014-09-07 at 04:49 +, Eichberger, German wrote: > > Hi Steven, > > > > > > > > Thanks for taking the time to lay out the components clearly. I thin

Re: [openstack-dev] [cinder] Cinder plans for kilo: attention new driver authors!

Hi, Thanks for clarification w.r.t cinder drivers. I had submitted the "CloudByte" driver code during juno and currently grappling with various aspects of setting up the CI for the same. It also requires a copy of tempest logs which also is a in progress item. Will above be automatically eligible

Re: [openstack-dev] [rally][iperf] Benchmarking network performance

The problem lies in this patch: https://review.openstack.org/#/c/96300 Even If I apply it, i get an error that Unknown Neutron context. The patch is correctly applied - some 20 times :) Task and output is as follows: { "VMTasks.boot_runcommand_delete": [ { "args": {

[openstack-dev] [neutron] non-deterministic gate failures due to unclosed eventlet Timeouts

Hi, Long story short: for future reference, if you initialize an eventlet Timeout, make sure you close it (either with a context manager or simply timeout.close()), and be extra-careful when writing tests using eventlet Timeouts, because these timeouts don't implicitly expire and will cause unexpe

Re: [openstack-dev] [neutron] [nova] non-deterministic gate failures due to unclosed eventlet Timeouts

On 9/7/2014 8:39 AM, John Schwarz wrote: Hi, Long story short: for future reference, if you initialize an eventlet Timeout, make sure you close it (either with a context manager or simply timeout.close()), and be extra-careful when writing tests using eventlet Timeouts, because these timeouts

Re: [openstack-dev] Kilo Cycle Goals Exercise

On Wed, 3 Sep 2014, Joe Gordon wrote: Have anyone interested (especially TC members) come up with a list of what they think the project wide Kilo cycle goals should be and post them on this thread by end of day Wednesday, September 10th. After which time we can begin discussing the results. I

Re: [openstack-dev] Kilo Cycle Goals Exercise

Comments in line (added my thoughts on a couple of the targets Sean outlined). On Thursday, September 4, 2014, Sean Dague wrote: > > > Here is my top 5 list: > > 1. Functional Testing in Integrated projects > > The justification for this is here - > http://lists.openstack.org/pipermail/openstack-

Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation

On 09/04/2014 11:24 PM, Robert Collins wrote: On 4 September 2014 23:42, Nejc Saje wrote: On 09/04/2014 11:51 AM, Robert Collins wrote: It doesn't contain that term precisely, but it does talk about replicating the buckets. What about using a descriptive name for this parameter, like 'di

[openstack-dev] [Swift] (Non-)consistency of the Swift hash ring implementation

Hey guys, in Ceilometer we're using consistent hash rings to do workload partitioning[1]. We've considered using Ironic's hash ring implementation, but found out it wasn't actually consistent (ML[2], patch[3]). The next thing I noticed that the Ironic implementation is based on Swift's. The

Re: [openstack-dev] [rally][iperf] Benchmarking network performance

The following context worked for me. "context": { "neutron_network": { "network_cidr": "10.%s.0.0/16", }, "users": { "tenants": 1, "users_per_tenant": 2 }

Re: [openstack-dev] [rally][iperf] Benchmarking network performance

Massoom, Seems like you are using old rally code. On Sun, Sep 7, 2014 at 10:33 PM, Ajay Kalambur (akalambu) < akala...@cisco.com> wrote: > The following context worked for me. > > > "context": { > "neutron_network": { > "network_cidr": "10.%s.0.

Re: [openstack-dev] [rally][iperf] Benchmarking network performance

Ajay, Seems like you are using old rally. Because it should show detailed information about error. Recently we merged this: https://review.openstack.org/#/c/118169/ that shows full information. Could you send the set of commands that you run to apply neutron context? Best regards, Boris Pavlov

Re: [openstack-dev] [rally][iperf] Benchmarking network performance

Hi Boris It worked for me see no error Ajay Sent from my iPhone On Sep 7, 2014, at 12:11 PM, "Boris Pavlovic" mailto:bo...@pavlovic.me>> wrote: Ajay, Seems like you are using old rally. Because it should show detailed information about error. Recently we merged this: https://review.openstack

[openstack-dev] NFV Meetings

Hi, Hope you are doing good. Did we have a meeting last week? I was under the impression it¹s was scheduled to Thursday (as in the wiki) but found other meetings in the IRCŠ What am I missing? Do we have one this week? Also, I sent a mail about the sub groups goals as we agreed ten days ago. Did

[openstack-dev] [cinder] new cinderclient release this week?

I think we're in dependency freeze or quickly approaching. What are the plans from the Cinder team for doing a python-cinderclient release to pick up any final features before Juno rc1? -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list Ope

Re: [openstack-dev] [qa][all][Heat] Packaging of functional tests

On 06/09/14 04:10, Matthew Treinish wrote: > On Fri, Sep 05, 2014 at 09:42:17AM +1200, Steve Baker wrote: >> On 05/09/14 04:51, Matthew Treinish wrote: >>> On Thu, Sep 04, 2014 at 04:32:53PM +0100, Steven Hardy wrote: On Thu, Sep 04, 2014 at 10:45:59AM -0400, Jay Pipes wrote: > On 08/29/20

Re: [openstack-dev] [Nova] List of granted FFEs

The FFE request thread is here: http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg34100.html Daniel Berrange and Sean Dague signed up to sponsor the FFE on the mailing list. Later, Jay Pipes reviewed the code and posted his agreement to sponsor the FFE in his +2 comment on th

Re: [openstack-dev] Kilo Cycle Goals Exercise

On 09/03/2014 08:37 AM, Joe Gordon wrote: As you all know, there has recently been several very active discussions around how to improve assorted aspects of our development process. One idea that was brought up is to come up with a list of cycle goals/project priorities for Kilo [0]. To that end

Re: [openstack-dev] Kilo Cycle Goals Exercise

Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making users happy. 1) Consistent/easy upgrading. all projects should follow a consistent model to the way they approach upgrading. it should actually work. - REST versioning - RPC versioning - db (data) mig

Re: [openstack-dev] Kilo Cycle Goals Exercise

On 09/07/2014 09:12 PM, Angus Salkeld wrote: > Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making > users happy. I don't understand why you would encourage writers of blog posts you disagree with by sending them traffic. Anita. > > 1) Consistent/easy upgrading. > all pr

[openstack-dev] New python-neutronclient release: 2.3.7

Hi: I've just pushed a new release of python-neutronclient out. The main feature in this release is keystone v3 auth support [1]. In addition, the following, changes are also a part of this release: f22dbd2 Updated from global requirements 9f3ffdf Remove unnecessary get_status_code wrapper functi

Re: [openstack-dev] [neutron] python-neutronclient, launchpad, and milestones

On Sat, Sep 6, 2014 at 9:08 PM, Kyle Mestery wrote: > On Sat, Sep 6, 2014 at 8:43 AM, Matt Riedemann > wrote: >> >> >> On 8/29/2014 1:53 PM, Kyle Mestery wrote: >>> >>> On Fri, Aug 29, 2014 at 1:40 PM, Matt Riedemann >>> wrote: On 7/29/2014 4:12 PM, Kyle Mestery wrote: >

Re: [openstack-dev] Kilo Cycle Goals Exercise

On 8 September 2014 13:27, Anita Kuno wrote: > On 09/07/2014 09:12 PM, Angus Salkeld wrote: >> Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making >> users happy. > I don't understand why you would encourage writers of blog posts you > disagree with by sending them traffic. B

Re: [openstack-dev] Kilo Cycle Goals Exercise

On Mon, Sep 8, 2014 at 11:27 AM, Anita Kuno wrote: > On 09/07/2014 09:12 PM, Angus Salkeld wrote: > > Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making > > users happy. > I don't understand why you would encourage writers of blog posts you > disagree with by sending them tr

Re: [openstack-dev] Kilo Cycle Goals Exercise

On 09/07/2014 09:37 PM, Angus Salkeld wrote: > On Mon, Sep 8, 2014 at 11:27 AM, Anita Kuno wrote: > >> On 09/07/2014 09:12 PM, Angus Salkeld wrote: >>> Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making >>> users happy. >> I don't understand why you would encourage writers o

Re: [openstack-dev] [cinder] new cinderclient release this week?

On Sun, Sep 7, 2014 at 2:44 PM, Matt Riedemann wrote: > I think we're in dependency freeze or quickly approaching. What are the > plans from the Cinder team for doing a python-cinderclient release to pick > up any final features before Juno rc1? > > -- > > Thanks, > > Matt Riedemann > > > __

[openstack-dev] [Neutron][ServiceVM] servicevm IRC meeting reminder (cancel Sep 9, next Sep 16 Tuesday 5:00(AM)UTC-)

Hi. This is a reminder mail for the servicevm IRC meeting. The meeting on Sep 9 will be canceled due to my conflicts. If someone is willing chair the meeting on, please go ahead(without me). The next meeting will be held on Sep 16. Sep 16, 2014 Tuesdays 5:00(AM)UTC- #openstack-meeting on freenode

Re: [openstack-dev] [Nova] List of granted FFEs

Ahhh, I didn't realize Jay had added his name in the review. This FFE is therefore approved. Michael On Mon, Sep 8, 2014 at 10:12 AM, Genin, Daniel I. wrote: > The FFE request thread is here: > > > http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg34100.html > > Daniel Berran

Re: [openstack-dev] [Nova] [FFE] alternative request for v2-on-v3-api

I didn't put two and two together and come up with three cores here. Sorry for that. This FFE is approved. Michael On Fri, Sep 5, 2014 at 10:57 PM, Sean Dague wrote: > On 09/04/2014 07:54 PM, Christopher Yeoh wrote: >> On Thu, 4 Sep 2014 23:08:09 +0900 >> "Ken'ichi Ohmichi" wrote: >> >>> Hi >>>

[openstack-dev] doubling our core review bandwidth

I hope the subject got your attention :). This might be a side effect of my having too many cosmic rays, but its been percolating for a bit. tl;dr I think we should drop our 'needs 2x+2 to land' rule and instead use 'needs 1x+2'. We can ease up a large chunk of pressure on our review bottleneck,

Re: [openstack-dev] doubling our core review bandwidth

On Mon, Sep 8, 2014 at 1:14 PM, Robert Collins wrote: > I hope the subject got your attention :). > > This might be a side effect of my having too many cosmic rays, but its > been percolating for a bit. > > tl;dr I think we should drop our 'needs 2x+2 to land' rule and instead > use 'needs 1x+2'.

Re: [openstack-dev] [Swift] (Non-)consistency of the Swift hash ring implementation

To test Swift directly, I used the CLI tools that Swift provides for managing rings. I wrote the following short script: $ cat remakerings #!/bin/bash swift-ring-builder object.builder create 16 3 0 for zone in {1..4}; do for server in {200..224}; do for drive in {1..12}; do swift-ring-builder o

Re: [openstack-dev] doubling our core review bandwidth

Responses in-line. -Original Message- From: Robert Collins Reply: OpenStack Development Mailing List (not for usage questions) > Date: September 7, 2014 at 20:16:32 To: OpenStack Development Mailing List > Subject:  [openstack-dev] doubling our core review bandwidth > I hope the subjec

Re: [openstack-dev] [cinder] Cinder plans for kilo: attention new driver authors!

On 17:18 Sun 07 Sep , Amit Das wrote: > I had submitted the "CloudByte" driver code during juno and currently > grappling with various aspects of setting up the CI for the same. It also > requires a copy of tempest logs which also is a in progress item. > > Will above be automatically eligible

Re: [openstack-dev] [cinder] Cinder plans for kilo: attention new driver authors!

Thanks. I have done that. Regards, Amit *CloudByte Inc.* On Mon, Sep 8, 2014 at 9:37 AM, Mike Perez wrote: > On 17:18 Sun 07 Sep , Amit Das wrote: > > I had submitted the "CloudByte" driver code during juno and currently > > grappling with various aspects of sett

Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation

On 8 September 2014 05:57, Nejc Saje wrote: \ >> That generator API is pretty bad IMO - because it means you're very >> heavily dependent on gc and refcount behaviour to keep things clean - >> and there isn't (IMO) a use case for walking the entire ring from the >> perspective of an item. Whats th

[openstack-dev] [gantt] Scheduler cleanup - what did we agree to

As I mentioned in a prior email I think that, although we're in agreement on what needs to be done before splitting out the scheduler into the Gantt project, I believe we have different views on what that agreement actually is. Given that we have multiple people that actively want to work on th

[openstack-dev] [mistral] Team meeting reminder - 09/08/2014

Hi, Please keep in mind that we’ll have a team meeting today at 16.00 UTC at #openstack-meeting. Agenda: Review action items Current status (progress, issues, roadblocks, further plans) Release 0.1 progress (go through the list of what's left) Metrics collector BPs Open discussion (see also at