I think this bug was considered fixed because at the time once the patch
addressing was merged, the bug automatically went into fix committed.
It should therefore be re-opened. Even if tweaking sql pool parameters
avoids the issue, this should be considered more of a mitigation rather
than a
Hi,
As you might have noticed, there has been some progress on parallel tests
for neutron.
In a nutshell:
* Armando fixed the issue with IP address exhaustion on the public network
[1]
* Salvatore has now a patch which has a 50% success rate (the last failures
are because of me playing with it)
November 2013 09:08, Salvatore Orlando sorla...@nicira.com wrote:
Thanks Maru,
This is something my team had on the backlog for a while.
I will push some patches to contribute towards this effort in the next
few
days.
Let me know if you're already thinking of targeting the completion
Thanks Maru,
This is something my team had on the backlog for a while.
I will push some patches to contribute towards this effort in the next few
days.
Let me know if you're already thinking of targeting the completion of this
job for a specific deadline.
Salvatore
On 27 November 2013 17:50,
Hi,
I've been recently debugging some issues I've had with the OVS agent, and I
found out that in many cases (possibly every case) the code just logs
errors from ovs-vsctl and ovs-ofctl without taking any action in the
control flow.
For instance, the routine which should do the wiring for a
Thanks Kyle,
More comments inline.
Salvatore
On 25 November 2013 16:03, Kyle Mestery (kmestery) kmest...@cisco.comwrote:
On Nov 25, 2013, at 8:28 AM, Salvatore Orlando sorla...@nicira.com
wrote:
Hi,
I've been recently debugging some issues I've had with the OVS agent,
and I found
Hi Lorin,
I think yours is a very good question; I am afraid I am not able to provide
a straight answer regarding in which cases one service should be preferred
to the other.
Technically the difference would be that a firewall rule is enforced only
at the edge of your network, and is therefore
Forgive my ignorance, but I would like to make sure that packets generated
from Openstack instances on neutron private networks will actually be able
to reach public addresses.
In its default configuration the traffic from the OS instance is SNATed and
the SRC IP will be rewritten to an address
Thanks
Avishay
*From:* Salvatore Orlando [mailto:sorla...@nicira.com]
*Sent:* Thursday, November 14, 2013 1:15 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Neutron] - Vendor specific erros
In general, an error state make sense
For what is worth we have considered this aspect from the perspective of
the Neutron plugin my team maintains (NVP) during the past release cycle.
The synchronous model that most plugins with a controller on the backend
currently implement is simple and convenient, but has some flaws:
-
://www.slideshare.net/harlowja/taskflow-27820295
From: Salvatore Orlando sorla...@nicira.com
Date: Tuesday, November 19, 2013 2:22 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Cc: Joshua Harlow harlo...@yahoo-inc.com, Isaku Yamahata
Oh no, not another *aas!
Seriously, I don't think IP address management should be a service of its
own independent from Neutron and/or nova-network.
Neutron currently has an IPAM logic which is entirely coded in
db_base_plugin_v2.py, and is more or less loosely coupled with the DHCP
agent.
We
Hi Yair,
I had in mind of doing something similar. I also registered a tempest
blueprint for it.
Basically I think we can assume test machines have access to the Internet,
but the devstack deployment might not be able to route packets from VMs to
the Internet.
Being able to ping the external
I've pushed https://review.openstack.org/#/c/56923/ trying to follow this
protocol.
Salvatore
On 14 November 2013 16:38, Zhi Kun Liu liuzhi...@gmail.com wrote:
+1, This is a great idea. We could consider it as a general process for
all tests.
2013/11/14 Koderer, Marc m.kode...@telekom.de
create, this might partially solve the side effect problem as
you'll get the floating ip ID as well in the response.
Thoughts? Ideas? Criticisms? Complements? J
Steven
Original message
From: Salvatore Orlando sorla...@nicira.com
Date: 11/14/2013 4:23 AM (GMT-07:00
Apologies for forking the thread.
I think this is probably the last post with some content which might be
useful for a discussion which does not involve fashion police.
On another note, I've seen my name is in the list of the required
attendees. To be fair and honest I'm not any more required
I also completely agree with this policy - and I hope all the developers
contributing code to non-core plugins like me will agree as well.
There is nothing like verifiability. This will also make a lot easier code
reviews for non-core plugins; one of the reasons for which these reviews
tend to
Hi Alejandro,
As we've already discussed the topic over IRC, let me add something else on
your setup:
- no dhcp agent, no l3 agent
- IP configuration injected into instances
(I'm disclosing this information since it's already been disclosed on IRC
whose logs are publicly accessible anyway)
Hi Alejandro,
As we've already discussed the topic over IRC, let me add something else on
your setup:
- no dhcp agent, no l3 agent
- IP configuration injected into instances
(I'm disclosing this information since it's already been disclosed on IRC
whose logs are publicly accessible anyway)
Also, just to add some pedantry (which you know I am very fond of), it
would be the case to share on openstack-dev minutes and logs from eavesdrop
after each subteam meeting.
I know they're anyway at http://eavesdrop.openstack.org/meetings/ - but
sending an email will be useful to notify the rest
In general, an error state make sense.
I think you might want to send more details about how this state plugs into
the load balancer state machine, but I reckon it is a generally
non-recoverable state which could be reached by any other state; in that
case it would be a generic enough case which
Although IRC requires typing, I find it more inclusive than Webex.
It's easy to have 100s of people in a IRC room, not so easy on a conf call.
Also, people like me whose 1st language is not English might find easier to
write read rather than listen speak.
Finally, the capability of generating
I reckon we should wait a little for the PTL to propose a draft of the
policy we can comment on.
'thirdy paty test' probably was meant as integration with gerrit (
http://ci.openstack.org/third_party.html); the test suite to be executed
is, obviously, the tempest test suite.
In my opinion, the
I don't think there has been any development in the past 6 months.
A few people have shown interest in it in the past, but the blueprint has
currently no assignee.
So If you want to work on it, feel free to assign to yourself.
To quickly sum up the discussion around this blueprint, it could be
This blueprint is related (the concept stands for any network, not just
externals):
https://blueprints.launchpad.net/neutron/+spec/sharing-model-for-external-networks
You can read the blueprint and spec pages for some context.
Bottom line is that it would be great to have some feedback on whether
Il giorno 03/nov/2013 17:15, Robert Collins robe...@robertcollins.net
ha scritto:
On 3 November 2013 17:36, Edgar Magana emag...@plumgrid.com wrote:
Zen, Kevin, Aaron, Salvatore et al,
Thank you so much for taking some time and reviewing this proposal. I
couldn't get any time slot
Hi Sean,
I looked further yesterday and nailed down an issue which cause a spike of
failures due to a patch merged on thursday early morning (GMT), for which a
patch was pushed to gerrit.
I then handed off to Armando Migliaccio, who has already pushed a few
patches to solve these issues. (which
Gary,
In the context of the nvp plugin we use a mechanism for enabling 'advanced'
capabilities of a router leveraging a 'router_service_type' extension.
this allow us to configure two types of routers, one which does just L3
forwarding, NAT and a few other things, and another one which also has
It might be worth both documenting this limitation on the admin guide and
provide a fix which we should backport to havana too.
It sounds like the fix should not be too extensive, so the backport should
be easily feasible.
Regards,
Salvatore
On 18 October 2013 21:50, Édouard Thuleau
From this traceback the only thing I can think of is that this behaviour is
related to https://bugs.launchpad.net/neutron/+bug/1236439
Can you please check the status of your agents?
Regards,
Salvatore
On 20 October 2013 08:31, Chu Duc Minh chu.ducm...@gmail.com wrote:
I'm upgrading from
wrote:
On 10/17/2013 08:46 AM, Salvatore Orlando wrote:
Hi,
in the discussion for patch
https://review.openstack.org/#**/c/50880/https://review.openstack.org/#/c/50880/Sean
asked a very reasonable question:
so are all these [Neutron] extensions always loaded on all
environments? If not, how
What about your l3 agents?
Please check if you're being hit by this upgrade bug:
https://bugs.launchpad.net/neutron/+bug/1236439
The bug mentions the l3 agents but applies to all agents.
Regards,
Salvatore
On 16 October 2013 20:27, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:
Aaron,
I
Hi Marco,
At least two of your questions clearly hint at the dichotomy between subnet
and network, which appear to be redundant.
A multi-homing use case on a single network is a potential use case for
this, albeit a very limited one, since one might argue that in a cloud
scenario instead of
Hi Rudra,
Some comments inline.
Regards,
Salvatore
Il 09/ott/2013 19:27 Rudra Rugge rru...@juniper.net ha scritto:
Updated the subject [neutron]
Hi All,
Is the extra route extension always tied to the router extension or
can it live in a separate route-table container. If extra-route
Hi Kumar,
some comments to your questions inline.
I am afraid I am unable to provide thorough answers. hopefully my thoughts
will be beneficial at least to provide more context.
Salvatore
On 2 October 2013 19:04, Kumar chvs...@gmail.com wrote:
Hi,
We are considering to run openstack
Emilien,
thanks for sharing this, which I reckong is going to be a very interesting
discussion at the next summit.
Of the two alternatives, I tend to prefer the latter as it is capable of
handling better failover; it would be good if you could more details about
the failover procedure; in the
Hi,
where are you observing such calls?
The vm boot process makes indeed several REST calls to Neutron, but about
90% of them are GETs, there should be only 1 POST for each port, and a few
puts.
I think you should not see DELETE in the boot process, so perhaps these
calls are coming from
Hi Marc,
Perhaps this guide [1] might help you going through the process of signign
the CLA and pushing your code to gerrit for review.
Salvatore
[1] https://wiki.openstack.org/wiki/How_To_Contribute
On 11 September 2013 23:13, Marc PINHEDE pinhede.m...@netvirt.ca wrote:
Hello,
I am Marc
whenever I run devstack keystone falies to start because dogpile.cache is
not installed; this is easily solved by installing it, but I wonder if it
should be in requirements.txt
Also, since the cache appears to be disabled by default (and I'm not
enabling it in my localrc), I'm not sure why I am
Is the cache module enabled on the devstack gate? If not, it's definetely
an issue on my side - otherwise we would have known about this.
Salvatore
On 4 September 2013 15:23, Dolph Mathews dolph.math...@gmail.com wrote:
On Wed, Sep 4, 2013 at 9:14 AM, Salvatore Orlando sorla
Hi Alan,
Design session proposal has opened today at summit.openstack.org; on the
other hand conference session proposal closed on July 31st.
I believe voting closed at some point last week (possibly August 29th).
Accepted talks should be announced in a few days. The voting system was
available
Hi,
We are removing the schema autogeneration capability from Neutron [1].
The patch however did not pass Torpedo tests on Smokestack; looking at the
logs it seems Firestack deploys Neutron but the db is empty, which is
consistent with firestack leveraging schema auto-generation capabilities.
The full suite of neutron tests is non voting; your jenkins job is failing
because of unit tests.
The reason for this failure, I believe, is the inability of querying
neutron ports by IP using a regex.
There is a blueprint for that already registered: allow filters to use
'like' operation of
As I said during the meeting, I am happy to support both as long as the
code churn is reasonably contained and the chances of strongswan support
introducing bugs into openswan driver are negligible.
Openswan should be the default solution, in muy opinion.
Salvatore
On 20 August 2013 00:15,
I tend to agree that when the gate for a project is broken, nothing should
be merged for that project until the gate jobs are green again.
In the case of Neutron, making the job non voting only caused more bugs to
slip through, and that meant more works for the developer themselves, and
more
As Ashok said, Aaron is working on a patch for removing the need for
holding an IP.
This will make IP addresses immediately reusable, thus removing the 'hold'
process.
This is however not likely to be backported to grizzly; it will be an
havana feature.
Salvatore
On 7 August 2013 17:44, Ashok
Hi Ben,
The closest the thing to what you want to achieve is the Floating IP, but,
as you say, this will not allow for fine-grained control over ports; so you
won't be able, for instance, to expose only port 443 of an internal IP.
However, this is not in the Havana roadmap at the moment - but
be the role of this noop driver?
Thanks,
Eugene.
On Wed, Jul 31, 2013 at 11:47 AM, Salvatore Orlando
sorla...@nicira.comwrote:
More comments on top of your comments!
And one more question: what are we going to do with 'orphaned' logical
instances? Can they be associated with another
Hi Sam,
is what you're trying to do tantamount to creating a port on a network
whose tenant_id is different from the network's tenant_id?
We have at the moment a fairly strict ownership check - which does not
allow even admin users to do this operation.
I do not have a strong opinion against
to implement the
same in Neutron.
Salvatore,
Can you share with us the concerns in implementing in Neutron?
Thanks,
-Ravi.
On Wed, Jul 31, 2013 at 12:57 AM, Salvatore Orlando
sorla...@nicira.comwrote:
Hi Ofer,
Basically this operation consists in ensuring that an instance
It is my personal opinion that there is no necessary condition between
'having the possibility of leaving a resource without service provider' and
'API users want to create resources without service providers'.
While being able to change the 'provider' associated with a resource is a
reasonable
To add more context to what Nachi quoted, in general the operational status
of a virtual advanced network service depends on the drivers that
implements it.
So far, the drivers being developed for firewall, VPN, and possibly even
Load Balancing all implement the same architecture. In my opinion it
totally +1 for mestery
+1 for Armax only if he stops serially -1'ing my patches.
Cheers,
Salvatore
PS: of course the official vote is +1 for both.
On 23 July 2013 13:37, Dan Wendlandt d...@nicira.com wrote:
+1's from this emeritus member of the core team :)
On Tue, Jul 23, 2013 at 1:04
I reckon the netifaces package is only used in Neutron's Ryu plugin.
At a first glance, it should be possible to replace its current usage with
the iplib module which has been developed within neutron itself.
Unless we hear otherwise from contributors to the Ryu plugin it is my
opinion that we
Hi Ivar,
thanks for your interest in Openstack and Neutron.
A few replies inline; I hope you'll find them useful.
Salvatore
On 10 July 2013 02:40, Ivar Lazzaro i...@embrane.com wrote:
Hi,
My name is Ivar Lazzaro, I’m an Italian developer currently employed at
Embrane.
Some comments inline.
Salvatore
On 9 July 2013 21:58, Eugene Nikanorov enikano...@mirantis.com wrote:
Nachi,
I think that dynamic loading/preloaded modules/REST api analogs of nova
flavor is a bit too forward looking in comparison to what I'm trying to
solve right now with existing patch.
Kyle,
is this commit basically a rebase on top of 91e0850?
In that case the diff with the previous patchset would be empty.
I recall I had a similar issue; I just tweaked a comment line in my commit
to let gerrit think it was a different patchset.
Salvatore
On 2 July 2013 23:05, Kyle Mestery
HEAD~1 would be the same in both cases.
If this however is not your problem just disregard this post.
Salvatore
On 2 July 2013 23:29, Kyle Mestery (kmestery) kmest...@cisco.com wrote:
On Jul 2, 2013, at 4:18 PM, Salvatore Orlando sorla...@nicira.com wrote:
Kyle,
is this commit
I reckon the admin guide [1] contains sufficiently up-to-date information
for the grizzly release.
Please let me know if you find it lacks important information. We'll be
more than happy to make the necessary amendments.
Your scenario appears to be fairly simple. On the compute node you will
need
401 - 459 of 459 matches
Mail list logo
