Re: [openstack-dev] [Kuryr] Proposing vikasc for kuryr-libnetwork core

+1 Vikas has been working on various aspects of Kuryr with dedication for some time. So yes it's about time :) Best, Mohammad From: Antoni Segura Puimedon To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [kuryr] kuryr-libnetwork split

<openstack-dev@lists.openstack.org>, Mohammad Banikazemi/Watson/IBM@IBMUS, Gal Sagie <gal.sa...@gmail.com>, Irena Berezovsky <ir...@midokura.com> Date: 07/01/2016 11:29 AM Subject:Re: [kuryr] kuryr-libnetwork split Hi Toni, There seems to be some

Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port isActive

that message queue is in itself a scalability bottleneck. I guess another option would be for the using system to determine for itself when the port appears to be working, e.g. by the host pinging the container/pod's IP address. Regards,     Neil On Wed, Jun 8, 2016 at 4:23 PM Mohammad Banikazemi <m...

Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port isActive

n/tree/neutron/notifiers/nova.py On 8 June 2016 at 17:23, Mohammad Banikazemi <m...@us.ibm.com> wrote: For the Kuryr project, in order to support blocking until vifs are plugged in (that is adding config options similar to the following options define in Nova: vif_plugging_is_fata

[openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port is Active

For the Kuryr project, in order to support blocking until vifs are plugged in (that is adding config options similar to the following options define in Nova: vif_plugging_is_fatal and vif_plugging_timeout), we need to detect that the Neutron plugin being used is done with plugging a given vif.

Re: [openstack-dev] [kuryr] Port binding query

e questions)" <openstack-dev@lists.openstack.org> Cc: Mohammad Banikazemi/Watson/IBM@IBMUS Date: 05/12/2016 11:51 AM Subject:Re: [openstack-dev] [kuryr] Port binding query On Thu, May 12, 2016 at 4:50 PM, Neil Jerram <n...@tigera.io> wrote: I'm trying Kuryr with netw

Re: [openstack-dev] [Kuryr] will we use os-vif in kuryr

Yes, we have been aware of the os-vif effort and will try to use it as soon as it is released. The scripts we currently use are to enable the use of the Neutron reference plugins/drivers in the meantime. Best, Mohammad From: "Daniel P. Berrange" To: "OpenStack

Re: [openstack-dev] [Kuryr] New Container Networking Model - Kubernetes, Kuryr, and Neutron

The log of this IRC meeting can be found here: http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-26-15.03.log.html Best, Mohammad From: Mohammad Banikazemi/Watson/IBM@IBMUS To: "OpenStack Development Mailing List \(not for usage questions \)" <

Re: [openstack-dev] [Kuryr] New Container Networking Model - Kubernetes, Kuryr, and Neutron

stack-dev] [Kuryr] New Container Networking Model - Kubernetes, Kuryr, and Neutron - Original Message ----- > From: "Mohammad Banikazemi" <m...@us.ibm.com> > To: openstack-dev@lists.openstack.org > > We are going to discuss CNI, the Container Net

[openstack-dev] [Kuryr] New Container Networking Model - Kubernetes, Kuryr, and Neutron

We are going to discuss CNI, the Container Network Interface at 15:00 UTC on Tuesday (!0am EST). In particular, we like to start putting together a plan for supporting CNI in the Kuryr project. All interested parties are welcome and encouraged to attend. Thanks, Mohammad

Re: [openstack-dev] [kuryr] Does Kuryr support multi-tenant

Considering that the underlying container technology is not multi-tenant (as of now), your observation is correct in that all neutron resources are made for a single tenant. Until Docker supports multi tenancy, we can possibly use network options and/or wrappers for docker/swarm clients to achieve

[openstack-dev] [Kuryr] Docker Swarm and Kuryr Integration Demo

I plan to write a blog post about it describing the mechanism 2) Mohammad Banikazemi verified Kuryr works with Docker Swarm seamlessly    and we are compatible with latest Docker libnetwork 3) We have fullstack job running in the gate, basically these tests are running with a     working Op

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

"Fox, Kevin M" wrote on 09/15/2015 02:57:10 PM: > From: "Fox, Kevin M" > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 09/15/2015 02:59 PM > Subject: Re: [openstack-dev]

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

"Fox, Kevin M" wrote on 09/15/2015 02:00:03 PM: > From: "Fox, Kevin M" > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 09/15/2015 02:02 PM > Subject: Re: [openstack-dev]

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

the > floating ips on the LB instead of the instances, and putting a pool > of instances behind it. So our instance counts are growing faster > then our usage of floating IP's. > > Thanks, > Kevin > > From: Mohammad Banikazemi [m...@us.ibm.com] > Sent: Tuesday, Septembe

Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to Neutron

UTC. Maybe at 14 or 15h ? On Wed, Jul 22, 2015 at 10:29 PM, Mohammad Banikazemi m...@us.ibm.com wrote: Gal, This time conflicts with the Neutron ML2 weekly meeting time [1]. I realize there are several networking related weekly meetings, but I would like to see if we can find

Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

Daneyon Hansen (danehans) daneh...@cisco.com wrote on 07/23/2015 03:40:38 PM: From: Daneyon Hansen (danehans) daneh...@cisco.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Mohammad Banikazemi/Watson/ IBM@IBMUS, Steven Dake (stdake

Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

$ docker -d --kv-store=consul:localhost:8500 -- label=com.docker.network.driver.kuryr.bind_interface=eth0 -- label=com.docker.network.driver.kuryr.neutron_api=10.10.10.10 --label=com.docker.network.driver.kuryr.token=AUTH_tk713d067336d21348bcea1ab220965485 Toni, Why do you want to have

Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

I let the creators of the project speak for themselves but here is my take on project Kuryr. The goal is not to containerize Neutron or other OpenStack services. The main objective is to use Neutron as a networking backend option for Docker. The original proposal was to do so in the context of

Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to Neutron

Gal, This time conflicts with the Neutron ML2 weekly meeting time [1]. I realize there are several networking related weekly meetings, but I would like to see if we can find a different time. I suggest the same time, that is 1600 UTC but either on Mondays or Thursdays. Please note there is the

Re: [openstack-dev] [Neutron] Modular L2 Agent

Thanks Sean for creating the rfe. I think we can go beyond the OVS and LB agents and aim for providing a framework where any agent (if and when needed) can benefit from it. We can continue the discussion on launchpad. Best, Mohammad From: Sean M. Collins s...@coreitpro.com To:

[openstack-dev] [Neutron] Modular L2 Agent

During the last couple of ML2 group meetings, the subject of Modular L2 Agents has come up again and I was tasked to bring up the subject to the attention of the larger community. We are aware of the ongoing efforts to improve the L2 agent(s) and the patches which are currently under review and

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

curious if a n-net - provider network side step (still on linux bridge) would actually be a more reasonable transition for most environments. -Sean -- Sean Dague http://dague.net [attachment signature.asc deleted by Mohammad Banikazemi/Watson/ IBM

Re: [openstack-dev] [Openstack-operators] [Neutron] allow_overlapping_ips (was: Deprecating the use_namespaces option ...)

The allow_overlapping_ips configuration option in it's current form was mainly used to cover older distros that did not support namespaces as you have mentioned. That's why in its current form this option operates across all networks of all tenants. That is, if the option is set to false,

Re: [openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB

It is perhaps worth mentioning that there is an effort to implement a generic synchronization mechanism (between Neutron and backend controllers/devices) in the ML2 plugin [1]. A possible framework for its eventual implementation is in an early discussion/proof-of-concept WIP state [2].

Re: [openstack-dev] [Neutron] Bulk network operations

Saksham, The Neutron bulk operations are by definition atomic [1]: Bulk operations are always performed atomically, meaning that either all or none of the objects in the request body are created. Best, Mohammad [1] https://wiki.openstack.org/wiki/Neutron/APIv2-specification From: Saksham

Re: [openstack-dev] [neutron] FYI: Just abandoned old reviews

Looks like some reviews which should have been marked by this script were not. At least I noticed one such review [1]. [1] https://review.openstack.org/#/c/122382/ From: Kyle Mestery mest...@mestery.com To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

I had done some work on looking at L2 agents and identifying how we may want to go about creating a Modular L2 Agent framework to make the agent code more modular, avoid code replication across multiple L2 agents, and to make adding new features and writing new agents (if/when necessary) easier.

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

. There is so much you can capture in an etherpad. Thanks for clarifying it promptly. Salvatore On 18 November 2014 19:32, Mohammad Banikazemi m...@us.ibm.com wrote: I had done some work on looking at L2 agents and identifying how we may want to go about creating a Modular L2 Agent framework

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

In the patch being referred to here and in the IBM controller, the project ID is the unique identifier used. The name is simply an additional piece of information that may perhaps be used for debugging. The back-end (controller) keeps a name not as a unique identifier but in addition to the

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

Akihiro Motoki amot...@gmail.com wrote on 09/22/2014 12:50:43 PM: From: Akihiro Motoki amot...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 09/22/2014 12:53 PM Subject: Re: [openstack-dev] [Neutron] - what integration

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

I can only see the use of a separate project for Group Policy as a tactical and temporary solution. In my opinion, it does not make sense to have the Group Policy as a separate project outside Neutron (unless the new project is aiming to replace Neutron and I do not think anybody is suggesting

Re: [openstack-dev] [Neutron] Use public IP address as instance fixed IP

Would this work? We used to have warnings in Neutron docs indicating that instances should not be attached to external networks: It is important to understand that you should not attach the instance to Ext-Net directly. Instead, you must use a floating IP to make it accessible from the external

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 mest...@mestery.com To: OpenStack Development Mailing

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

Thierry Carrez thie...@openstack.org wrote on 08/07/2014 06:23:56 AM: From: Thierry Carrez thie...@openstack.org To: openstack-dev@lists.openstack.org Date: 08/07/2014 06:25 AM Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward Armando M. wrote: This

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

Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 04:09:20 PM: From: Jay Pipes jaypi...@gmail.com To: openstack-dev@lists.openstack.org Date: 08/06/2014 04:12 PM Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward On 08/06/2014 03:46 PM, Kevin Benton

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

Yes, indeed. I do not want to be over dramatic but the discussion on the original Group Based Policy and the way forward thread is nothing short of heartbreaking. After months and months of discussions, three presentations at the past three summits, a design session at the last summit, and (most

Re: [openstack-dev] 答???: [Neutron] Auth token in context

Yes, Here: https://review.openstack.org/#/c/111756/ From: Kevin Benton blak...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Cc: isaku.yamah...@gmail.com Date: 08/04/2014 01:01 PM Subject:Re:

Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy

I don't think another extension is needed. Beyond the CLI, very limited changes (additions) in the model/db such as those I suggested in [1] can be helpful and will minimize the changes needed on the client side. Best, Mohammad [1] https://review.openstack.org/#/c/103755/ (Patch Set 3)

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

Thanks Kyle for the update. As noted below, we have been in the process of upgrading the SDN-VE CI system to a Zuul based system and this has caused an interruption in our voting. We have resolved the issues we were facing with standing up our new system and are close to having our system voting

Re: [openstack-dev] [Neutron][ML2] Modular L2 agent architecture

Zang, thanks for your comments. I think what you are suggesting is perhaps orthogonal to having Resource and Agent drivers. By that I mean we can have what you are suggesting and keep the Resource and Agent drivers. The reason for having Resource drivers is to provide the means for possibly

Re: [openstack-dev] Help in writing new neutron plugin

Have you looked at https://wiki.openstack.org/wiki/NeutronDevelopment In particular, this section may be useful to you: Developing a Neutron Plugin You may also want to look at the following presentation/talk and look for more such presentations from OpenStack Summits:

Re: [openstack-dev] [Neutron][ml2] Tracking the reviews for ML2 related specs

being tracked this may be helpful as long as the code owners keep the table up to date. Best, Mohammad From: Irena Berezovsky ire...@mellanox.com To: Mohammad Banikazemi/Watson/IBM@IBMUS, Cc: OpenStack Development Mailing List (not for usage questions) openstack-dev

Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

Gonçalves m...@cgoncalves.pt wrote: Hi, On 27 May 2014, at 15:55, Mohammad Banikazemi m...@us.ibm.com wrote: GP like any other Neutron extension can have different implementations. Our idea has been to have the GP code organized similar to how ML2 and mechanism drivers are organized

[openstack-dev] [Neutron][ml2] Tracking the reviews for ML2 related specs

In order to make the review process a bit easier (without duplicating too much data and without creating too much overhead), we have created a wiki to keep track of the ML2 related specs for the Juno cycle [1]. The idea is to organize the people who participate in the ML2 subgroup activities and

[openstack-dev] [Neutron][ML2] Modular L2 agent architecture

Following the discussions in the ML2 subgroup weekly meetings, I have added more information on the etherpad [1] describing the proposed architecture for modular L2 agents. I have also posted some code fragments at [2] sketching the implementation of the proposed architecture. Please have a look

Re: [openstack-dev] [Neutron][ML2] Modular agent architecture

Development Mailing List openstack-dev@lists.openstack.org, Mohammad Banikazemi/Watson/IBM@IBMUS, Date: 05/30/2014 06:25 AM Subject:[openstack-dev][Neutron][ML2] Modular agent architecture Hi all, Modular agent seems to have to choose between two type

Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

, Date: 05/26/2014 09:46 PM Subject:Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver On May 26, 2014 4:27 PM, Mohammad Banikazemi m...@us.ibm.com wrote: Armando, I think there are a couple of things that are being mixed up here, at least as I see

Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

Armando, I think there are a couple of things that are being mixed up here, at least as I see this conversation :). The mapping driver is simply one way of implementing GP. Ideally I would say, you do not need to implement the GP in terms of other Neutron abstractions even though you may choose

Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project

Hi Mike. I think we still owe you a response to your earlier email as we recover from the summit but let me address your current questions below. On May 22, 2014, at 6:55 PM, Mike Grima mike.r.gr...@gmail.com wrote: Hello, Just to make sure I understand: 1.) I’m assuming that you can

Re: [openstack-dev] [Neutron] reservation of fixed ip

Well, for a use case we had in mind we were trying to figure out how to simply get an IP address on a subnet. We essentially want to use such an address internally by the controller and make sure it is not used for a port that gets created on a network with that subnet. In this use case, an

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

Thanks to everyone who participated in the Group Policy meeting [1] earlier today. A lot of good discussion that hopefully will continue with participation from the larger community. I wanted to first make a comment about how the Group Policy work was received outside the Neutron community and

Re: [openstack-dev] [Neutron] ML2 extensions info propagation

Hi Mathieu, Yes, the enhancement of the get_device_details method sounds like an interesting and useful option. The option of using drivers in the agent for supporting extensions is to make the agent more modular and allow for selectively supporting extensions as needed by a given agent. If we

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

...@cable.comcast.com wrote: On Tue, May 06, 2014 at 07:17:26PM EDT, Mohammad Banikazemi wrote: There are networking talks in the general session in the afternoon on Thursday including the talk on Network Policies from 1:30 to 2:10pm. Anything after that is ok with me. How does 2:30PM

Re: [openstack-dev] [neutron] Mid-Cycle Meeting Location

Kyle Mestery mest...@noironetworks.com wrote on 05/08/2014 04:45:43 PM: From: Kyle Mestery mest...@noironetworks.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 05/08/2014 04:46 PM Subject: [openstack-dev] [neutron] Mid-Cycle

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

+1. Please announce a date/time here so we can perhaps avoid any conflicts with others who plan to use the networking pod. Best, Mohammad From: Stephen Wong s3w...@midokura.com To: OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [Neutron][ml2] Etherpad for the design session on Modular L2 Agents

Please note that I have created an etherpad for the Modular L2 Agent session at [1]. It relates to one of the three topics that are to be discussed during the Modular Layer2 Agent design session scheduled for Thursday 11:50am-12:30pm [2]. Please update the etherpad and/or use the ML or contact me

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

wrote: On Tue, May 06, 2014 at 03:04:09PM EDT, Mohammad Banikazemi wrote: +1. Please announce a date/time here so we can perhaps avoid any conflicts with others who plan to use the networking pod. Best, Agreed. So - Thursday seems to be a pretty light in the afternoon

Re: [openstack-dev] [Neutron][ml2] Etherpad for the design session on Modular L2 Agents

Thanks for the suggestion. That's what I plan to do next (barring other possible suggestions). While the sharing is limited in some cases, it appears to be significant in other cases (e.g., the ovs and the mlnx agents). Best, Mohammad From: yamam...@valinux.co.jp (YAMAMOTO Takashi) To:

Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project

Hi Mike, Thanks for your interest in OpenStack and Neutron. Are there any published papers you can point us to? It may be easier to understand your work by reading/reviewing your papers. Best, Mohammad From: Mike Grima mike.r.gr...@gmail.com To: openstack-dev@lists.openstack.org, Date:

Re: [openstack-dev] [Neutron] Flavor(?) Framework

As I understand the proposed flavor framework, the intention is to provide a mechanism for specifying different flavors of a given service type as they are already defined. So using the term type may be confusing. Here we want to specify possibly different set of capabilities within a given

Re: [openstack-dev] [Neutron][ML2][Ml2Plugin] Setting _original_network in NetworkContext:

Nader, During the last ML2 IRC weekly meeting [1] having per-MD extensions was mentioned. This is an important topic in my opinion. You may want to add a proposal for a design session on this topic at [2] and/or add this topic to the agenda for the next ML2 weekly meeting [3] for further

[openstack-dev] [neutron][policy] Presentation from last summit

During the Group Policy IRC meeting earlier today, the talk I gave during the last summit (in Hong Kong) came up. I couldn't find the link to the slides during the meeting. In case anyone is interested, the slides can be found here:

Re: [openstack-dev] [Neutron] advanced servicevm framework IRC meeting March 18(Tuesday) 23:00 UTC

Thanks for setting up the meeting. I would second the request for change of the time slot; Hope to attend this one and see if we can come up with a better time slot. With respect to other suggestions, it would be great if we start with a report on the current state of this work. Something similar

Re: [openstack-dev] [neutron][policy] Integrating network policies and network services

:Re: [openstack-dev] [neutron][policy] Integrating network policies and network services Mohammad, Can you share details on the contract-based policy model? - Louis From: Mohammad Banikazemi [mailto:m...@us.ibm.com] Sent: Friday, March 14, 2014 3:18 PM To: OpenStack

Re: [openstack-dev] [Neutron] Docs for new plugins

/config-reference/content/networking-options-plugins.html Thanks, Edgar From: Mohammad Banikazemi m...@us.ibm.com Date: Monday, March 10, 2014 2:40 PM To: OpenStack List openstack-dev@lists.openstack.org Cc: Edgar Magana emag...@plumgrid.com Subject: Re: [openstack-dev] [Neutron

Re: [openstack-dev] [neutron][policy] Integrating network policies and network services

Kanzhe, thanks for your response to my comments and questions. Please see below. From: Kanzhe Jiang kan...@gmail.com [...] On Fri, Mar 14, 2014 at 3:18 PM, Mohammad Banikazemi m...@us.ibm.com wrote: [...] 3- For the service chain creation, I am sure there are good reasons for requiring

Re: [openstack-dev] [neutron][policy] Integrating network policies and network services

I think there are a couple of issues here: 1- Having network services in VMs: There was a design summit session in this regard in Hong Kong: Framework for Advanced Services in VMs [1]. There is a corresponding blueprint [2] and some code submitted for early review marked as work in progress [3].

[openstack-dev] [neutron][policy] Integrating network policies and network services

We have started looking at how the Neutron advanced services being defined and developed right now can be used within the Neutron policy framework we are building. Furthermore, we have been looking at a new model for the policy framework as of the past couple of weeks. So, I have been trying to

Re: [openstack-dev] [Neutron] Docs for new plugins

://docs.openstack.org/havana/config-reference/content/networking-options-plugins.html Thanks, Edgar From: Mohammad Banikazemi m...@us.ibm.com Date: Monday, March 10, 2014 2:40 PM To: OpenStack List openstack-dev@lists.openstack.org Cc: Edgar Magana emag...@plumgrid.com Subject: Re: [openstack-dev

Re: [openstack-dev] [Neutron] Docs for new plugins

] [Neutron] Docs for new plugins On 13/03/14 13:43, Mohammad Banikazemi wrote: Thanks for your response. It looks like the page you are referring to gets populated automatically and I see a link already added to it for the new plugin. I also see a file corresponding to the new plugin

Re: [openstack-dev] [Neutron] Docs for new plugins

Would like to know what to do for adding documentation for a new plugin. Can someone point me to the right place/process please. Thanks, Mohammad___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [neutron][policy] Using network services with network policies

...@gmail.com To: Mohammad Banikazemi/Watson/IBM@IBMUS, Cc: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 02/17/2014 02:12 AM Subject:Re: [openstack-dev] [neutron][policy] Using network services with network

[openstack-dev] [neutron][policy] Using network services with network policies

During the last IRC call we started talking about network services and how they can be integrated into the group Policy framework. In particular, with the redirect action we need to think how we can specify the network services we want to redirect the traffic to/from. There has been a

Re: [openstack-dev] [Neutron] Group Policy questions

Hi Carlos, We have just started looking at the same issues you have mentioned. Please follow the email thread started by me earlier today ([openstack-dev] [neutron][policy] Using network services with network policies). We will be spending more time on these topics during our upcoming weekly IRC

[openstack-dev] [qa] Adding support for a new plugin

Hi everybody, We have a new Neutron plugin being reviewed (approved for the Icehouse-3 milestone) and would like to add the corresponding file in devstack. Not being sure as to how to do this, I opened a blueprint ( https://blueprints.launchpad.net/devstack/+spec/ibm-sdnve-plugin-support ) and

Re: [openstack-dev] [neutron] [group-policy] Canceling tomorrows meeting

Hi everybody, Since some of us are away attending the OpenDaylight Summit, we are going to cancel the Thursday Feb 6 meeting. We have started coding for our PoC implementation and should have some code for review by next week. Please use the mailing list for discussing Group Policy related

[openstack-dev] [neutron] [third-party-testing] Which patchset triggered the test

Have a question regarding the Jenkins/Gerrit setup for third party testing setups. When Jenkins get triggered by a patchset through the Gerrit trigger plug-in, you can execute a set of shell scripts. How do you get the information about the patchset that triggered the test? In particular, in

Re: [openstack-dev] [neutron] [third-party-testing] Which patchset triggered the test

://etherpad.openstack.org/p/multi-node-neutron-tempest if you'll set NEUTRON_BRANCH=$GERRIT_REFSPEC in the localrc then Devstack will pull the change which triggered the build. Try env shell command to find out what are the rest of the environment variables. Best, --- Roey From: Mohammad Banikazemi [m...@us.ibm.com

Re: [openstack-dev] [neutron] [third-party-testing] Sharing information

Jay Pipes jaypi...@gmail.com wrote on 01/17/2014 04:32:55 PM: From: Jay Pipes jaypi...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 01/17/2014 04:37 PM Subject: Re: [openstack-dev] [neutron] [third-party-testing]

[openstack-dev] [neutron] unnecessary return statement in ovs_lib

Came across the following issue while looking at ovs_lib [1]: The BaseOVS class has the add_bridge() method which after creating an OVS bridge, returns an OVSBridge object. BaseOVS class is only used by OVSBridge defined in the same file. OVSBridge has a create() method that calls the

Re: [openstack-dev] [neutron] [third-party-testing] Sharing information

Sounds good. Thanks. Mohammad From: Kyle Mestery mest...@siliconloons.com To: Mohammad Banikazemi/Watson/IBM@IBMUS, Cc: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 01/14/2014 09:31 AM Subject:Re

Re: [openstack-dev] [neutron] [third-party-testing] Sharing information

Hi everybody, I see that we already have at least two 3rd party testing setups (from Arista and Midokura) up and running. Noticed their votes on our newly submitted plugin. The etherpad which is to be used for sharing information about setting up 3rd party testing (as well as multi-node testing)

Re: [openstack-dev] [neutron] [policy] Complementary or alternative semantics?

Hi Tim, It is complementary (as an extension to the core API). Mohammad From: Tim Hinrichs thinri...@vmware.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 01/06/2014 07:35 PM Subject:[openstack-dev]

Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting

Please have a look at the agenda for tomorrow at https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy It would be great if we could at least close on the following two items tomorrow: 1. Converged model by allowing policies to have a destination group and a source

Re: [openstack-dev] [neutron] [policy] Policy-group relationship

-group relationship Hi Mohammad, Good writeup, one minor comment at the end below (look for [s3wong]). On Thu, Dec 12, 2013 at 3:42 PM, Mohammad Banikazemi m...@us.ibm.com wrote: Continuing the discussion we had earlier today during the Neutron Group Policy weekly meeting [0], I would like

[openstack-dev] [neutron] [policy] Policy-group relationship

Continuing the discussion we had earlier today during the Neutron Group Policy weekly meeting [0], I would like to initiate a couple of email threads and follow up on a couple of important issues we need to agree on so we can move forward. In this email thread, I would like to discuss the

[openstack-dev] [Neutron] Calling a controller from within a session in the plugin

Have a question regarding calling an external SDN controller in a plugin. The ML2 model brings up the fact that it is preferred not to call an external controller within a database session by splitting up each call into two calls: *_precommit and *_postcommit. Makes sense. Looking at the

[openstack-dev] [neutron] [policy] Neutron Policy IRC meeting

Hello everybody, Following up the action items from our last meeting and in preparation for our next IRC meeting on Dec 5th (see below), I have started updating the google document [1]. I have added the tables describing the attributes of new Neutron objects. I will be also working on adding a

Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings

Kyle, Thank you for organizing this. I think the original email you sent out did not solicit any comments (except for possibly proposing a different time for the weekly meetings). So that is probably why you have not heard from anybody (including me). So we are ready to have the meeting but if