[openstack-dev] [neutron] dns-nameservers order not honored

2015-06-23 Thread Paul Ward
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

[openstack-dev] [neutron] No concept for user owner of a neutron port... security issue?

2015-03-13 Thread Paul Ward
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

[openstack-dev] [neutron] ovs-neutron-agent wipes out all flows on startup

2014-06-30 Thread Paul Ward
The current design for ovs-neutron-agent is that it will wipe out all flows configured on the system when it starts up, recreating them for each neutron port it's aware of. This has a not-so-desirable side effects that there's a temporary hiccup in network connectivity for the VMs on the

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-06-05 Thread Paul Ward
? 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

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-29 Thread Paul Ward
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

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-29 Thread Paul Ward
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

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-28 Thread Paul Ward
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

[openstack-dev] [Openstack-stable-maint] Stable exception

2014-05-28 Thread Paul Ward
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

[openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-27 Thread Paul Ward
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

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-27 Thread Paul Ward
(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

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-27 Thread Paul Ward
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

[openstack-dev] [neutron] alembic migration not working? specifically in regards to ml2_port_bindings table

2014-04-08 Thread Paul Ward
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

Re: [openstack-dev] [neutron] alembic migration not working? specifically in regards to ml2_port_bindings table

2014-04-08 Thread Paul Ward
/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

Re: [openstack-dev] [neutron] ML2 plugin swallows mechanism driver exceptions

2014-01-28 Thread Paul Ward
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

Re: [openstack-dev] [neutron] Neutron should disallow /32 CIDR

2014-01-24 Thread Paul Ward
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

[openstack-dev] [neutron] ML2 plugin swallows mechanism driver exceptions

2014-01-24 Thread Paul Ward
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

Re: [openstack-dev] [neutron] Neutron should disallow /32 CIDR

2014-01-23 Thread Paul Ward
check that the pool fits within 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

Re: [openstack-dev] [neutron] Neutron should disallow /32 CIDR

2014-01-22 Thread Paul Ward
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

[openstack-dev] [neutron] Neutron should disallow /32 CIDR

2014-01-21 Thread Paul Ward
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

Re: [openstack-dev] [neutron] Neutron should disallow /32 CIDR

2014-01-21 Thread Paul Ward
] 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

Re: [openstack-dev] [neutron] Neutron should disallow /32 CIDR

2014-01-21 Thread Paul Ward
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

Re: [openstack-dev] [neutron] ML2 vlan type driver does not honor network_vlan_ranges

2014-01-17 Thread Paul Ward
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

[openstack-dev] [neutron] ML2 vlan type driver does not honor network_vlan_ranges

2014-01-16 Thread Paul Ward
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