Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

On Thursday, 26 de February de 2015 at 7:48, Miguel Ángel Ajo wrote: > Inline comments follow after this, but I wanted to respond to Brian question > which has been cut out: > > We’re talking here of doing a preliminary analysis of the networking > performance, > before writing any real code at

Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

On Thu, Feb 26, 2015 at 07:48:51AM +0100, Miguel Ángel Ajo wrote: > Also, ipset groups can be moved into conjunctive groups in OF (thanks Ben > Pfaff for the > explanation, if you’re reading this ;-)) You're welcome. __ Open

Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

Inline comments follow after this, but I wanted to respond to Brian question which has been cut out: We’re talking here of doing a preliminary analysis of the networking performance, before writing any real code at neutron level. If that looks right, then we should go into a preliminary (and ort

Re: [openstack-dev] [nova] Shared storage support

Actually I have similar idea, an plan to work on it at L by a nova-spec (is it worth a spec?). But this idea not come from this bug, it's come from other cases: 1. Currently we need specified 'on_shared_storage' and 'block_migration' when evacuate and live_migration. After we tracking the shared

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

On Thu, Feb 26, 2015 at 10:50 AM, Kevin Benton wrote: > You can horizontally split as well (if I understand what axis definitions > you are using). The Big Switch driver for example will bind ports that > belong to hypervisors running IVS while leaving the OVS driver to bind > ports attached to h

Re: [openstack-dev] [all] creating a unified developer reference manual

Sounds like a very good idea. Cross project development shared knowledge. Miguel Ángel Ajo On Wednesday, 25 de February de 2015 at 22:32, michael mccune wrote: > On 02/25/2015 02:54 PM, Doug Hellmann wrote: > > During yesterday’s cross-project meeting [1], we discussed the "Eventlet > > Best P

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

You can horizontally split as well (if I understand what axis definitions you are using). The Big Switch driver for example will bind ports that belong to hypervisors running IVS while leaving the OVS driver to bind ports attached to hypervisors running OVS. I don't fully understand your comments

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

Oh, what you mean is vertical splitting, while I'm talking about horizontal splitting. I'm a little confused about why Neutron is designed so differently with Nova and Cinder. In fact MD could be very simple, delegating nearly all things out to agent. Remember Cinder volume manager? The real stora

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

In the cases I'm referring to, OVS handles the security groups and vswitch. The other drivers handle fabric configuration for VLAN tagging to the host and whatever other plumbing they want to do. On Feb 25, 2015 5:30 PM, "loy wolfe" wrote: > > > On Thu, Feb 26, 2015 at 3:51 AM, Kevin Benton wro

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

On Thu, Feb 26, 2015 at 3:51 AM, Kevin Benton wrote: > The fact that a system doesn't use a neutron agent is not a good > justification for monolithic vs driver. The VLAN drivers co-exist with OVS > just fine when using VLAN encapsulation even though some are agent-less. > so how about security g

Re: [openstack-dev] [Neutron] (RE: Change in openstack/neutron-specs[master]: Introducing Tap-as-a-Service)

On 2/24/2015 6:47 PM, Kevin Benton wrote: More seriously, have you considered starting a tap-as-a-service project on stackforge now that the services split has established a framework for advanced services? Uploading the code you are using to do it is a great way to get people motivated to try i

Re: [openstack-dev] [Openstack-operators] Resources owned by a project/tenant are not cleaned up after that project is deleted from keystone

On 25/02/15 19:15, Dolph Mathews wrote: On Wed, Feb 25, 2015 at 5:42 PM, Zane Bitter mailto:zbit...@redhat.com>> wrote: On 25/02/15 15:37, Joe Gordon wrote: On Sat, Feb 21, 2015 at 5:03 AM, Tim Bell mailto:tim.b...@cern.ch>

Re: [openstack-dev] [Openstack-operators] Resources owned by a project/tenant are not cleaned up after that project is deleted from keystone

On Wed, Feb 25, 2015 at 5:42 PM, Zane Bitter wrote: > On 25/02/15 15:37, Joe Gordon wrote: > >> >> >> On Sat, Feb 21, 2015 at 5:03 AM, Tim Bell > > wrote: >> >> >> A few inline comments and a general point >> >> How do we handle scenarios like volumes when we have

[openstack-dev] [Manila] Devstack+Manila -- old method won't work anymore

Many of you may have gotten in the habit of copying the contrib/devstack folder in order to make Manila work with Devstack. https://review.openstack.org/#/c/158054/ Once the above change merges, that method of installing Manila with Devstack won't work anymore. Valeriy was kind enough to inclu

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On 02/24/2015 12:27 PM, Daniel P. Berrange wrote: > I'm actually trying to judge it from the POV of users, not just > developers. I find it pretty untenable that in the fast moving > world of cloud, users have to wait as long as 6 months for a > feature to get into a openstack release, often much l

Re: [openstack-dev] [Ironic] Stepping down from Ironic Core

Robert, Thank you for all your input and insight over the last two years. Our architectural discussions have been invaluable to me and helped shape Ironic into what it is today. All the best, Devananda On Tue Feb 24 2015 at 4:26:54 PM Robert Collins wrote: > Like with TripleO, I've not been pu

Re: [openstack-dev] [Openstack-operators] Resources owned by a project/tenant are not cleaned up after that project is deleted from keystone

On 25/02/15 15:37, Joe Gordon wrote: On Sat, Feb 21, 2015 at 5:03 AM, Tim Bell mailto:tim.b...@cern.ch>> wrote: A few inline comments and a general point How do we handle scenarios like volumes when we have a per-component janitor rather than a single co-ordinator ? To be cl

Re: [openstack-dev] [stable][requirements] External dependency caps introduced in 499db6b

I'll follow-up on the spec, but one thing Donald has been pointing out for a while is that we don't use requirements.txt the way that pip anticipates: the expected use is that a specific install (e.g. the gate) will have a very specific list of requirements, caps etc, but that the install_requires

Re: [openstack-dev] [Ironic] patches that only address grammatical/typos

On 26 February 2015 at 05:26, Ruby Loo wrote: > Hi, > > I was wondering what people thought about patches that only fix grammatical > issues or misspellings in comments in our code. > > I can't believe I'm sending out this email, but as a group, I'd like it if > we had a similar understanding so

Re: [openstack-dev] [Openstack-operators] Resources owned by a project/tenant are not cleaned up after that project is deleted from keystone

On Wed, Feb 25, 2015 at 3:02 PM, Matt Joyce wrote: > Wondering if heat should be performing this orchestration. > I wouldn't expect heat to have access to everything that needs to be cleaned up. > > Would provide for a more pluggable front end to the action set. > > -matt > > On Feb 25, 2015 2

Re: [openstack-dev] H302 considered harmful

Excerpts from Duncan Thomas's message of 2015-02-25 12:51:35 -0800: > Clint > > This rule is not currently enabled in Cinder. This review fixes up all > cases and enables it, which is absolutely 100% the right thing to do if we > decide to implement this rule. > > The purpose of this thread is to

Re: [openstack-dev] H302 considered harmful

The “making things more explicit” argument carried to its logical conclusion would require that no “import … as …” ever be used either, and we would have to use the full namespace/path for each module or function being used. With allowing “import … as …” and the practice of extending and monkey pa

[openstack-dev] [QA] Meeting Thursday February 26th at 17:00 UTC

Hi everyone, Just a quick reminder that the weekly OpenStack QA team IRC meeting will be tomorrow Thursday, February 26th at 17:00 UTC in the #openstack-meeting channel. The agenda for tomorrow's meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome t

Re: [openstack-dev] [Ironic] patches that only address grammatical/typos

We've unwound the gate quite a bit, so the cost of extra patches in the merge queue fixing trivial things (like comment spelling) is pretty low. Honestly, I'd much rather merge functional fixes faster and not go an extra 2 rounds of typo fixing (assuming the English is decipherable), and merge typ

Re: [openstack-dev] [all] creating a unified developer reference manual

On 02/25/2015 02:54 PM, Doug Hellmann wrote: During yesterday’s cross-project meeting [1], we discussed the "Eventlet Best Practices” spec [2] started by bnemec. The discussion of that spec revolved around the question of whether our cross-project specs repository is the right place for this t

[openstack-dev] [openstack-operators][Rally][HA-testing][multi-scenarios-load-gen] Proposal to change Rally input task format

Hi stackers, When we started Rally we have a just small idea to make some tool that generates load and measures performance. During almost 2 years a lot of changed in Rally, so now it's quite common testing framework that allows to cover various topics like: stress, load, volume, performance, neg

Re: [openstack-dev] [Ironic] patches that only address grammatical/typos

Jay, I can only confirm your point of view. I personally landed such a patch yesterday and saw it as an easy way to get familiar with Gerrit. My goal being to land some more complex patches in the near future. Bernard On Wed, Feb 25, 2015 at 12:37 PM, Doug Hellmann wrote: > > > On Wed, Feb 25,

Re: [openstack-dev] [neutron][docs] VPNaaS API reference missing...

On Wed, Feb 25, 2015 at 3:11 PM, Paul Michali wrote: > Cool! Glad to see it is not gone. Should it also be on the API reference > pages? > > http://developer.openstack.org/api-ref-networking-v2.html > > Yes, we've had a doc bug since last fall about it being missing from the API Reference. https

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On 2/25/15, 14:41, "Doug Hellmann" wrote: > > >On Wed, Feb 25, 2015, at 12:35 PM, Johannes Erdfelt wrote: >> On Tue, Feb 24, 2015, Jeremy Stanley wrote: >> > On 2015-02-24 10:00:51 -0800 (-0800), Johannes Erdfelt wrote: >> > [...] >> > > Recently, I have spent a lot more time waiting on reviews

Re: [openstack-dev] [stable][requirements] External dependency caps introduced in 499db6b

On Wed, Feb 25, 2015, at 04:04 PM, Joe Gordon wrote: > On Tue, Feb 24, 2015 at 7:00 AM, Doug Hellmann > wrote: > > > > > > > On Mon, Feb 23, 2015, at 06:31 PM, Joe Gordon wrote: > > > On Mon, Feb 23, 2015 at 11:04 AM, Doug Hellmann > > > wrote: > > > > > > > > > > > > > > > On Mon, Feb 23, 201

Re: [openstack-dev] [neutron][docs] VPNaaS API reference missing...

Cool! Glad to see it is not gone. Should it also be on the API reference pages? http://developer.openstack.org/api-ref-networking-v2.html PCM (Paul Michali) IRC pc_m (irc.freenode.com) Twitter... @pmichali On Wed, Feb 25, 2015 at 1:42 PM, Salvatore Orlando wrote: > As you can

Re: [openstack-dev] [stable][requirements] External dependency caps introduced in 499db6b

On Tue, Feb 24, 2015 at 7:00 AM, Doug Hellmann wrote: > > > On Mon, Feb 23, 2015, at 06:31 PM, Joe Gordon wrote: > > On Mon, Feb 23, 2015 at 11:04 AM, Doug Hellmann > > wrote: > > > > > > > > > > > On Mon, Feb 23, 2015, at 12:26 PM, Joe Gordon wrote: > > > > On Mon, Feb 23, 2015 at 8:49 AM, Ihar

Re: [openstack-dev] [Openstack-operators] Resources owned by a project/tenant are not cleaned up after that project is deleted from keystone

Wondering if heat should be performing this orchestration. Would provide for a more pluggable front end to the action set. -matt On Feb 25, 2015 2:37 PM, Joe Gordon wrote: > > > > On Sat, Feb 21, 2015 at 5:03 AM, Tim Bell wrote: >> >> >> A few inline comments and a general point >> >> How do w

Re: [openstack-dev] [all] creating a unified developer reference manual

On Wed, Feb 25, 2015 at 12:49 PM, Doug Hellmann wrote: > > > On Wed, Feb 25, 2015, at 03:14 PM, Joe Gordon wrote: > > On Wed, Feb 25, 2015 at 11:54 AM, Doug Hellmann > > wrote: > > > > > During yesterday’s cross-project meeting [1], we discussed the > "Eventlet > > > Best Practices” spec [2] sta

Re: [openstack-dev] H302 considered harmful

Clint This rule is not currently enabled in Cinder. This review fixes up all cases and enables it, which is absolutely 100% the right thing to do if we decide to implement this rule. The purpose of this thread is to understand the value of the rule. We should either enforce it, or else explicitly

Re: [openstack-dev] [all] creating a unified developer reference manual

On Wed, Feb 25, 2015, at 03:14 PM, Joe Gordon wrote: > On Wed, Feb 25, 2015 at 11:54 AM, Doug Hellmann > wrote: > > > During yesterday’s cross-project meeting [1], we discussed the "Eventlet > > Best Practices” spec [2] started by bnemec. The discussion of that spec > > revolved around the ques

Re: [openstack-dev] H302 considered harmful

On Wed, Feb 25, 2015, at 02:59 PM, Robert Collins wrote: > On 26 February 2015 at 08:54, melanie witt wrote: > > On Feb 25, 2015, at 10:51, Duncan Thomas wrote: > > > >> Is there anybody who'd like to step forward in defence of this rule and > >> explain why it is an improvement? I don't disco

Re: [openstack-dev] H302 considered harmful

Excerpts from Duncan Thomas's message of 2015-02-25 10:51:00 -0800: > Hi > > So a review [1] was recently submitted to cinder to fix up all of the H302 > violations, and turn on the automated check for them. This is certainly a > reasonable suggestion given the number of manual reviews that -1 for

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

Tom Fifield wrote on 25/02/2015 06:46:13 AM: > On 24/02/15 19:27, Daniel P. Berrange wrote: > > On Tue, Feb 24, 2015 at 12:05:17PM +0100, Thierry Carrez wrote: > >> Daniel P. Berrange wrote: > >>> [...] > > > I'm not familiar with how the translations works, but if they are > > waiting until the

Re: [openstack-dev] [OpenStackClient] New meeting time

Ditto! On Wed, Feb 25, 2015, at 01:35 PM, Steve Martinelli wrote: > \o/ > > I'll be there! Thanks for organizing it all Dean. > > Steve > > Dean Troyer wrote on 02/25/2015 12:19:38 PM: > > > From: Dean Troyer > > To: OpenStack Development Mailing List > > > Date: 02/25/2015 12:32 PM > > Su

[openstack-dev] sqlalchemy-migrate 0.9.5 released

https://pypi.python.org/pypi/sqlalchemy-migrate/0.9.5 Changes: mriedem@ubuntu:~/git/sqlalchemy-migrate$ git log --oneline --no-merges 0.9.4..0.9.5 5feeaba Don't run the test if _setup() fails c8c5c4b Correcting minor typo 9d212e6 Fix .gitignore for .tox and .testrepository ae64d82 allow droppi

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On Wed, Feb 25, 2015, at 12:35 PM, Johannes Erdfelt wrote: > On Tue, Feb 24, 2015, Jeremy Stanley wrote: > > On 2015-02-24 10:00:51 -0800 (-0800), Johannes Erdfelt wrote: > > [...] > > > Recently, I have spent a lot more time waiting on reviews than I > > > have spent writing the actual code. >

Re: [openstack-dev] [Openstack-operators] Resources owned by a project/tenant are not cleaned up after that project is deleted from keystone

On Sat, Feb 21, 2015 at 5:03 AM, Tim Bell wrote: > > A few inline comments and a general point > > How do we handle scenarios like volumes when we have a per-component > janitor rather than a single co-ordinator ? > > To be clean, > > 1. nova should shutdown the instance > 2. nova should then ask

Re: [openstack-dev] [Ironic] patches that only address grammatical/typos

On Wed, Feb 25, 2015, at 12:36 PM, Jay Faulkner wrote: > > > On Feb 25, 2015, at 10:26 AM, Ruby Loo wrote: > > > > Hi, > > > > I was wondering what people thought about patches that only fix grammatical > > issues or misspellings in comments in our code. > > > > I can't believe I'm sending

Re: [openstack-dev] [all] creating a unified developer reference manual

On Wed, Feb 25, 2015 at 11:54 AM, Doug Hellmann wrote: > During yesterday’s cross-project meeting [1], we discussed the "Eventlet > Best Practices” spec [2] started by bnemec. The discussion of that spec > revolved around the question of whether our cross-project specs repository > is the right p

Re: [openstack-dev] [nova][vmware][ironic] Configuring active/passive HA Nova compute

On Fri, Feb 20, 2015 at 3:48 AM, Matthew Booth wrote: > Gary Kotton came across a doozy of a bug recently: > > https://bugs.launchpad.net/nova/+bug/1419785 > > In short, when you start a Nova compute, it will query the driver for > instances and compare that against the expected host of the the i

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

Yeah, it seems ML2 at the least should save you a lot of boilerplate. On Feb 25, 2015 2:32 AM, "Russell Bryant" wrote: > On 02/24/2015 05:38 PM, Kevin Benton wrote: > > OVN implementing it's own control plane isn't a good reason to make it a > > monolithic plugin. Many of the ML2 drivers are for

Re: [openstack-dev] H302 considered harmful

On Wed, Feb 25, 2015 at 12:59 PM, Robert Collins wrote: > On 26 February 2015 at 08:54, melanie witt wrote: > > On Feb 25, 2015, at 10:51, Duncan Thomas > wrote: > > > >> Is there anybody who'd like to step forward in defence of this rule and > explain why it is an improvement? I don't discount

[openstack-dev] [Fuel] [plugins] A simple network to interface mapping in astute.yaml

Hi, fuelers, As you may know, we have a rich and complex network_transformations section in astute.yaml. We use it to describe which OVS/Linux network primitives should be created and how they should be connected together. This section is used by "l23network" Puppet module during the deployment st

Re: [openstack-dev] H302 considered harmful

On 26 February 2015 at 08:54, melanie witt wrote: > On Feb 25, 2015, at 10:51, Duncan Thomas wrote: > >> Is there anybody who'd like to step forward in defence of this rule and >> explain why it is an improvement? I don't discount for a moment the >> possibility I'm missing something, and welco

Re: [openstack-dev] H302 considered harmful

On Feb 25, 2015, at 10:51, Duncan Thomas wrote: > Is there anybody who'd like to step forward in defence of this rule and > explain why it is an improvement? I don't discount for a moment the > possibility I'm missing something, and welcome the education in that case A reason I can think of wo

[openstack-dev] [all] creating a unified developer reference manual

During yesterday’s cross-project meeting [1], we discussed the "Eventlet Best Practices” spec [2] started by bnemec. The discussion of that spec revolved around the question of whether our cross-project specs repository is the right place for this type of document that isn’t a “plan” for a chang

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

The fact that a system doesn't use a neutron agent is not a good justification for monolithic vs driver. The VLAN drivers co-exist with OVS just fine when using VLAN encapsulation even though some are agent-less. There is a missing way to coordinate connectivity with tunnel networks across drivers

Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

Hi, The RFC2544 with near zero packet loss is a pretty standard performance benchmark. It is also used in the OPNFV project ( https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases ). Does this mean that OpenStack will have stateful firewalls (or security groups)? Any oth

Re: [openstack-dev] H302 considered harmful

Thanks for that, Joe. I'd say the cons miss 'It looks ugly in places'. On 25 February 2015 at 20:54, Joe Gordon wrote: > > On Wed, Feb 25, 2015 at 10:51 AM, Duncan Thomas > wrote: > >> Hi >> >> So a review [1] was recently submitted to cinder to fix up all of the >> H302 violations, and turn on

Re: [openstack-dev] H302 considered harmful

On Wed, Feb 25, 2015 at 10:51 AM, Duncan Thomas wrote: > Hi > > So a review [1] was recently submitted to cinder to fix up all of the H302 > violations, and turn on the automated check for them. This is certainly a > reasonable suggestion given the number of manual reviews that -1 for this > issu

[openstack-dev] H302 considered harmful

Hi So a review [1] was recently submitted to cinder to fix up all of the H302 violations, and turn on the automated check for them. This is certainly a reasonable suggestion given the number of manual reviews that -1 for this issue, however I'm far from convinced it actually makes the code more re

Re: [openstack-dev] [nova] bp serial-ports *partly* implemented?

Sahid Orentino Ferdjaoui wrote on 02/25/2015 12:58:30 PM: > [...] > > So we probably have a bug here, can you at least refer it in launchpad > ? We need to see if the problem comes from the code in Nova or a bad > interpretation of the behavior of libvirt or a bug in libvirt. > > Please on the

Re: [openstack-dev] [neutron][docs] VPNaaS API reference missing...

As you can see, netconn-api has gone into the Openstack-attic. A few months ago, all neutron API reference docs were moved into neutron-specs (similar things happened to other projects). The new home of the VPN API spec is [1] Salvatore [1] http://specs.openstack.org/openstack/neutron-specs/spec

Re: [openstack-dev] [OpenStackClient] New meeting time

\o/ I'll be there! Thanks for organizing it all Dean. Steve Dean Troyer wrote on 02/25/2015 12:19:38 PM: > From: Dean Troyer > To: OpenStack Development Mailing List > Date: 02/25/2015 12:32 PM > Subject: [openstack-dev] [OpenStackClient] New meeting time > > [Parse the subject as new-meet

[openstack-dev] [neutron][docs] VPNaaS API reference missing...

Not sure where it disappeared, but there are none of the API pages for VPNaaS exist. This was added some time ago (I think it was review 41702 back in 9/2013). Mentioned to Edgar, but wanted to let the community know... PCM (Paul Michali) IRC pc_m (irc.freenode.com) Twitter...

Re: [openstack-dev] [stable][all] Revisiting the 6 month release cycle

On Tue, Feb 24, 2015, Jeremy Stanley wrote: > On 2015-02-24 10:00:51 -0800 (-0800), Johannes Erdfelt wrote: > [...] > > Recently, I have spent a lot more time waiting on reviews than I > > have spent writing the actual code. > > That's awesome, assuming what you mean here is that you've spent > m

Re: [openstack-dev] [devstack] [Cinder-GlusterFS CI] centos7 gate job abrupt failures

On Wed, Feb 25, 2015 at 8:42 PM, Deepak Shetty wrote: > > > On Wed, Feb 25, 2015 at 6:34 PM, Jeremy Stanley wrote: > >> On 2015-02-25 17:02:34 +0530 (+0530), Deepak Shetty wrote: >> [...] >> > Run 2) We removed glusterfs backend, so Cinder was configured with >> > the default storage backend i.e

Re: [openstack-dev] [Ironic] patches that only address grammatical/typos

> On Feb 25, 2015, at 10:26 AM, Ruby Loo wrote: > > Hi, > > I was wondering what people thought about patches that only fix grammatical > issues or misspellings in comments in our code. > > I can't believe I'm sending out this email, but as a group, I'd like it if we > had a similar underst

[openstack-dev] [OpenStackClient] New meeting time

[Parse the subject as new-meeting time, as there is no old meeting time...] OpenStackClient will start holding periodic development team meetings on Thursday Feb 26 at 18:00 UTC in Freenode's #openstack-meeting channel. One of the first things I want to cover is timing and frequency of these meet

Re: [openstack-dev] [Ironic] patches that only address grammatical/typos

On 02/25/2015 05:26 PM, Ruby Loo wrote: Hi, I was wondering what people thought about patches that only fix grammatical issues or misspellings in comments in our code. I can't believe I'm sending out this email, but as a group, I'd like it if we had a similar understanding so that we treat all

Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

On 02/25/2015 05:52 AM, Miguel Ángel Ajo wrote: I’m writing a plan/script to benchmark OVS+OF(CT) vs OVS+LB+iptables+ipsets, so we can make sure there’s a real difference before jumping into any OpenFlow security group filters when we have connection tracking in OVS. The plan is to keep all of i

Re: [openstack-dev] [Ironic] patches that only address grammatical/typos

Ruby Loo said on Wed, Feb 25, 2015 at 11:26:56AM -0500: > I was wondering what people thought about patches that only fix grammatical > issues or misspellings in comments in our code. For my money, a patch fixing nits has value but only if it fixes a few. If it's a follow-up patch it should fix al

Re: [openstack-dev] [Congress][Delegation] Initial workflow design

Hi Tim, All, 1) Step 3: The VM-placement engine is also a "datalog engine" . Right? When policies are delegated: when policies are inserted? When the VM-placement engine has already registered itself all policies are given to it? "In our example, this would mean the domain-specific pol

Re: [openstack-dev] [api][all] - Openstack.error common library

On Wed, Feb 25, 2015, at 09:33 AM, Eugeniya Kudryashova wrote: > Hi, stackers! > > As was suggested in topic [1], using an HTTP header was a good solution > for > communicating common/standardized OpenStack API error codes. > > So I’d like to begin working on a common library, which will collec

Re: [openstack-dev] [Neutron] (RE: Change in openstack/neutron-specs[master]: Introducing Tap-as-a-Service)

>From previous discussion, it appeared the proposer really felt this needed to be a "core" neutron aspect. Where by "core" they meant both be part of the core API and part of openstack/neutron. On the other hand, we also agreed that the best way forward was to develop a service plugin which in a w

Re: [openstack-dev] [Neutron] db-level locks, non-blocking algorithms, active/active DB clusters and IPAM

On 25 February 2015 at 16:52, Carl Baldwin wrote: > jOn Mon, Feb 23, 2015 at 5:07 AM, Salvatore Orlando > wrote: > > Lazy-Stacker summary: > > I am doing some work on Neutron IPAM code for IP Allocation, and I need > to > > found whether it's better to use db locking queries (SELECT ... FOR > UP

Re: [openstack-dev] [api][all][log] - Openstack.error common library

Hi Eugeniya, Please have a look on the discussion under tag [log]. We’ve been discussing around this topic (bit wider, not limiting to API errors) quite regular since Paris Summit and we should have X-project specs for review quite soon after the Ops meetup. The workgroup meetings will start as

[openstack-dev] [all] oslo.messaging 1.7.0 released

The Oslo team is thrilled to announce the release of: oslo.messaging 1.7.0: Oslo Messaging API For more details, please see the git log history below and: http://launchpad.net/oslo.messaging/+milestone/1.7.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.messag

[openstack-dev] [Ironic] patches that only address grammatical/typos

Hi, I was wondering what people thought about patches that only fix grammatical issues or misspellings in comments in our code. I can't believe I'm sending out this email, but as a group, I'd like it if we had a similar understanding so that we treat all patches in a similar (dare I say it, cons

Re: [openstack-dev] [Neutron] db-level locks, non-blocking algorithms, active/active DB clusters and IPAM

On 2/25/15, 10:52 AM, "Carl Baldwin" wrote: > >Wondering if Kilo should just focus on creating the interface which >will allow us to create multiple implementations and swap them out >during the Liberty development cycle. Hopefully, this could include >even something like your option 2 below. >

Re: [openstack-dev] [Neutron] db-level locks, non-blocking algorithms, active/active DB clusters and IPAM

On 25 February 2015 at 02:35, Robert Collins wrote: > On 24 February 2015 at 01:07, Salvatore Orlando > wrote: > > Lazy-Stacker summary: > ... > > In the medium term, there are a few things we might consider for > Neutron's > > "built-in IPAM". > > 1) Move the allocation logic out of the driver,

Re: [openstack-dev] [Ironic] Stepping down from Ironic Core

Hi Robert, I'm really glad I had a chance to interact with you. Thanks for everything; I'm hopeful that we'll see you back. Ironic still has lots of life, so I guess life goes on without lifeless, but I'll miss you still. ;) --ruby

Re: [openstack-dev] [Neutron] db-level locks, non-blocking algorithms, active/active DB clusters and IPAM

On 25 February 2015 at 13:50, Eugene Nikanorov wrote: > Thanks for putting this all together, Salvatore. > > I just want to comment on this suggestion: > > 1) Move the allocation logic out of the driver, thus making IPAM an > independent service. The API workers will then communicate with the IPA

Re: [openstack-dev] [Neutron] db-level locks, non-blocking algorithms, active/active DB clusters and IPAM

jOn Mon, Feb 23, 2015 at 5:07 AM, Salvatore Orlando wrote: > Lazy-Stacker summary: > I am doing some work on Neutron IPAM code for IP Allocation, and I need to > found whether it's better to use db locking queries (SELECT ... FOR UPDATE) > or some sort of non-blocking algorithm. > Some measures su

Re: [openstack-dev] [Neutron] db-level locks, non-blocking algorithms, active/active DB clusters and IPAM

Thanks Clint. I think you are bringing an interesting and disruptive perspective into this discussion. Disruptive because one thing that has not been considered so far in this thread is that perhaps we don't need at all to leverage multi-master capabilities for write operations. More comments inl

Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

On 02/25/2015 08:52 AM, Miguel Ángel Ajo wrote: > I’m writing a plan/script to benchmark OVS+OF(CT) vs OVS+LB+iptables+ipsets, > so we can make sure there’s a real difference before jumping into any > OpenFlow security group filters when we have connection tracking in OVS. > > The plan is to keep

Re: [openstack-dev] [devstack] [Cinder-GlusterFS CI] centos7 gate job abrupt failures

On Wed, Feb 25, 2015 at 6:34 PM, Jeremy Stanley wrote: > On 2015-02-25 17:02:34 +0530 (+0530), Deepak Shetty wrote: > [...] > > Run 2) We removed glusterfs backend, so Cinder was configured with > > the default storage backend i.e. LVM. We re-created the OOM here > > too > > > > So that proves th

Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

On Wed, Feb 25, 2015 at 8:49 AM, Miguel Ángel Ajo wrote: > On Wednesday, 25 de February de 2015 at 15:38, Kyle Mestery wrote: > > On Wed, Feb 25, 2015 at 7:52 AM, Miguel Ángel Ajo > wrote: > > I’m writing a plan/script to benchmark OVS+OF(CT) vs > OVS+LB+iptables+ipsets, > so we can make sure t

Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

On Wednesday, 25 de February de 2015 at 15:38, Kyle Mestery wrote: > On Wed, Feb 25, 2015 at 7:52 AM, Miguel Ángel Ajo (mailto:majop...@redhat.com)> wrote: > > I’m writing a plan/script to benchmark OVS+OF(CT) vs > > OVS+LB+iptables+ipsets, > > so we can make sure there’s a real difference befo

Re: [openstack-dev] [nova] Shared storage support

On Wed, Feb 25, 2015 at 02:08:32PM +, Gary Kotton wrote: > Hi, > There is an issue with the statistics reported when a nova compute > driver has shared storage attached. That is, there may be more than > one compute node reporting on the shared storage. A patch has been > posted - https://revie

Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

On Wed, Feb 25, 2015 at 7:52 AM, Miguel Ángel Ajo wrote: > I’m writing a plan/script to benchmark OVS+OF(CT) vs > OVS+LB+iptables+ipsets, > so we can make sure there’s a real difference before jumping into any > OpenFlow security group filters when we have connection tracking in OVS. > > The pla

Re: [openstack-dev] [nova][vmware][ironic] Configuring active/passive HA Nova compute

On 25/02/15 11:51, Radoslav Gerganov wrote: > On 02/23/2015 03:18 PM, Matthew Booth wrote: >> On 23/02/15 12:13, Gary Kotton wrote: >>> >>> >>> On 2/23/15, 2:05 PM, "Matthew Booth" wrote: >>> On 20/02/15 11:48, Matthew Booth wrote: > Gary Kotton came across a doozy of a bug recently:

[openstack-dev] [api][all] - Openstack.error common library

Hi, stackers! As was suggested in topic [1], using an HTTP header was a good solution for communicating common/standardized OpenStack API error codes. So I’d like to begin working on a common library, which will collect all openstack HTTP API errors, and assign them string error codes. My suggest

[openstack-dev] [nova] Shared storage support

Hi, There is an issue with the statistics reported when a nova compute driver has shared storage attached. That is, there may be more than one compute node reporting on the shared storage. A patch has been posted - https://review.openstack.org/#/c/155184. The direction here was to add a extra p

[openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

I’m writing a plan/script to benchmark OVS+OF(CT) vs OVS+LB+iptables+ipsets, so we can make sure there’s a real difference before jumping into any OpenFlow security group filters when we have connection tracking in OVS. The plan is to keep all of it in a single multicore host, and make all the

Re: [openstack-dev] [all] Replace eventlet with asyncio

Excerpts from Victor Stinner's message of 2015-02-25 02:12:05 -0800: > Hi, > > > I also just put up another proposal to consider: > > https://review.openstack.org/#/c/156711/ > > """Sew over eventlet + patching with threads""" > > My asyncio spec is unclear about WSGI, I just wrote > > "The spec

Re: [openstack-dev] [manuals] Training guide issue

On 02/25/2015 03:16 AM, Ajay Kalambur (akalambu) wrote: > Hi > I am trying to just get started with openstack commits and wanted to > start by fixing some documentation bugs. I assigned 3 bugs which seem to > be in the same file/area Welcome! Let's discuss this on the openstack-docs mailing list

Re: [openstack-dev] [Neutron] db-level locks, non-blocking algorithms, active/active DB clusters and IPAM

Excerpts from Salvatore Orlando's message of 2015-02-23 04:07:38 -0800: > Lazy-Stacker summary: > I am doing some work on Neutron IPAM code for IP Allocation, and I need to > found whether it's better to use db locking queries (SELECT ... FOR UPDATE) > or some sort of non-blocking algorithm. > Some

Re: [openstack-dev] [devstack] [Cinder-GlusterFS CI] centos7 gate job abrupt failures

On 2015-02-25 17:02:34 +0530 (+0530), Deepak Shetty wrote: [...] > Run 2) We removed glusterfs backend, so Cinder was configured with > the default storage backend i.e. LVM. We re-created the OOM here > too > > So that proves that glusterfs doesn't cause it, as its happening > without glusterfs to

Re: [openstack-dev] [Neutron] db-level locks, non-blocking algorithms, active/active DB clusters and IPAM

Thanks for putting this all together, Salvatore. I just want to comment on this suggestion: > 1) Move the allocation logic out of the driver, thus making IPAM an independent service. The API workers will then communicate with the IPAM service through a message bus, where IP allocation requests wil

Re: [openstack-dev] [cinder] Resuming of workflows/tasks

Hi Michal, > 1. Need of distributed lock to avoid same task being resumed by two instances > of a service. Do we need tooz to do that or is there any other solution? Tooz library is already being used in ceilometer to manage group membership. (https://github.com/openstack/ceilometer/blob/master

Re: [openstack-dev] [nova] Request non-priority feature freeze exception for VIF_TYPE_TAP

On Wed, Feb 25, 2015 at 11:46:05AM +, Neil Jerram wrote: > Although we are past the non-priority deadline, I have been encouraged > to request this late exception for Project Calico's spec and code adding > VIF_TYPE_TAP to Nova. I'm afraid you're also past the freeze exception request deadline

Re: [openstack-dev] [nova] bp serial-ports *partly* implemented?

On Tue, Feb 24, 2015 at 04:19:39PM +0100, Markus Zoeller wrote: > Sahid Orentino Ferdjaoui wrote on 02/23/2015 > 11:13:12 AM: > > > From: Sahid Orentino Ferdjaoui > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > Date: 02/23/2015 11:17 AM > > Subject: Re: [opensta

[openstack-dev] [nova] Request non-priority feature freeze exception for VIF_TYPE_TAP

Although we are past the non-priority deadline, I have been encouraged to request this late exception for Project Calico's spec and code adding VIF_TYPE_TAP to Nova. https://review.openstack.org/#/c/130732/ (spec) https://review.openstack.org/#/c/146914/ (code) Why might you consider this? - It

  1   2   >