yahoo-eng-team team mailing list archive

[OpenStack Infra <1424096@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/257938
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=96ba199d733944e5b8aa3664a04d9204fd66c878
Submitter: Jenkins
Branch:    master

commit 96ba199d733944e5b8aa3664a04d9204fd66c878
Author: Oleg Bondarev <obondarev@xxxxxxxxxxxx>
Date:   Tue Dec 15 17:58:51 2015 +0300

    Use admin context when removing DVR router on vm port deletion
    
    In case non-admin tenant removes last VM on a shared network (owned
    by admin) connected to a DVR router (also owned by admin) we need
    to remove the router from the host where there are no more dvr
    serviceable ports. Commit edbade486102a219810137d1c6b916e87475d477
    fixed logic that determines routers that should be removed from host.
    However in order to actually remove the router we also need admin
    context.
    
    This was not caught by unit tests and one reason for that is so called
    'mock everything' approach which is evil and generally useless.
    This patch replaces unit tests with functional tests that we able
    to catch the bug.
    
    Closes-Bug: #1424096
    Change-Id: Ia6cdf2294562c2a2727350c78eeab155097e0c33


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1424096

Title:
  DVR routers attached to shared networks aren't being unscheduled from
  a compute node after deleting the VMs using the shared net

Status in neutron:
  Fix Released
Status in neutron juno series:
  Fix Released
Status in neutron kilo series:
  New

Bug description:
  As the administrator, a DVR router is created and attached to a shared
  network. The administrator also created the shared network.

  As a non-admin tenant, a VM is created with the port using the shared
  network.  The only VM using the shared network is scheduled to a
  compute node.  When the VM is deleted, it is expected the qrouter
  namespace of the DVR router is removed.  But it is not.  This doesn't
  happen with routers attached to networks that are not shared.

  The environment consists of 1 controller node and 1 compute node.

  Routers having the problem are created by the administrator attached
  to shared networks that are also owned by the admin:

  As the administrator, do the following commands on a setup having 1
  compute node and 1 controller node:

  1. neutron net-create shared-net -- --shared True
     Shared net's uuid is f9ccf1f9-aea9-4f72-accc-8a03170fa242.

  2. neutron subnet-create --name shared-subnet shared-net 10.0.0.0/16

  3. neutron router-create shared-router
      Router's UUID is ab78428a-9653-4a7b-98ec-22e1f956f44f.

  4. neutron router-interface-add shared-router shared-subnet
  5. neutron router-gateway-set  shared-router public

  
  As a non-admin tenant (tenant-id: 95cd5d9c61cf45c7bdd4e9ee52659d13), boot a VM using the shared-net network:

  1. neutron net-show shared-net
  +-----------------+--------------------------------------+
  | Field           | Value                                |
  +-----------------+--------------------------------------+
  | admin_state_up  | True                                 |
  | id              | f9ccf1f9-aea9-4f72-accc-8a03170fa242 |
  | name            | shared-net                           |
  | router:external | False                                |
  | shared          | True                                 |
  | status          | ACTIVE                               |
  | subnets         | c4fd4279-81a7-40d6-a80b-01e8238c1c2d |
  | tenant_id       | 2a54d6758fab47f4a2508b06284b5104     |
  +-----------------+--------------------------------------+

  At this point, there are no VMs using the shared-net network running
  in the environment.

  2. Boot a VM that uses the shared-net network: nova boot ... --nic net-id=f9ccf1f9-aea9-4f72-accc-8a03170fa242 ... vm_sharednet
  3. Assign a floating IP to the VM "vm_sharednet"
  4. Delete "vm_sharednet". On the compute node, the qrouter namespace of the shared router (qrouter-ab78428a-9653-4a7b-98ec-22e1f956f44f) is left behind

  stack@DVR-CN2:~/DEVSTACK/manage$ ip netns
  qrouter-ab78428a-9653-4a7b-98ec-22e1f956f44f
   ...

  
  This is consistent with the output of "neutron l3-agent-list-hosting-router" command.  It shows the router is still being hosted on the compute node.

  
  $ neutron l3-agent-list-hosting-router ab78428a-9653-4a7b-98ec-22e1f956f44f
  +--------------------------------------+----------------+----------------+-------+
  | id                                   | host           | admin_state_up | alive |
  +--------------------------------------+----------------+----------------+-------+
  | 42f12eb0-51bc-4861-928a-48de51ba7ae1 | DVR-Controller | True           | :-)   |
  | ff869dc5-d39c-464d-86f3-112b55ec1c08 | DVR-CN2        | True           | :-)   |
  +--------------------------------------+----------------+----------------+-------+

  Running the "neutron l3-agent-router-remove" command removes the
  qrouter namespace from the compute node:

  $ neutron l3-agent-router-remove ff869dc5-d39c-464d-86f3-112b55ec1c08 ab78428a-9653-4a7b-98ec-22e1f956f44f
  Removed router ab78428a-9653-4a7b-98ec-22e1f956f44f from L3 agent

  stack@DVR-CN2:~/DEVSTACK/manage$ ip netns
  stack@DVR-CN2:~/DEVSTACK/manage$

  This is a workaround to get the qrouter namespace deleted from the
  compute node. The L3-agent scheduler should have removed the router
  from the compute node when the VM is deleted.

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