trying to convince you of the value of declarative
network configuration.
On Thu, Aug 7, 2014 at 12:02 PM, Aaron Rosen aaronoro...@gmail.com wrote:
On Thu, Aug 7, 2014 at 9:54 AM, Kevin Benton blak...@gmail.com wrote:
You said you had no idea what group based policy was buying us so I tried
the
optimization to not actually sort the whole list if you just need the first
of the largest two elements.
The former is analogous to the security groups API, and the latter to the
GBP API.
On Aug 7, 2014 4:00 PM, Aaron Rosen aaronoro...@gmail.com wrote:
On Thu, Aug 7, 2014 at 12:08 PM, Kevin Benton blak
The existing constructs will not change.
On Aug 8, 2014 9:49 AM, CARVER, PAUL pc2...@att.com wrote:
Wuhongning [mailto:wuhongn...@huawei.com] wrote:
Does it make sense to move all advanced extension out of ML2, like
security
group, qos...? Then we can just talk about advanced service itself,
at 6:28 PM, Jay Pipes jaypi...@gmail.com wrote:
On 08/08/2014 08:55 AM, Kevin Benton wrote:
The existing constructs will not change.
A followup question on the above...
If GPB API is merged into Neutron, the next logical steps (from what I
can tell) will be to add drivers that handle policy
/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
constraints would result in a 403.
On Aug 8, 2014 1:04 PM, Maru Newby ma...@redhat.com wrote:
On Aug 8, 2014, at 10:56 AM, Kevin Benton blak...@gmail.com wrote:
There is an enforcement component to the group policy that allows you to
use the current APIs and it's the reason that group policy
wrote:
On 8 August 2014 10:56, Kevin Benton blak...@gmail.com wrote:
There is an enforcement component to the group policy that allows you to
use the current APIs and it's the reason that group policy is integrated
into the neutron project. If someone uses the current APIs, the group
policy
, and eth2 connected
to the storage network (or some other permutation.)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
to the
Development policies doc.
Mark.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing
I'm not sure what the guideline is, but I would like to point out a good
reason to have the bug report even for obvious fixes.
When users encounters bugs, they go to launchpad to report them. They don't
first scan the commits of the master branch to see what was fixed. Having
the bug in launchpad
Is the pylint static analysis that caught that error prone to false
positives? If not, I agree that it would be really nice if that were made
part of the tox check so these don't have to be fixed after the fact.
To me that particular patch seems like one that should be accompanied with
a unit
?
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
Although just swapping the times defeats the whole purpose for people that
attend both meetings. :-)
On Wed, Aug 13, 2014 at 1:02 PM, Collins, Sean
sean_colli...@cable.comcast.com wrote:
On Wed, Aug 13, 2014 at 03:28:34PM EDT, Kevin Benton wrote:
Maybe the ipv6 subteam meeting could
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi
correct any dependencies on the
RouterInterface. I understand the error I’m getting, but I’m not sure if
I’m doing something wrong or if it’s a bug.
*From:* Kevin Benton [mailto:blak...@gmail.com]
*Sent:* Wednesday, August 13, 2014 10:44 PM
*To:* OpenStack Development Mailing List
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
. This
allows vendor control over most of their bits, removes the constant
churn for simple bug fixes in the neutron tree, and adds the benefit
of being a part of the simultaneous release, which is the only thing
most vendors care about.
On Thu, Aug 14, 2014 at 10:34 PM, Kevin Benton blak
@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to vote, can you clarify?
Edgar
From: Kevin Benton blak...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: Tuesday, August 19, 2014 at 1:11 PM
To: OpenStack Development Mailing List (not for usage questions
list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
? As we are expecting
to orchestrate hundreds of NFV with all similar network configuration,
programmability is another key element.
On Thu, Aug 21, 2014 at 3:52 PM, Kevin Benton blak...@gmail.com wrote:
Have you tried making the external network shared as well? Instances that
need a private IP
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
for
example the appropriate vlan id (what if external network does not use
vlan?) and then to the external network without doing the NATing. Would
this traffic go through the veth pair connecting the br-int and br-ex?
Mohammad
[image: Inactive hide details for Kevin Benton ---08/23/2014 01:37:28
/meetings/networking/2014/networking.2014-07-14-21.02.html
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
, Kevin Benton blak...@gmail.com wrote:
I think this will depend on the deployment type for the L3 agent. If the
gateway_external_network_id is left blank for the L3 agent, the external
network is vlan tagged just like any regular network and doesn't have an
independent bridge.[1] In that deployment
@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, Kevin Benton blak...@gmail.com wrote:
No, the gateway_external_network_id option just refers to how your
network is deployed. If the external network uses a regular segmentation
identifier like the rest of the networks, this will work. If not, it won't
because the instances will try to use
From what I understand, the intended projects for the incubator can't
operate without neutron because they are just extensions/plugins/drivers.
For example, if the DVR modifications to the reference reference L3 plugin
weren't already being developed in the tree, DVR could have been developed
in
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi
/neutron/plugins/ml2/drivers/mech_agent.py#L53
2.
https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8/neutron/plugins/ml2/drivers/mechanism_odl.py#L326
On Tue, Aug 26, 2014 at 10:05 PM, loy wolfe loywo...@gmail.com wrote:
On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton
, Kevin Benton blak...@gmail.com wrote:
Ports are bound in order of configured drivers so as long as the
OpenVswitch driver is put first in the list, it will bind the ports it can
and then ODL would bind the leftovers. [1][2] The only missing component is
that ODL doesn't look like it uses l2pop
be a perfect
place for this type of work.
1. https://wiki.openstack.org/wiki/Neutron/DVR/HowTo
On Wed, Aug 27, 2014 at 1:22 AM, loy wolfe loywo...@gmail.com wrote:
On Wed, Aug 27, 2014 at 2:44 PM, Kevin Benton blak...@gmail.com wrote:
Incubator doesn't mean being kicked out of tree, it just mean
/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
idea sounds interesting for the one-time big
experimental changes. Are there any other projects that do this right now?
On Wed, Aug 27, 2014 at 12:30 PM, James E. Blair cor...@inaugust.com
wrote:
Kevin Benton blak...@gmail.com writes:
From what I understand, the intended projects
at 10:30 AM, Kevin Benton blak...@gmail.com wrote:
So why not agent based?
Maybe I have an experimental operating system that can't run python.
Maybe
the RPC channel between compute nodes and Neutron doesn't satisfy certain
security criteria. Regardless of the reason, it doesn't matter
feedback and tracking
comments. Or should I just commit it to the juno folder?
Thanks,
Andreas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
referring to its internal API modifications, its referring to how the L3
service plugin will integrate with the data plane.
On Thu, Aug 28, 2014 at 7:45 AM, Jay Pipes jaypi...@gmail.com wrote:
On 08/27/2014 04:28 PM, Kevin Benton wrote:
What are you talking about? The only reply was from me
...@yuggoth.org wrote:
On 2014-08-28 08:31:26 -0700 (-0700), Kevin Benton wrote:
[...]
DVR completely changed the reference L3 service plugin, which
lives in the main tree.
A well-defined, versioned internal API would not have helped any
of the issues I brought up.
[...]
Except, perhaps
be looked favorable on when time is to move it into incubated
status.
Susanne
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I see. Then if a group's ultimate goal is their own project, would the
Neutron incubator even make sense as a first step?
On Thu, Aug 28, 2014 at 6:48 PM, Kyle Mestery mest...@mestery.com wrote:
On Thu, Aug 28, 2014 at 5:55 PM, Kevin Benton blak...@gmail.com wrote:
I think we need some
I think the point is that if there were discussions that lead to
uncertainty about the split, they should have resulted in a - 1/-2 on the
spec instead of letting it sit there.
On Aug 29, 2014 9:46 AM, Jay Pipes jaypi...@gmail.com wrote:
On 08/29/2014 12:25 PM, Zane Bitter wrote:
On 28/08/14
Is it possible to put an iCal on the wiki so we can automatically see when
meetings are updated/cancelled/moved?
On Sep 1, 2014 6:23 PM, Kyle Mestery mest...@mestery.com wrote:
Per discussion again today in the Neutron meeting, next week we'll
start rotating the meeting. This will mean next
-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
/Meetings for a link to an iCal
feed of all OpenStack meetings.
https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics
On Mon, Sep 1, 2014 at 8:26 PM, Kevin Benton blak...@gmail.com wrote:
Is it possible to put an iCal on the wiki so we
for when
things go wrong? Getting reviews is already hard enough, let alone when
there is a -1 in the 'verified' column.
1. https://review.openstack.org/#/c/116187/
2.
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin
--
Kevin Benton
to the reviews?
Thanks,
Kevin Benton
On Mon, Sep 1, 2014 at 8:08 PM, YAMAMOTO Takashi yamam...@valinux.co.jp
wrote:
I have had multiple occasions where the OpenDaylight CI will vote a -1
on a
patch for something completely unrelated (e.g. [1]). This would be fine
except for two issues. First
for horizon.
Else for the limitation of resource, we have to sort by the priority,
then should we focus on APIs being baked in the incubator first?
--
*From:* Kevin Benton [blak...@gmail.com]
*Sent:* Tuesday, September 02, 2014 9:55 AM
*To:* OpenStack Development
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
that they will be moving around...
-Sukhdev
On Mon, Sep 1, 2014 at 6:58 PM, Kevin Benton blak...@gmail.com wrote:
Unfortunately the master ICAL has so many meetings that it's not useful
to have displaying as part of a normal calendar.
I was hoping for a Neutron-specific one similar to Tripleo's.
On Mon, Sep 1
to the Neutron incubator
can be evaluated once it actually becomes something more than a wiki page.
1.
http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html
--
Kevin Benton
On Thu, Sep 4, 2014 at 11:24 PM, Mandeep Dhami dh...@noironetworks.com
wrote:
I agree. Also
://bugs.launchpad.net/neutron/+bug/1255142
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
:41 AM, Kevin Benton blak...@gmail.com wrote:
https://review.openstack.org/#/c/83664/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Giuseppe Cossu
CREATE-NET
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
Being in the incubator won't help with this if it's a different repo as
well.
On Wed, Sep 10, 2014 at 7:22 AM, Robert Kukura kuk...@noironetworks.com
wrote:
On 9/9/14, 7:51 PM, Jay Pipes wrote:
On 09/09/2014 06:57 PM, Kevin Benton wrote:
Hi Jay,
The main component that won't work without
\ 35756
BR,
Germy
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
/14, 6:54 PM, Kevin Benton wrote:
Being in the incubator won't help with this if it's a different repo as
well.
Agreed.
Given the requirement for GBP to intercept API requests, the potential
couplings between policy drivers, ML2 mechanism drivers, and even service
plugins (L3 router
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
to learn, it will help with developing new features
by reducing reviewer load.
On Fri, Sep 12, 2014 at 1:50 AM, Germy Lure germy.l...@gmail.com wrote:
On Fri, Sep 12, 2014 at 11:11 AM, Kevin Benton blak...@gmail.com wrote:
Maybe I missed something, but what's the solution?
There isn't one yet
):
return self.engine
1. https://review.openstack.org/#/c/110016/
--
Kevin Benton
On Fri, Sep 12, 2014 at 2:15 AM, Anna Kamyshnikova
akamyshnik...@mirantis.com wrote:
This is implementing ModelsMigrationsSync test from oslo [1]. For running
it locally on Postgres you have to do the following
I saw that the specs that didn't make the deadline for the feature freeze
were removed from the tree completely.[1] For easier reference, can we
instead revert that commit to restore them and then move them into a
release specific folder called 'unimplemented' or something along those
lines?
It
restrict the whole repo to being documentation of what went in?
If that's all the specs are for, why don't we just wait to create them
until after the code merges?
On Sep 15, 2014 6:16 AM, Kyle Mestery mest...@mestery.com wrote:
On Mon, Sep 15, 2014 at 4:52 AM, Kevin Benton blak...@gmail.com wrote:
I
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
this way , but
atleast we
saw Openvswitch implementations did. So we consciously did not promote
VLANs for
initial phase of DVR.
--
Thanks,
Vivek
From: Kevin Benton [mailto:blak...@gmail.com]
Sent: Thursday, September 18, 2014 3:01 AM
To: OpenStack Development Mailing List
-Original Message-
From: Kevin Benton [mailto:blak...@gmail.com]
Sent: Thursday, September 18, 2014 12:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] DVR Tunnel Design Question
This sounds like a bug in Openvswitch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
Sorry, forgot to include a link.
https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api
On Fri, Sep 19, 2014 at 4:45 PM, Kevin Benton blak...@gmail.com wrote:
Well there is the QoS work that has been pushed to incubation or Kilo.
On Fri, Sep 19, 2014 at 1:40 PM, Carlino, Chuck
)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
://review.openstack.org/#/c/122382
2. https://review.openstack.org/#/c/118456
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack
conversation if anyone is interested).
Store IDs where necessary, and use IDs on the wire where possible though,
as they are immutable.
On Sat, Sep 20, 2014 at 7:46 PM, Kevin Benton blak...@gmail.com wrote:
Hello all,
A patch has come up to query keystone for tenant names in the IBM
plugin.[1
not as a unique identifier but in addition to the
unique identifier which is the project ID. For all practical purposes, we
can set the project name for all projects to Kevin Benton and nothing will
change functionally.
This should be obvious from the code and how the project id
mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
Neutron security groups were broken with ML2 in icehouse.
Fixed in these two patches on the date range you noticed the change:
https://review.openstack.org/#/c/83280/
https://review.openstack.org/#/c/83190/
--
Kevin Benton
On Wed, Apr 2, 2014 at 11:34 PM, Eugene Nikanorov
enikano
of the use cases, but it is a breaking change
due to the loss of generality.
--
Kevin Benton
On Mon, Apr 7, 2014 at 5:28 PM, Zane Bitter zbit...@redhat.com wrote:
The Neutron API is a constant cause of pain for us as Heat developers, but
afaik we've never attempted to bring up the issues we have found
manner that exclude a ton of possibilities, we shouldn't have to worry
about rainbow tables.
--
Kevin Benton
On Fri, Jun 13, 2014 at 12:52 AM, Robert Collins robe...@robertcollins.net
wrote:
On 12 June 2014 23:59, Sean Dague s...@dague.net wrote:
The only thing it makes harder is you have
ML2
driver with just ML2 installed because the Big Switch plugin directory is
gone.
Is there somewhere where we can put common third party code that will be
safe from removal during packaging?
Thanks
--
Kevin Benton
___
OpenStack-dev mailing list
be a high priority and I suspect
other packagers could end up doing the same thing.
That's why I was looking for an alternative approach.
--
Kevin Benton
On Mon, Jun 16, 2014 at 3:37 PM, Ihar Hrachyshka ihrac...@redhat.com
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 17/06/14 00
This approach would work but my only concern is then getting an external
package added as a dependency to Neutron.
Or would you just forgo that entirely and mock out all of the library calls?
--
Kevin Benton
On Mon, Jun 16, 2014 at 3:29 PM, Salvatore Orlando sorla...@nicira.com
wrote:
I think
That could be a possible workaround.
In this particular deployment the nodes no longer had access to the
Internet though to install additional packages.
--
Kevin Benton
On Mon, Jun 16, 2014 at 3:59 PM, Armando M. arma...@gmail.com wrote:
I believe the Brocade's mech driver might have the same
Hi Ihar,
What is the reason to breakup neutron into so many packages? A quick disk
usage stat shows the plugins directory is currently 3.4M.
Is that considered to be too much space for a package, or was it for
another reason?
Thanks,
Kevin Benton
On Mon, Jun 16, 2014 at 3:37 PM, Ihar
This sounds like a good idea to handle some of the performance issues until
the ovs firewall can be implemented down the the line.
Do you have any performance comparisons?
On Jun 18, 2014 7:46 PM, shihanzhang ayshihanzh...@126.com wrote:
Hello all,
Now in neutron, it use iptable implementing
as the 'with' statement for the transaction so it will be
closed at that point.
Cheers,
Kevin Benton
--
Kevin Benton
On Tue, Jun 24, 2014 at 8:33 PM, Li Ma skywalker.n...@gmail.com wrote:
Hi all,
I'm developing a new mechanism driver. I'd like to access ml2-related
tables in create_port_precommit
demonstrating what you are trying to do.
--
Kevin Benton
On Wed, Jun 25, 2014 at 3:21 AM, Li Ma skywalker.n...@gmail.com wrote:
Hi Kevin,
Thanks for your reply. Actually, it is not that straightforward.
Even if postcommit is outside the 'with' statement, the transaction is not
'truly' committed
and
writing ml2-related tables) in postcommit, db lock wait exception is still
thrown.
Li Ma
- Original Message -
From: Kevin Benton blak...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: 星期三, 2014年 6 月 25日 下午 4:59
- Original Message -
From: Kevin Benton blak...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: 星期四, 2014年 6 月 26日 上午 10:32:47
Subject: Re: [openstack-dev] [Neutron ML2] Potential DB lock when
developing new mechanism driver
would be acceptable to the community?
1.
http://eavesdrop.openstack.org/meetings/third_party/2014/third_party.2014-06-30-18.01.html
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
this to the mailing list
to get feedback.
1. https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
Cheers
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
it
will just test the patch without merging it.
Where is this merging process handled in the OpenStack CI? Is that done in
Zuul with the custom Zuul branch is passed to devstack?
--
Kevin Benton
On Tue, Jul 1, 2014 at 4:00 PM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2014-07-01 10:05:45 -0700 (-0700
-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Maybe we can require period checks against the head of the master
branch (which should always pass) and build statistics based on the results
of that. Otherwise it seems like we have to take a CI system's word for it
that a particular patch indeed broke that system.
--
Kevin Benton
On Thu, Jul
Are these zuul refs publicly accessible so that the third party CI systems
could reference then to guarantee they are testing the same thing?
On Thu, Jul 3, 2014 at 11:31 AM, Jay Pipes jaypi...@gmail.com wrote:
On 07/03/2014 02:10 PM, Kevin Benton wrote:
The reason I thought it changed
1 - 100 of 830 matches
Mail list logo
