+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)"
Date: 08/16/2016 05:55 PM
Subject:[opens
Did this resolve the problem? https://review.openstack.org/#/c/336549/
From: Vikas Choudhary
To: Antoni Segura Puimedon
Cc: "OpenStack Development Mailing List (not for usage questions)"
, Mohammad
Banikazemi/Watson/IBM@IBMUS, Gal Sagie ,
y 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 wrote:
For the Kuryr project, i
nto the AMQP bus,
as that would be implementation-specific - since there would be an
assumption about having a plugin that communicates with the reference impl
l2 agent.
Salvatore
[1]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/notifiers/nova.py
On 8 June 2016 at 17:23, Mohamm
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.
H
Yes, we want to use the same naming conventions when possible.
Submitted a fix here: https://review.openstack.org/#/c/315799/
Best,
Mohammad
From: Antoni Segura Puimedon
To: "OpenStack Development Mailing List (not for usage questions)"
Cc: Mohammad Banikaz
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 Development Mailing List
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
\)"
Dat
tes, Kuryr, and Neutron
- Original Message -
> From: "Mohammad Banikazemi"
> To: openstack-dev@lists.openstack.org
>
> 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
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
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
___
oni Segura Puimedon
, Vikas Choudhary
, Irena Berezovsky
, Taku Fukushima ,
Mohammad Banikazemi/Watson/IBM@IBMUS, Kyle Mestery
, Jaume Devesa
Date: 12/29/2015 01:37 AM
Subject:[Kuryr] Progress Update and Kubernetes Integratio
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, September 15, 2015 12:23 PM
> To: OpenStack Dev
"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] [nova][neutron][devstack] New proposed
> 'default' network model
>
> We run several clouds w
"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] [nova][neutron][devstack] New proposed
> 'default' network model
>
> Most projects let you s
k-dev] [Neutron][Kuryr] - Bringing Dockers
networking to Neutron
On Thu, Jul 23, 2015 at 8:10 PM, Stephen Wong
wrote:
+1 for Monday
+1 for Monday UTC. Maybe at 14 or 15h ?
On Wed, Jul 22, 2015 at 10:29 PM, Mohammad Banikazemi
wrote:
Gal, This time conflicts w
"Daneyon Hansen (danehans)" wrote on 07/23/2015
03:40:38 PM:
> From: "Daneyon Hansen (danehans)"
> To: "OpenStack Development Mailing List (not for usage questions)"
> , Mohammad Banikazemi/Watson/
> IBM@IBMUS, "Steven Dake (stdake)"
&
> $ 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
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 usi
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 Ir
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"
To: "OpenStack Development
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 t
s issues, I
> think it's a useful exercise anyway for devstack's neutron support to
> revert to a minimum viable neutron for learning purposes, and let you
> layer on complexity manually over time. And I'd be really curious if a
> n-net -> provider network
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,
overlappi
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].
-Mohammad
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
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
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 01/26/2015 10:21
It wasn't
obvious from the etherpad but that is understandable. There is so much you
can capture in an etherpad. Thanks for clarifying it promptly.
> Salvatore
>
> On 18 November 2014 19:32, Mohammad Banikazemi wrote:
> I had done some work on looking at L2 agents and identifyi
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.
I
Akihiro Motoki wrote on 09/22/2014 12:50:43 PM:
> From: Akihiro Motoki
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Date: 09/22/2014 12:53 PM
> Subject: Re: [openstack-dev] [Neutron] - what integration with
> Keystone is allowed?
>
> In Keystone, as Dolph says, a t
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
unique
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
that
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 n
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
To: "OpenStack Development Mailing List (not for usage q
Thierry Carrez wrote on 08/07/2014 06:23:56 AM:
> From: Thierry Carrez
> 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 thread is moving so fast I can't
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
Jay Pipes wrote on 08/06/2014 04:09:20 PM:
> From: Jay Pipes
> 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 wrote:
> > >I believe the refer
Yes, Here: https://review.openstack.org/#/c/111756/
From: Kevin Benton
To: "OpenStack Development Mailing List (not for usage questions)"
Cc: isaku.yamah...@gmail.com
Date: 08/04/2014 01:01 PM
Subject:Re: [openstack-dev] 答???: [Neutron] Auth token in context
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)
From:
Either date works for me. Glad to see this is not being scheduled in August :) Best,Mohammad-Sean Roberts wrote: -To: "openstack-dev@lists.openstack.org" , Kyle Mestery , "mi...@stillhq.com" From: Sean Roberts Date: 07/11/2014 03:34PMSubject: Re: [openstack-dev] [congress] mid-cycle policy
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 ag
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 exten
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:
http://www.slideshare.net/
number of specs/code being tracked this may
be helpful as long as the code owners keep the table up to date.
Best,
Mohammad
From: Irena Berezovsky
To: Mohammad Banikazemi/Watson/IBM@IBMUS,
Cc: "OpenStack Development Mailing List (not for usage questions)"
Date:
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
g
May 2014, at 15:55, Mohammad Banikazemi 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, with the possibility of having different drivers
for
> rea
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 w
List
, 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 of architecture [1].
As I understood during the last ML2 meeting
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" wrote:
>
> Armando,
>
> I think there are a couple of things that are being mixed up here, at
least as I see this co
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 t
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" wrote:
>
> Hello,
>
> Just to make sure I understand:
>
> 1.) I’m assuming that you can dilettante which p
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 the
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
interf
Kyle Mestery wrote on 05/08/2014 04:45:43 PM:
> From: Kyle Mestery
> To: "OpenStack Development Mailing List (not for usage questions)"
> ,
> Date: 05/08/2014 04:46 PM
> Subject: [openstack-dev] [neutron] Mid-Cycle Meeting Location
>
> Hi everyone:
>
> I've settled on a date, location, and age
t;
sean_colli...@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
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 ta
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
To: openstack-dev@lists.openstack.org,
Date: 05/06/2014 09:21 PM
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:
t 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 -
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 m
+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
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date: 05/06/2014 12:39 PM
Subject:Re:
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
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 discussi
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:
https://www.openstack.org/assets/presentation-media/MB-Openstack-
Isaku Yamahata wrote on 03/19/2014 04:38:34 AM:
> From: Isaku Yamahata
> To: OpenStack Development Mailing List
,
> Cc: isaku.yamah...@gmail.com
> Date: 03/19/2014 04:48 AM
> Subject: [openstack-dev] [Neutron] advanced servicevm framework:
> meeting time slot proposal 5:00UTC (Tue) and minute
[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 Development Mailing List (not
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
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].
Kanzhe, thanks for your response to my comments and questions. Please see
below.
> From: Kanzhe Jiang
>
[...]
>> On Fri, Mar 14, 2014 at 3:18 PM, Mohammad Banikazemi
wrote:
>>
[...]
>> 3- For the service chain creation, I am sure there are good reasons
>> for req
ugins.html
Thanks,
Edgar
From: Mohammad Banikazemi
Date: Monday, March 10, 2014 2:40 PM
To: OpenStack List
Cc: Edgar Magana
Subject: 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 m
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
se
Tom Fifield wrote on 03/12/2014 10:51:54 PM:
> From: Tom Fifield
> To: "OpenStack Development Mailing List (not for usage questions)"
> , Edgar Magana ,
> Date: 03/12/2014 10:59 PM
> Subject: Re: [openstack-dev] [Neutron] Docs for new plugins
>
> On 13/03/14 1
docs scripts get executed.
It looks like there is nothing to be done in this front for adding the docs
for the new plugin. If that seems reasonable, I will close the bug I had
opened for the the docs for our plugin.
Thanks,
-Mohammad
From: Edgar Magana
To: Mohammad Banikazemi/Watson
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
http://lists.openstack.org/cgi-bin/mailman/
t Naiksatam
To: Mohammad Banikazemi/Watson/IBM@IBMUS,
Cc: "OpenStack Development Mailing List (not for usage questions)"
Date: 02/17/2014 02:12 AM
Subject:Re: [openstack-dev] [neutron][policy] Using network services
with network policies
Thanks Mohamma
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 c
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 substanti
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 s
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 matters
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]
Sent: Monday, January 20,
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
your
Jay Pipes wrote on 01/17/2014 04:32:55 PM:
> From: Jay Pipes
> To: "OpenStack Development Mailing List (not for usage questions)"
> ,
> Date: 01/17/2014 04:37 PM
> Subject: Re: [openstack-dev] [neutron] [third-party-testing] Sharing
> information
>
> On Thu, 2014-01-16 at 15:37 +, Sullivan
> >>
> > >>
> > >>
> > >> On Tue, Jan 14, 2014 at 3:55 PM, Edgar Magana
> > wrote:
> > >> I like it and I am in favor.
> > >> Some of us, will be in Montreal attending the sprint tempest
session.
> > Hopefully we can all take it from
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 add_bridge
Sounds good. Thanks.
Mohammad
From: Kyle Mestery
To: Mohammad Banikazemi/Watson/IBM@IBMUS,
Cc: "OpenStack Development Mailing List (not for usage questions)"
Date: 01/14/2014 09:31 AM
Subject:Re: [openstack-dev] [neutron] [third-party-testin
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)
Hi Tim,
It is complementary (as an extension to the core API).
Mohammad
From: Tim Hinrichs
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date: 01/06/2014 07:35 PM
Subject:[openstack-dev] [neutron] [policy] Complementary or alternative
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 gro
>
> Good writeup, one minor comment at the end below (look for [s3wong]).
>
> On Thu, Dec 12, 2013 at 3:42 PM, Mohammad Banikazemi
wrote:
> > Continuing the discussion we had earlier today during the Neutron Group
> > Policy weekly meeting [0], I would like to initiate
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
policy-g
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 existin
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 fe
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 t
93 matches
Mail list logo
