configuration: fix configure scheme

[mrkz]

Both compute_net and mgmt_net can only represent one
subnet. This commit changes the configure scheme for
compute_net and mgmt_net to accept a list of subnets.

both values should be now a YAML list of subnets like:

  launcher:
    compute_net: [192.168.1.110]
    mgmt_net: [192.168.1.0/24, 192.168.2.0/24]

or

  launcher:
    compute_net:
      - 192.168.1.110
    mgmt_net:
      - 192.168.1.0/24
      - 192.168.2.0/24

Fixes #232

Signed-off-by: Simental Magana, Marcos [email protected]

[mrkz]

missing code coverage, created early PR for reviewing purposes

[coveralls]

Coverage increased (+0.007%) to 64.714% when pulling 2f83fe8 on mrkz:fix_conf_scheme into dd98c89 on 01org:master.

[mrkz]

There's a duplicated function ( equalNetSlice(slice1, slice2 []string) bool ) which is duplicated in payloads/configure_test.go and configuration/configuration_test.go as it wasn't clear enough where this could be placed to be used in both places, any suggestion here would be appreciated.

[mrkz]

Also, please notice that by the nature of the Issue (#232) this PR fixes, the YAML schema is changed; some data which was previously a YAML string type will be now a YAML list type, breaking previous CIAO clusters setup, in order to fix it, both compute_net and mgmt_net values in yaml should be changed into a list format. e.g:

• Previous PR format:

  launcher:
    compute_net: 192.168.1.110
    mgmt_net: 192.168.1.0/24

• New PR format:

  launcher:
    compute_net:
    -  192.168.1.110
    mgmt_net:
    -  192.168.1.0/24

[sameo]

@mrkz So you want to compare if the 2 subnets slices are equal, right ?
2 options here:

1. The order of the subnets matters, i.e [a, b] != [b, a] for us. In which case you can simply call reflect.DeepEqual(slice1, slice2)
2. The order of the subnets does not matter, i.e. [a, b] and [b, a] are equivalent for us. In that case you can sort and copy the 2 slices and then call reflect.DeepEqual(sortedSlice1, sortedSlice2).

@mcastelino When building the mgmt and compute list of subnets for NetworkConfig, does the order of the subnets matter ?

[mrkz]

@sameo so I sorted those slices to be able to compare slices element by element, will take a look at this approach. For other matters, I don't know if slices should be sorted or not, that's why I create copies of them and work with those copies instead of modifying the ones read from the configuration.

Other issue I have is having this func equalNetSlice function duplicated, any hint on where I could drop this in order to avoid code duplication?

[mcastelino]

@sameo the order of the subnets does not really matter. We scan all the network interfaces and see if they belong to one or more of the subnets. To run traffic we choose the first network interface that matched any of the subnets.

You do not need to check for overlaps. All you need to do is ensure they are valid CIDR subnets.

So the interface discovery order matters (not the subnet order).

[sameo]

@mrkz So we're in case #2, where order does not matter. I think you can order them without copying, remove duplicates and then call reflect.DeepEqual(slice1, slice2) on them.

Since this really is a subnet comparison routine, it probably makes sense to have it exported from libsnnet.

[coveralls]

Coverage decreased (-0.09%) to 65.265% when pulling 3f90027 on mrkz:fix_conf_scheme into 56930ea on 01org:master.

[coveralls]

Coverage decreased (-0.07%) to 65.356% when pulling dcc21dc on mrkz:fix_conf_scheme into 981bb66 on 01org:master.

[sameo]

return false

[coveralls]

Coverage decreased (-0.02%) to 65.439% when pulling db86e63 on mrkz:fix_conf_scheme into d6cef89 on 01org:master.

[coveralls]

Coverage increased (+0.1%) to 65.561% when pulling c49e3af on mrkz:fix_conf_scheme into d6cef89 on 01org:master.