cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Vazquez (JIRA)" <>
Subject [jira] [Created] (CLOUDSTACK-9470) [BLOCKER] Fix for test_network_acl, SshHelper
Date Wed, 24 Aug 2016 12:32:20 GMT
Nicolas Vazquez created CLOUDSTACK-9470:

             Summary: [BLOCKER] Fix for test_network_acl, SshHelper
                 Key: CLOUDSTACK-9470
             Project: CloudStack
          Issue Type: Improvement
      Security Level: Public (Anyone can view this level - this is the default.)
          Components: VMware
    Affects Versions: 4.10.0
            Reporter: Nicolas Vazquez
            Assignee: Nicolas Vazquez
             Fix For: 4.10.0

h2. Problem
In a Vmware environment, running {{test_network_acl}} we examined why sometimes it failed
and sometimes it passed. It was discovered that issue was on {{VmwareResource}}:

private int findRouterEthDeviceIndex(String domrName, String routerIp, String mac) throws
Exception {
        VmwareManager mgr = getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);"findRouterEthDeviceIndex. mac: " + mac);

        // TODO : this is a temporary very inefficient solution, will refactor it later
        Pair<Boolean, String> result = SshHelper.sshExecute(routerIp, DefaultDomRSshPort,
"root", mgr.getSystemVMKeyFile(), null, "ls /proc/sys/net/ipv4/conf");

Command sent to router returned a pair which its first parameter was always true but second
parameter sometimes it was null and sometimes the correct output for given command.

h2. Solution
Examining {{SshHelper}} we discovered that cases in which second parameter in result was null,
didn't consume stdout properly

This message was sent by Atlassian JIRA

View raw message