namespace is not reassigned on swact

[Jose Perez Carranza]

Title
-----
Namespace created on controller is not reassigned when doing a swact

Brief Description
-----------------
When a network is created also a namespace should be created in order to ping the VMs by namespace, currently the namespace is created but when doing a swact the namspace remains assigned to the previous controller and on the active controller no namespace is available.

Severity
--------
Provide the severity of the defect.
Major

Steps to Reproduce
------------------
1. On active controller create a net and a subnet
 $ openstack network create test-net --shared
 $ penstack subnet create --network test-net --subnet-range 192.168.0.0/24 --ip-version 4 --dhcp test-subnet

2. Verify that a namespace is created with the id of the network
 $ sudo ip netns
    qdhcp-<ntwrok_uid>

3. Perform a swact on active controller
  $ system host-swact <controller_X>

4. Wain until swact is completed

5. On Controller active (controler-Y) execute command
  $ sudo ip netns

Expected Behavior
------------------
namespace should be re created after the swact on the new active controller

Actual Behavior
----------------
namespace is not being re-created after the swact on teh new active controller

Reproducibility
---------------
Reproducible

System Configuration
--------------------
Duplex Bare-Metal Two node system

Branch/Pull Time/Commit
-----------------------
r-2018-.10
Network

Timestamp/Logs
--------------

[Allain Legacy (alegacy)]

The expected behavior is incorrect. Network namespaces are created and managed by Neutron agents. They are not directly affected by a controller swact. A namespace will only move from one node to a different node if the resource that created it moves to a different node.

Network namespaces are a part of the internal infrastructure needed to allow agents to have connectivity to VM instances attached to a particular tenant network. They are not intended as a means for end users to access tenant networks for the purposes of pinging or SSHing to VM instances. Networking developers, for debugging purposes, may make direct use of namespaces to test connectivity to/from various resources, but end users (and formal tests) should not make use of namespaces.

[Jose Perez Carranza (jgperezc)]

Hi Allain

If namespaces are intended for debugging process, are you able to explain us what is the correct procedure to get access via SSH from a controller/compute to a VM instance?. In our particular case that process should be used to create Automate Tests.

[Allain Legacy (alegacy)]

If you want to access VM instances from the controller (or vice-versa) then the network used to reach the controller needs to be in the same layer3 routable domain as the virtual tenant networks (either directly or via a virtual external network with or without floating IP instances). This is how it would work in an actual real-world deployment; namespaces would not be used. Customers may need to access VM instances from the controller (or from other physical nodes in their network); or vice-versa a VM instance may need to access one or more of the Openstack API endpoints and would need a routable path back to the controller IP address on the OAM network.

For example (assuming a physical controller rather than a virtualized one):

      (controller)
           |
           |
      [OAM network]
           |
           |
    (physical router)
           |
           |
[virtual external network]
           |
           |
    (virtual router)
           |
           |
[virtual tenant network]
           |
           |
     (VM instance)

In this example the "virtual external network" would need to be backed by a provider network that used a VLAN that was configured on the "physical router" and used an IP subnet that was known/configured by the physical router.

It is possible to simplify this example and to attach the "virtual tenant network" directly to the physical router but that is a more specialized usecase and more difficult to manage since it requires an admin to configure each virtual tenant network with specific VLAN provider network segments.