l3agent-remove-router should fail if there are floatingip associated with that agent

[Murali Birru]

l3agent-router-remove is allowed from l3-agent if floatingip is associated on that agent.

this command should fail if any floatingip's are associated with that agent. should allow to remove only when no floatingip's are associated

[Oleg Bondarev (obondarev)]

router-in-use check is done on the server side, which includes checks for floating ips or any ports associated with the router. These checks are performed before sending delete request to the agent. Can you please clarify why additional check is needed on the agent side?

[Jack McCann (jack-mccann)]

Not sure exactly what you are proposing, but from the description above it sounds like you are saying I should not be able to remove a router from an l3 agent if that router has floating IPs.

I should be able to remove (unschedule) a router from an l3 agent, and add (reschedule) it to another l3 agent, whether or not it has floating IPs. For example, I need to take a server down for maintenance, I should be able to move a router off that server and onto another server.

[Murali Birru (mbirru)]

Hi Oleg,

I understand the those validations checks are availbale for "neutron delete-router".

But here the use case is when user wants remove the router from agent using the command "neutron l3agent-router-remove <agent-id> <router-id>"
In this case we are not checking whether flotingip is associated or not.

Thanks
-Murali

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Oleg Bondarev
Sent: Monday, April 14, 2014 11:59 PM
To: Birru, Murali Yadav
Subject: [Bug 1307840] Re: l3agent-remove-router should fail if there are floatingip associated with that agent

router-in-use check is done on the server side, which includes checks for floating ips or any ports associated with the router. These checks are performed before sending delete request to the agent. Can you please clarify why additional check is needed on the agent side?

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1307840

Title:
  l3agent-remove-router should fail if there are floatingip associated
  with that agent

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  l3agent-router-remove is allowed from l3-agent if floatingip is
  associated on that agent.

  this command should fail if any floatingip's are associated with that
  agent. should allow to remove only when no floatingip's are
  associated

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1307840/+subscriptions

[Murali Birru (mbirru)]

Hi Jack,

Right now the current behavior: It is allowed to remove(unschedule) the router from agent even when there are floatingip associated with that agent.

Now I would like add the validation before removing(unschedule) the router from agent for floatingIp's.

If no floating-ip's are associated with the l3agent then only allow the remove router from l3agent. Otherwise it though error to user

Thanks
-Murali

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Jack McCann
Sent: Tuesday, April 15, 2014 6:26 AM
To: Birru, Murali Yadav
Subject: [Bug 1307840] Re: l3agent-remove-router should fail if there are floatingip associated with that agent

Not sure exactly what you are proposing, but from the description above it sounds like you are saying I should not be able to remove a router from an l3 agent if that router has floating IPs.

I should be able to remove (unschedule) a router from an l3 agent, and add (reschedule) it to another l3 agent, whether or not it has floating IPs. For example, I need to take a server down for maintenance, I should be able to move a router off that server and onto another server.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1307840

Title:
  l3agent-remove-router should fail if there are floatingip associated
  with that agent

Status in OpenStack Neutron (virtual network service):
  Incomplete

Bug description:
  l3agent-router-remove is allowed from l3-agent if floatingip is
  associated on that agent.

  this command should fail if any floatingip's are associated with that
  agent. should allow to remove only when no floatingip's are
  associated

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1307840/+subscriptions

[Murali Birru (mbirru)]

Hi

I understand the information on this bug is not enough to understand. Please follow the below description for this bug
Provide me you’re your thoughts on this bug

Creating an External Network:
neutron net-create ext-net --router:external=True Created a new network:
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | True |
| id | 69c37dff-e7e0-4b51-a6d5-da08dd3fe55f |
| name | ext-net |
| provider:network_type | vxlan |
| provider:physical_network | |
| provider:segmentation_id | 2002 |
| router:external | True |
| shared | False |
| status | ACTIVE |
| subnets | |
| tenant_id | e14188c580374f24b0552eb16ad608c0 |
+---------------------------+--------------------------------------+

Creating the Public Subnet on the External Network:
neutron subnet-create ext-net --name ext-sub 192.168.101.0/24 --enable_dhcp false --gateway_ip 192.168.101.1 Created a new subnet:
+------------------+------------------------------------------------------+
| Field | Value |
+------------------+------------------------------------------------------+
| allocation_pools | {"start": "192.168.101.2", "end": "192.168.101.254"} |
| cidr | 192.168.101.0/24 |
| dns_nameservers | |
| enable_dhcp | False |
| gateway_ip | 192.168.101.1 |
| host_routes | |
| id | 23846271-5cef-416c-88b4-c279f2fe6e0c |
| ip_version | 4 |
| name | ext-sub |
| network_id | 69c37dff-e7e0-4b51-a6d5-da08dd3fe55f |
| tenant_id | e14188c580374f24b0552eb16ad608c0 |
+------------------+------------------------------------------------------+

Creating a Floating IP on Public Network:
neutron floatingip-create ext-net
Created a new floatingip:
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| fixed_ip_address | |
| floating_ip_address | 192.168.101.2 |
| floating_network_id | 69c37dff-e7e0-4b51-a6d5-da08dd3fe55f |
| id | 5255c0f8-1cf2-4...

[Salvatore Orlando (salvatore-orlando)]

The commands for associating routers with floating IPs are supposed to be executed from admin only.
An administrator should be allowed to take offline for rescheduling routers even if they have floating IPs active on it.
This is an operation which might be required for maintenance.

During a mainteinance events, users will be usually warned via other means. When the router is rescheduled, the floating IP should be created again. It's important that this is confirmed.
Requiring floating IPs to be removed before rescheduling a router seems excessive, and could make a lot more difficult performing mainteinance tasks.

I'm resetting this bug to incomplete, waiting for the submitter to make a case again for his claim.

[Cedric Brandily (cbrandily)]

This bug is > 365 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]