Connectivity check does not catch wrong interfaces configuration

[ElenaRossokhina]

Detailed bug description:
Sometimes default configuration on network interface differs from node to node, for example:
node-1, controller has enp0s5==management, enp0s6==storage
node-2, compute has enp0s5==storage, enp0s6==management

Such cluster can pass network verification before deploy and can be successfully deployed thereafter.

Steps to reproduce:
Create cluster with 2 nodes: 1 controller + 1 compute
Attach network incorrectly:
node-1, controller has enp0s5==management, enp0s6==storage
node-2, compute has enp0s5==storage, enp0s6==management
Verify network, deploy cluster

Expected results:
Network check fails, deploy fails or can not be started
Actual result:
Verify network - OK, deploy cluster - OK
NOTE: After deploy network verification fails, as expected:
Verification failed.
Repo availability verification failed on following nodes Untitled (2f:9f).
Following repos are not available - http://archive.ubuntu.com/ubuntu/, http://mirror.fuel-infra.org/mos-repos/ubuntu/9.0/.

Reproducibility:
100%

fuel-9.0-mos-427-2016-06-01_12-18-59.iso
full snapshot https://drive.google.com/open?id=0B2ag_Bf-ShtTNDNfaUk0VW16RzA

[Aleksey Kasatkin (alekseyk-ru)]

> Repo availability verification failed on following nodes Untitled (2f:9f).
> Following repos are not available - http://archive.ubuntu.com/ubuntu/, http://mirror.fuel-infra.org/mos-repos/ubuntu/9.0/.

AFAIC, it was not expected here. It's not about connectivity between nodes.

[Aleksey Kasatkin (alekseyk-ru)]

Expected results:
Network check fails, deploy fails or can not be started
Actual result:
Verify network - OK, deploy cluster - OK

As deployment is OK, your assumptions seem to be incorrect.
Probably, all those NICs are connected with one another.

[Aleksey Kasatkin (alekseyk-ru)]

From logs:

Seems, repos check was failed because node '2' did not have internet connectivity. Other two URLs (local) were OK.

Connectivity test was OK both before and after deployment. net-checker knows nothing about networks. It knows just about interfaces and VLANs. Its connectivity test checks just connectivity between interfaces with and without VLAN tags. In your case 'management' and 'storage' networks do not have VLAN tags so they are equal for net-checker connectivity test.

Looks like your environment is not operational. Did you check that?
If all those NICs are connected with one another, environment should be OK (and connectivity test should have not been failed then).

[Aleksey Kasatkin (alekseyk-ru)]

So, net-checker does not support such cases (NICs with untagged networks are connected in different order) currently. AFAIC, it is a feature request rather than a bug.

Seems, to get this done, we need to change astute and nailgun parts.
Now astute converts net-checker responses so that part of data gets lost.

response from net-checker:
   {"enp0s6"=>{"0"=>{"1"=>["enp0s6"], "2"=>["enp0s6"]}},
    "enp0s5"=>{"0"=>{"1"=>["enp0s5"], "2"=>["enp0s5"]}},
response from astute:
   [{"iface"=>"enp0s6", "vlans"=>[0]},
    {"iface"=>"enp0s5", "vlans"=>[0]},

So, nailgun cannot determine what particular interfaces have inter-connectivity. But it can be determined from the original response.
It's needed to remove this transformation from astute and analize such cases in nailgun then.