I haven't dug into the code yet, but from testing via CLI and REST API,
it appears neutron does not honor the order in which users specify their
dns-nameservers. For example, no matter what order I specify 10.0.0.1
and 10.0.0.2 for dns-nameservers, they are always ordered with the
numerically
From what I can tell, neutron ports do not have the concept of an
owner that is a user. They have device_owner, which seems to be
more for things like assigning to a router.
The reason I bring this up is because there seems to be no way to
restrict the update/delete of a port to only the
?
Carl
On Thu, May 29, 2014 at 11:15 AM, Paul Ward wpw...@us.ibm.com wrote:
Yes, we're still on a code level that uses httplib2. I noticed that as
well, but wasn't sure if that would really
help here as it seems like an ssl thing itself. But... who knows?? I'm not
sure how consistently we can
fixed the server :)). Most of the times I've seen this type of
failure is due to deadlock errors caused between (sqlalchemy and
eventlet *i think*) which cause the client to eventually timeout.
Best,
Aaron
On Wed, May 28, 2014 at 11:51 AM, Paul Ward wpw...@us.ibm.com wrote:
Would
are referring to
manifest themselves with the former http library rather than the
latter. Could you clarify?
Thanks,
Armando
[1] - https://review.openstack.org/#/c/89879/
On 29 May 2014 17:25, Paul Ward wpw...@us.ibm.com wrote:
Well, for my specific error, it was an intermittent ssl handshake
mechanism in the client and
instead make the user of the client implement retry so they are
aware of failures.
Aaron
On Tue, May 27, 2014 at 10:48 AM, Paul Ward wpw...@us.ibm.com wrote:
Currently, neutronclient is hardcoded to only try a request once in
retry_request by virtue of the fact
I'll start by saying that we don't need this ported to icehouse as we've
included it in our distro, as Alan suggested.
However, I would like to explain why we needed it. We do generate
cert files for the controller node. However, for cases where the different
services are all running on the
Currently, neutronclient is hardcoded to only try a request once in
retry_request by virtue of the fact that it uses self.retries as the retry
count, and that's initialized to 0 and never changed. We've seen an issue
where we get an ssl handshaking error intermittently (seems like more of an
(not for usage questions)
openstack-dev@lists.openstack.org,
Date: 05/27/2014 02:00 PM
Subject: Re: [openstack-dev] [neutron] Supporting retries in
neutronclient
On Tue, May 27, 2014 at 12:48 PM, Paul Ward wpw...@us.ibm.com wrote:
Currently, neutronclient is hardcoded to only try a request once
creation; retrying this again leads to multiple fixed IPs
assigned to a VM
Thanks,
Eugene.
On Wed, May 28, 2014 at 12:09 AM, Kyle Mestery mest...@noironetworks.com
wrote:
I'm not aware of any such change at the moment, no.
On Tue, May 27, 2014 at 3:06 PM, Paul Ward wpw...@us.ibm.com wrote
Is anyone else out there seeing failures that appear to be because alembic
is not upgrading db tables in neutron? I'm seeing, on an upgrade, that
ml2_port_bindings is not being updated to remove column cap_port_filter or
add columns vnic_type, profile, or vif_details, I'm also seeing the
/master/
neutron/db/migration/README ?
Itzik
On 08/04/2014 23:41, Paul Ward wrote:
Is anyone else out there seeing failures that appear to be because
alembic is not upgrading db tables in neutron? I'm seeing, on an
upgrade, that ml2_port_bindings is not being updated to remove
column
in the MechanismDriverError message, I think that'd help a lot.
Andre
On Fri, Jan 24, 2014 at 1:19 PM, Paul Ward wpw...@us.ibm.com wrote:
In implementing a mechanism driver for ML2 today, I discovered that
any exceptions thrown from your mechanism driver will get swallowed
by the ML2 manager (https
Given your obviously much more extensive understanding of networking than
mine, I'm starting to move over to the we shouldn't make this fix camp.
Mostly because of this:
CARVER, PAUL pc2...@att.com wrote on 01/23/2014 08:57:10 PM:
Putting a friendly helper in Horizon will help novice users and
In implementing a mechanism driver for ML2 today, I discovered that any
exceptions thrown from your mechanism driver will get swallowed by the ML2
manager (
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/managers.py
at line 164).
Is this by design? Sure, you can look at
and
validate the pool. It seems to do a adequate job of that.
Perhaps there is a _validate_subnet method that you should be
focused on? (I'd check but I don't have convenient access to the
code at the moment)
Carl
On Jan 21, 2014 6:16 PM, Paul Ward wpw...@us.ibm.com wrote:
You beat me
Currently, NeutronDbPluginV2._validate_allocation_pools() does some very
basic checking to be sure the specified subnet is valid. One thing that's
missing is checking for a CIDR of /32. A subnet with one IP address in it
is unusable as the sole IP address will be allocated to the gateway, and
] Neutron should disallow /32 CIDR
Wouldn't be easier just to check if:
cidr is 32?
I believe it is a good idea to not allow /32 network but this is
just my opinion
Edgar
From: Paul Ward wpw...@us.ibm.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Tuesday, January 21
the allocatable range of the subnet. I think
we're good.
Carl
On Tue, Jan 21, 2014 at 3:35 PM, Paul Ward wpw...@us.ibm.com wrote:
Currently, NeutronDbPluginV2._validate_allocation_pools() does some
very
basic checking to be sure the specified subnet is valid. One thing
that's
missing is checking
networks. Provider networks are not confined to this pool. In
fact, I
believe it is a more common use-case that provider vlans are outside the
pool so that they do not conflict with tenant vlan allocation.
-- Henry
On Thu, Jan 16, at 3:45 pm, Paul Ward wpw...@us.ibm.com wrote:
In testing some
In testing some new function I've written, I've unsurfaced the problem that
the ML2 vlan type driver does not enforce the vlan range specified in the
network_vlan_ranges option in ml2_conf.ini file. It is properly enforcing
the physical network name, and even checking to be sure the
21 matches
Mail list logo
