[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776735#comment-13776735
 ] 

Alena Prokharchyk commented on CLOUDSTACK-3128:
-----------------------------------------------

As an example, you can look at createVirtualMachine call in UserVmManager.

1) NetworkNicMap is created. Note that it doesn't have to be linkedhashMap (I 
will explain why in #3 and #4)

LinkedHashMap<String, NicProfile> networkNicMap = new LinkedHashMap<String, 
NicProfile>();

2) Then we iterate through all the networks passed to the call, in order to 
build/populate nic profiles:

 for (NetworkVO network : networkList) {
.................

3) When nicprofile is being built, the defaultNic attribute is being set for 
the first network from the networkList:

 if (defaultNetworkNumber == 0) {
                defaultNetworkNumber++;
                // if user requested specific ip for default network, add it
                if (defaultIps.getIp4Address() != null || 
defaultIps.getIp6Address() != null) {
                    _networkModel.checkRequestedIpAddresses(network.getId(), 
defaultIps.getIp4Address(), defaultIps.getIp6Address());
                    profile = new NicProfile(defaultIps.getIp4Address(), 
defaultIps.getIp6Address());
                }

                profile.setDefaultNic(true);
            }


4) The underlying code will always read the defaultNic information from the 
NicProfile instead of relying on the order.


I agree that it takes time to track it down, and that it would have been much 
more clear if UserVmServices interface explicitly accepted Pair<Long networkId, 
Boolean isDefault> parameter instead of using List<Long> one and making the 
decision to rely on the network order to figure out the default network. This 
way it would be more evident for the developer using the code, where the 
network order is coming from. This is the enhancement that can be done later on 
as the current code still respects the networks order.
                
> deployVm does not guearentee network interface order inside VM when called 
> with ipToNetwork list parameter
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-3128
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3128
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>          Components: Management Server
>    Affects Versions: 4.2.0
>            Reporter: Alena Prokharchyk
>            Assignee: Alena Prokharchyk
>             Fix For: 4.2.0
>
>
> When deployVm is called with networkIds parameter, the nics will be created 
> in the Vm with the order defined by networkId parameter. 
> But when ipToNetworkList parameter is passed, the order the map is presented 
> in this param, is not the order the nics are created on the Vm.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to