/134179/ (l2 gw aas)
On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando sorla...@nicira.com
wrote:
Thanks Maruti,
I have some comments and questions which I've posted on gerrit.
There are two things I would like to discuss on the mailing list
concerning
this effort.
1) Is this spec
No worries,
you get one day off over the weekend. And you also get to choose if it's
saturday or sunday.
Salvatore
On 13 November 2014 20:05, Kevin Benton blak...@gmail.com wrote:
December 8-19? 11 day mid-cycle seems a little intense...
On Thu, Nov 13, 2014 at 11:01 AM, Kyle Mestery
There are a lot of neutron patches which, for different reasons, have not
been updated in a while.
In order to ensure reviewers focus on active patch, I have set a few
patches (about 75) as 'abandoned'.
No patch with an update in the past month, either patchset or review, has
been abandoned.
Hi Jaume,
The concept of provider router is useful as it maps what actually already
happens in several infrastructures. I am not entirely sure that this
however implies we need to expose new API constructs and change the
topology API.
The provider router perhaps can exist in a concealed way,
On 12 November 2014 09:53, marios mar...@redhat.com wrote:
On 12/11/14 11:18, Anita Kuno wrote:
On 11/12/2014 08:04 AM, marios wrote:
On 12/11/14 04:17, Clint Byrum wrote:
Just as a counter-point: The entire reason that a mid-cycle is an
important thing to do is to achieve higher
approach.
BR,
Germy
On Wed, Nov 5, 2014 at 3:36 PM, Salvatore Orlando sorla...@nicira.com
wrote:
From what I gather from this thread and related bug report, the change
introduced in the OVS agent is causing a data plane outage upon agent
restart, which is not desirable in most cases
From what I gather from this thread and related bug report, the change
introduced in the OVS agent is causing a data plane outage upon agent
restart, which is not desirable in most cases.
The rationale for the change that introduced this bug was, I believe,
cleaning up stale flows on the OVS
Keshava,
I think the thread is not going a bit off its stated topic - which is to
discuss the various proposed approaches to vlan trunking.
Regarding your last post, I'm not sure I saw either spec implying that at
the data plane level every instance attached to a trunk will be implemented
as a
Just like Kevin I was considering using conntrack zones to segregate
connections.
However, I don't know whether this would be feasible as I've never used
iptables CT target in real applications.
Segregation should probably happen at the security group level - or even at
the rule level - rather
at 2:25 AM, Salvatore Orlando
sorla...@nicira.com
wrote:
Just like Kevin I was considering using conntrack zones to segregate
connections.
However, I don't know whether this would be feasible as I've never
used
iptables CT target in real applications.
Segregation
Hi Miguel,
while we'd need to hear from the stable team, I think it's not such a bad
idea to make this tool available to users of pre-juno openstack releases.
As far as upstream repos are concerned, I don't know if this tool violates
the criteria for stable branches. Even if it would be a rather
Kyle,
I pointed out the similarity of the two specifications while reviewing them
a few months ago (see patch set #4).
Ian then approached me on IRC (I'm afraid it's going to be a bit difficult
to retrieve those logs), and pointed out that actually the two
specifications, in his opinion, try to
On 20 October 2014 15:38, Jay Pipes jaypi...@gmail.com wrote:
On 10/20/2014 10:26 AM, Amit Gandhi wrote:
Thanks for the clarification Sam.
Its good to know where the mission of the API working group starts and
stops. During the meetup discussions, my understanding was that the
working
In an analysis we recently did for managing lifecycle of neutron resources,
it also emerged that task (or operation) API are a very useful resource.
Indeed several neutron resources introduced the (in)famous PENDING_XXX
operational statuses to note the fact that an operation is in progress and
its
I think you did everything right.
Are you sure cirros images by default are configured to boostrap interfaces
different from eth0?
Perhaps all you need to do is just ifup the interface... have you already
tried that?
Salvatore
On 15 October 2014 23:07, Danny Choi (dannchoi) dannc...@cisco.com
://etherpad.openstack.org/p/kilo-oslo-summit-topics
Doug
On Wed, Oct 8, 2014 at 2:29 AM, Salvatore Orlando sorla...@nicira.com
wrote:
On 8 October 2014 04:13, Joe Gordon joe.gord...@gmail.com wrote:
On Fri, Oct 3, 2014 at 10:47 AM, Morgan Fainberg
morgan.fainb...@gmail.com wrote
The blueprint was untargeted mostly because the analysis indicated that
there was no easy solution, and that what we needed was a solution to do
some RBAC on neutron resources.
I think this would be a good addition to the Neutron resource model, and it
would be great if you could start the
it seems not a lot of projects use it:
$ find . -name openstack-common.conf | xargs grep quota
$
Salvatore
On 15 October 2014 00:34, Doug Hellmann d...@doughellmann.com wrote:
On Oct 14, 2014, at 12:31 PM, Salvatore Orlando sorla...@nicira.com
wrote:
Hi Doug,
do you know if the existing quota
If the ARP request reaches the compute node, then you do already know
tunnelling (or whatever transport type you're using) is not your problem.
The security group is also configured properly, so it does not seem
something you need to worry about.
This leaves us with two possible problems:
1) did
Comments inline.
Salvatore
On 10 October 2014 11:02, Wuhongning wuhongn...@huawei.com wrote:
Hi,
In the Juno cycle there is proposal of ModularL2Agent [1,2], which is
very useful to develop agent for new backend with much less redundant code.
Without that, we have to either fork a new
On Friday, October 3, 2014, Salvatore Orlando sorla...@nicira.com
wrote:
Thanks Vish,
this seems a very reasonable first step as well - and since most
projects would be enforcing quotas in the same way, the shared library
would be the logical next step.
After all this is quite the same
I am totally not against it.
I agree with you that probably the restriction on core-only might be
lifted, but that decision lies with the oslo team.
Salvatore
On 7 October 2014 13:55, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/10/14
Some (hopefully) helpful answer inline.
Salvatore
On 6 October 2014 22:45, Mike Spreitzer mspre...@us.ibm.com wrote:
Is it possible to use DevStack to install OpenStack, including Neutron, so
that OpenStack can make a VM that can communicate with the world beyond
OpenStack? I am looking
Hi,
Quota management is currently one of those things where every openstack
project does its own thing. While quotas are obviously managed in a similar
way for each project, there are subtle differences which ultimately result
in lack of usability.
I recall that in the past there have been
of
reconciling actual usage against quota usage periodically, to detect
problems.
On 3 October 2014 15:03, Salvatore Orlando sorla...@nicira.com wrote:
Hi,
Quota management is currently one of those things where every openstack
project does its own thing. While quotas are obviously managed
On 30 September 2014 10:26, Linchengyong linchengy...@huawei.com wrote:
Dear all,
Could anyone help me? I have some questions to trouble .
1. Can the neutron create complex virtual network topology? Such as,
any two routers' interconnection between each other.
Only if you bridge
I reckon it is a sort of convenience route which allows us to connect
directly to private instances running in the network namespace from the
devstack host without having to use floating ips.
It is something which probably makes sense for dev scenarios only as
FIXED_RANGE is generally not
Relying again on automatic schema generation could be error-prone. It can
only be enabled globally, and does not work when models are altered if the
table for the model being altered already exists in the DB schema.
I don't think it would be a big problem to put these migrations in the main
Please keep me in the loop.
The importance of ensuring consistent style across Openstack APIs increases
as the number of integrated project increases.
Unless we decide to merge all API endpoints as proposed in another thread!
[1]
Regards,
Salvatore
[1]
Bug 1357055 [1] and 1323658 [2] affect neutron jobs and are among the top
gate offenders.
With this kind of bugs, it's hard to tell whether the root cause lies with
neutron, nova, tempest, or even cirros.
However, it is not ok that these bugs are not assigned in neutron. We need
to have some
Nested commits in sqlalchemy should be seen as a single transaction on the
backend, shouldn't they?
I don't know anything about this specific problem, but the fact that unit
tests use sqlite might be a reason, since it's not really a full DBMS...
I think that wrapping tests in transaction also
The HDN plugin is purely for educational purposes.
I remember it worked with devstack, but as I've not run it for a while it
might be broken now.
If you've found this plugin you should also have found the slides which
introduced it.
First you should assess whether you need to implement a new
This is a very important discussion - very closely related to the one going
on in this other thread
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045768.html
.
Unfortunately it is also a discussion that tends to easily fragment and
move in a thousand different directions.
A few
While it's good that somebody is addressing this specific issue, perhaps
punctual solutions - eg: hey I have a patch for that, are not
addressing the general issues, which is that Neutron has very granular
primitives that force users to do multiple API requests for operations they
regard as
On 3 September 2014 22:10, Joe Gordon joe.gord...@gmail.com wrote:
On Tue, Aug 26, 2014 at 4:47 PM, Salvatore Orlando sorla...@nicira.com
wrote:
TL; DR
A few folks are proposing to stop running tests for neutron advanced
services [ie: (lb|vpn|fw)aas] in the integrated gate, and run them
Some more comments from me inline.
Salvatore
On 2 September 2014 11:06, Adam Harwell adam.harw...@rackspace.com wrote:
I also agree with most of what Brandon said, though I am slightly
concerned by the talk of merging Octavia and [Neutron-]LBaaS-v2 codebases.
Beyond all the reasons listed
Octavia will
sit.
Nevertheless I think this is a discussion that it's useful for the
medium/long term - it does not seem to me that there is an urgency here.
Regards Susanne
On Tue, Sep 2, 2014 at 9:18 AM, Salvatore Orlando sorla...@nicira.com
wrote:
Some more comments from me inline
If you are running version from a stable branch, changes in DB migrations
should generally be forbidden as the policy states since those migrations
are not likely to be executed again. Downgrading and then upgrading again
is extremely risky and I don't think anybody would ever do that.
However,
I agree with Brandon that it will be difficult to find spaces for Octavia,
and the pod is a valid option.
Nevertheless it is always worth trying.
For the traditional load balancing service instead I reckon #1 is a very
good thing to discuss. Problem is that it is also hard to conclude anything
in
I think it's ok to submit specs for Kilo - mostly because it would be a bit
pointless submitting them for Juno!
Salvatore
On 28 August 2014 09:26, Kevin Benton blak...@gmail.com wrote:
You could just make the kilo folder in your commit and then rebase it once
Kilo is open.
On Thu, Aug 28,
Hi,
it would be good if you can confirm whether this behaviour affects icehouse
or trunk as well.
Several bugs concerning nova/neutron communication as well as ovs agent
handling of ports have been fixed during the last two release cycle.
While the stable team did a great job in back-porting
As it has been pointed out previously in this thread debugging gate
failures is mostly about chasing race conditions, which in some cases
involve the most disparate interactions between Openstack services [1].
Finding the root cause of these races is a mix of knowledge, pragmatism,
and luck.
Hi Nader,
Sorry about that failure.
We have temporarily stopped mine sweeper for neutron while we update our
devstack images.
However, unfortunately some jobs did not complete properly, and therefore
you had failures without logs being reported.
The situation should be back to normal soon, and
Hi Kyle,
I have conflicts for 13 UTC - Thursday is already full for me, but I'll try
anyway, to join the convo on IRC.
I agree the 3 blueprints you've mentioned are the ones we should really
merge for Juno.
To this aim, I wonder why [1] has not been set to high. Nevertheless it
does not matter a
Hi Karthik,
what do you mean that the plugin is incompatible with
https://review.openstack.org/#/c/114393/?
you're mentioning a rebase issue - but the patch in question appears to
cleanly apply to master.
Is your probably because patch #114393 does not have in its log some
changes you need to
TL; DR
A few folks are proposing to stop running tests for neutron advanced
services [ie: (lb|vpn|fw)aas] in the integrated gate, and run them only on
the neutron gate.
Reason: projects like nova are 100% orthogonal to neutron advanced
services. Also, there have been episodes in the past of
by
the service plugin should be exposed at the management plane, implemented
at the control plane, and if necessary also at the data plane.
Some more comments inline.
Salvatore
On 20 August 2014 11:31, Mathieu Rohon mathieu.ro...@gmail.com wrote:
Hi
On Wed, Aug 20, 2014 at 12:12 AM, Salvatore
Some comments inline.
Salvatore
On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all,
I've read the proposal for incubator as described at [1], and I have
several comments/concerns/suggestions to this.
Overall, the
Hi Joe,
manual rechecks are possible for mine sweeper. The new syntax is
vmware-recheck-patch. I found out vmware-recheck still triggered upstream
zuul.
I think it should be possible to submit a batch job with all the patches
that need to be rechecked without having to trigger the recheck from
In the current approach QoS support is being hardwired into ML2.
Maybe this is not the best way of doing that, as perhaps it will end up
requiring every mech driver which enforces VIF configuration should support
it.
I see two routes. One is a mechanism driver similar to l2-pop, and then you
As the conversation has drifted away from a discussion pertaining the nova
core team, I have some comments inline as well.
On 18 August 2014 12:18, Thierry Carrez thie...@openstack.org wrote:
Doug Hellmann wrote:
On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote:
Let me
://bugs.launchpad.net/nova/+bug/1305892
On 16 August 2014 01:13, Mark McClain mmccl...@yahoo-inc.com wrote:
On Aug 15, 2014, at 6:20 PM, Salvatore Orlando sorla...@nicira.com
wrote:
The neutron full job is finally voting, and the first patch [1] has
already passed it in gate checks!
I've collected
Hi Trevor,
thanks for sharing this minutes!
I would like to cooperate a bit to this project's developments, possibly
without ending up being just deadweight.
To this aim I have some comments inline.
Salvatore
On 18 August 2014 22:25, Trevor Vardeman trevor.varde...@rackspace.com
wrote:
Hi Stuart,
As far as I can tell, this is the first time I hear about this problem.
I can't make any judgment with the details you've shared here, but I would
initially focus on ovs, the kernel and their interactions.
For Neutron's l3 agent the only thing I can say is that it uses the
conntrack
August 2014 20:14, Salvatore Orlando sorla...@nicira.com wrote:
And just when the patch was only missing a +A, another bug slipped in!
The nova patch to fix it is available at [1]
And while we're there, it won't be a bad idea to also push the neutron
full job, as non-voting, into the integrated
VMware minesweeper has filters which have been designed to cover the
largest possible subset of submissions without add unnecessary load to our
scarce resources for CI validation. This is probably why the analysis
reveals not all patches are covered.
Therefore our filters exclude neutral changes
I think there will soon be a discussion regarding what the appropriate
location for plugin and drivers should be.
My personal feeling is that Neutron has simply reached the tipping point
where the high number of drivers and plugins is causing unnecessary load
for the core team and frustration for
? Ideas? Criticisms? Complements? J
Steven
Original message
From: Salvatore Orlando sorla...@nicira.com
Date: 11/14/2013 4:23 AM (GMT-07:00)
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev
cores who'll review these patches!)
Salvatore
[1] https://review.openstack.org/#/c/113554/
[2] https://review.openstack.org/#/c/113562/
On 7 August 2014 17:51, Salvatore Orlando sorla...@nicira.com wrote:
Thanks Armando,
The fix for the bug you pointed out was the reason of the failure we've
Hi,
VMware minesweeper caused havoc today causing exhaustion of the upstream
node pool.
The account has been disabled so things are back to normal now.
The root cause of the issue was super easy once we realized we missed [1].
I would like to apologise to the whole community on behalf of the
-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][CI] VMware mine sweeper for
Neutron temporarily disabled
On Jul 29, 2014 12:46 PM, Salvatore Orlando sorla...@nicira.com wrote:
Minesweeper for Neutron is now running again.
We updated the image for our compute nodes
It might be because of the wording used, but it seems to me that you're
making it sound like the group policy effort could have been completely
orthogonal to neutron as we know it now.
What I understood is that the declarative abstraction offered by group
policy could do without any existing
If we want to keep everything the way it is, we have to change everything
[1]
This is pretty much how I felt after reading this proposal, and I felt that
this quote, which Ivar will probably appreciate, was apt to the situation.
Recent events have spurred a discussion about the need for a change
yYW1lIjoiMTcyODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQwNzQwMDExMDIwNywibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ==
On 23 July 2014 14:59, Matthew Treinish mtrein...@kortar.org wrote:
On Wed, Jul 23, 2014 at 02:40:02PM +0200, Salvatore Orlando wrote:
Here I am again bothering you
/#/c/98441/
On 7 August 2014 10:34, Salvatore Orlando sorla...@nicira.com wrote:
I had to put the patch back on WIP because yesterday a bug causing a 100%
failure rate slipped in.
It should be an easy fix, and I'm already working on it.
Situations like this, exemplified by [1] are a bit
As Ronak said, this thread is starting to move in a lot of different
directions, ranging from correctness of the blueprint approval process to
nova/neutron integration, which are rather off topic.
In particular it seems things are being skewed towards a discussion around
nova parity, whereas
As long as the discussion stays focused on how group policies are
beneficial for the user community and how the Neutron developer community
should move forward, I reckon it's fine to keep the discussion in this
thread.
Salvatore
Il 06/ago/2014 21:18 Aaron Rosen aaronoro...@gmail.com ha scritto:
I was asked beforehand what I mean with
* consider GBP an 'experimental' V3 tenant API (this was mentioned
somewhere in this thread) and treat it accordingly
The group based policies, although implemented as a service plugin, are
quite different from the ones we have now. Things like firewall,
Congratulations!
And to celebrate this milestone, I would consider running something more
than ~280 api tests... perhaps also a few scenario tests?
Salvatore
On 7 August 2014 01:09, Sukhdev Kapur sukhdevka...@gmail.com wrote:
Folks,
Just wanted to share with you that Arista CI has been up
Hi Luke,
Once in place, the CI system should be able to pick up the patches from the
new plugin or driver on gerrit.
In my opinion, successful CI runs against those patches should constitute a
sufficient proof of the validity of the CI system.
Salvatore
Il 05/ago/2014 09:57 Luke Gorrie
Hi Henry,
Are the fixes pushed with patches [1], and [2], which amend tox.ini,
insufficient?
Salvatore
[1] https://review.openstack.org/#/c/109888/
[2] https://review.openstack.org/#/c/109729/
On 4 August 2014 20:42, Henry Gessau ges...@cisco.com wrote:
Please see this bug:
won't vote when they're hit.
Regards,
Salvatore
[1]
https://github.com/openstack/nova/commit/842b2abfe76dede55b3b61ebaad5a90c356c5ace
On 28 July 2014 13:07, Salvatore Orlando sorla...@nicira.com wrote:
Hi,
We have been witnessing some issues in our infrastructure which resulted
in Mine
For what is worth, I'm trying below to provide my perspective on Luke's
question both as a reviewer and as developer.
Salvatore
On 26 July 2014 20:02, Luke Gorrie l...@snabb.co wrote:
On 25 July 2014 20:05, Stefano Maffulli stef...@openstack.org wrote:
Indeed, communication is key. I'm not
Hi,
We have been witnessing some issues in our infrastructure which resulted in
Mine Sweeper test run failures. Unfortunately these failures resulted in
-1s being put on several patches.
Mine sweeper is now temporarily disabled and our team is already working on
solving the issue.
In the
I'm sure it is not news to anyone that we already have approved a too many
specifications for Juno-3. The PTL made clear indeed that Low priority
blueprints are considered best effort.
However, this already leaves us with 23 medium to high specifications to
merge in Juno-3. This is already quite
can confirm a failure rate below 15% with more data points.
Salvatore
[1] https://review.openstack.org/#/c/103865/
[2] https://review.openstack.org/#/c/88289/
On 10 July 2014 11:49, Salvatore Orlando sorla...@nicira.com wrote:
On 10 July 2014 11:27, Ihar Hrachyshka ihrac...@redhat.com
Kyle,
It is probably my fault that I did not notice the review assignment page
beforehand.
Thankfully, I'm already engaged in reviewing the db 'healing' work. On the
other hand, I've barely followed Oleg's progress on the migration work.
I'm ok to assist Maru there, even if I'm surely less
I think I've provided some examples in the review.
However, the point is mostly to simplify usage from a user perspective -
allowing consumers of the neutron API to use the same flavour object for
multiple services.
There are other considerations which could be made, but since they're
dependent
1bnQiLCJ0aW1lIjp7ImZyb20iOiIyMDE0LTA3LTAxVDA4OjU5OjAxKzAwOjAwIiwidG8iOiIyMDE0LTA3LTEwVDA4OjU5OjAxKzAwOjAwIiwidXNlcl9pbnRlcnZhbCI6IjAifSwic3RhbXAiOjE0MDQ5ODI3OTc3ODAsIm1vZGUiOiIiLCJhbmFseXplX2ZpZWxkIjoiIn0=
[4] https://bugs.launchpad.net/nova/+bug/1333654
On 2 July 2014 17:57, Salvatore Orlando sorla...@nicira.com wrote:
Hi again,
From my analysis most of the failures
On 10 July 2014 11:27, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/07/14 11:07, Salvatore Orlando wrote:
The patch for bug 1329564 [1] merged about 11 hours ago. From [2]
it seems there has been an improvement on the failure rate, which
I would just add that if I'm not mistaken the DVR work would also include
the features currently offered by nova network's 'multi-host' capability.
While DVR clearly does a lot more than multi host, keeping SNAT centralized
only might not fully satisfy this requirement.
Indeed nova-network offers
Apologies for quoting again the top post of the thread.
Comments inline (mostly thinking aloud)
Salvatore
On 30 June 2014 22:22, Jay Pipes jaypi...@gmail.com wrote:
Hi Stackers,
Some recent ML threads [1] and a hot IRC meeting today [2] brought up some
legitimate questions around how a
Hi,
As you surely now, in Juno oslo.db will graduate [1]
I am currently working on the port. It's been already cleared that making
alembic migrations idempotent and healing the DB schema is a requirement
for this task.
These two activities are tracked by the blueprints [2] and [3].
I think we've
git.openstack.org has an up-to-date log:
http://git.openstack.org/cgit/openstack/neutron-specs/log/
Unfortunately I don't know what the policy is for syncing repos with github.
Salvatore
On 4 July 2014 00:34, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:
Is this still the right repo for
[3] https://review.openstack.org/#/c/99182/
[4] https://review.openstack.org/#/c/103865/
[5] https://bugs.launchpad.net/neutron/+bug/1273386
On 25 June 2014 23:38, Matthew Treinish mtrein...@kortar.org wrote:
On Tue, Jun 24, 2014 at 02:14:16PM +0200, Salvatore Orlando wrote:
There is a long
There is a long standing patch [1] for enabling the neutron full job.
Little before the Icehouse release date, when we first pushed this, the
neutron full job had a failure rate of less than 10%. However, since has
come by, and perceived failure rates were higher, we ran again this
analysis.
Here
Ops... I forgot to mention that in agreement with sdague we won't anyway
enable this job before thursday June 26th, in order to give a few days to
the trusty update to settle down.
Salvatore
On 24 June 2014 14:14, Salvatore Orlando sorla...@nicira.com wrote:
There is a long standing patch [1
Hi Jeff,
in a nutshell, Neutron has its IPAM logic baked into the main 'db class'.
However, Neutron's IPAM does not manage at all the underlay - it manages
exclusively devices in the 'logical' realm.
There are been discussions in the past concerning Physical appliance
management in Neutron, not
Hi Luke,
That kind of message usually shows up in unit tests job when there is some
syntax error or circular import. But I think that it's not your case.
Usually you see an import error message towards the end of the garbage.
If you can point me to a failing log of your CI I can have a look at
] http://paste.openstack.org/show/84406/
On 18 June 2014 18:01, Luke Gorrie l...@snabb.co wrote:
On 18 June 2014 15:48, Salvatore Orlando sorla...@nicira.com wrote:
Hi Luke,
That kind of message usually shows up in unit tests job when there is
some syntax error or circular import. But I think
and developers might have an answer to your
problem.
Salvatore
On 18 June 2014 18:54, Luke Gorrie l...@snabb.co wrote:
On 18 June 2014 18:24, Salvatore Orlando sorla...@nicira.com wrote:
it seems something is not quite right with your tempest environment - you
have import errors at startup [1
We've started doing this in a slightly more reasonable way for icehouse.
What we've done is:
- remove unnecessary notification from the server
- process all port-related events, either trigger via RPC or via monitor in
one place
Obviously there is always a lot of room for improvement, and I agree
I will probably be unable, as usual, to attend today's CI meeting (falls
right around my dinner time).
I think it's a good idea to starting keeping track of the status of the
various CI systems, but I feel the etherpad will not work very well in the
long term.
However, it would be great if we
On 16 June 2014 15:58, Kyle Mestery mest...@noironetworks.com wrote:
On Mon, Jun 16, 2014 at 8:52 AM, Salvatore Orlando sorla...@nicira.com
wrote:
I will probably be unable, as usual, to attend today's CI meeting (falls
right around my dinner time).
I think it's a good idea to starting
I think there's is no suitable place at the moment in the source code tree.
common and plugin specific indeed are semantically a bit at odds too!
I am considering moving all library code for the vmware plugins outside
of the source code tree, into their own package, maintained separately and
Hi Israel,
please find my answers inline.
I'm not really an expert in this area, but I hope these answers are
helpful, and, hopefully, correct!
Salvatore
On 15 June 2014 14:55, Israel Ziv israel@huawei.com wrote:
Hi!
Please let me know if I’ve reached the proper group.
I am going
Regarding the two approaches outlines in the top post, I found out that the
bullet This is API versioning done the wrong way appears in both
approaches.
Is this a mistake or intentional?
From what I gather, the most reasonable approach appears to be starting
with a clean slate, which means having
Avishay,
what you say here is correct.
However, as we are in the process of moving to Pecan as REST API framework
I would probably refrain from adding new features to it at this stage.
Therefore, even if far from ideal, this kind of validation should perhaps
be performed in the DB layer. I think
I would like to understand how did we get to this 80%/20% distinction.
In other terms, it seems conntrack's RELATED features won't be supported
for non-tcp traffic. What about the ESTABLISHED feature? The blueprint
specs refers to tcp_flags=ack.
Or will that be supported through the source port
It seems that method has some room for optimization, and I suspect the same
logic has been used in other type drivers as well.
If optimization is possible, it might be the case to open a bug for it.
Salvatore
On 30 May 2014 04:58, Xurong Yang ido...@gmail.com wrote:
Hi,
Thanks for your
201 - 300 of 459 matches
Mail list logo
