Add spec test for a full refresh

[skovic]

This PR adds a test case for testing a full refresh. In particular, it attempts to recreate the guest_devices table problem described in Bug 1542710.

[skovic]

@miq-bot add_label wip

[agrare]

Probably better going through a physical_server association since that name doesn't look like it'd be particularly unique

[agrare]

Not a good idea to dereference the array without sorting it first since the return order isn't guaranteed and can lead to sporadic test failures

[agrare]

Better to say something like

port_1 = ports.find_by(:device_name => "Physical Port 1")

[agrare]

@skovic commented, looks like the VCRs might have to be re-recorded? There are vcr errors in the spec tests

[skovic]

@agrare It works running it locally (with the same vcr files). I'm not sure what to make of this error. This is why it's failing:

An HTTP request has been made that VCR does not know how to handle: GET https://ip-10-243-9-123.ec2.internal/aicc

Notice the strange format of the IP address. Any idea about why this may be occurring?

[agrare]

@skovic got me my guess is that something in init_parser is doing something with the local machine's hostname, and that was the hostname of the travis appliance running the test

[agrare]

so @skovic when you said you reproduced this with only one refresh, what exactly was it that you saw? I thought the issue was that ports were getting switched between two refreshes but maybe I don't understand what the bug is exactly.

[skovic]

@agrare For example, before a refresh, a NIC may have two ports with the following names and MAC addresses:

Physical Port 1    00:0A:F7:25:67:38
Physical Port 2    00:0A:F7:25:67:39

After a refresh, the NIC now has the following two ports:

Physical Port 1    00:0A:F7:25:67:38
Physical Port 1    00:0A:F7:25:67:38

It's as if Port 2 disappeared and was replaced by a duplicate of Port 1.

[skovic]

@agrare Looks like the same issue again with the malformed IP address. Any idea how I can debug this possible init_parser problem? Thanks

[agrare]

@skovic I would step into what that connection.discover_aicc method is doing, you might have to stub it out in your spec

[skovic]

@agrare @rodneyhbrown7 Regarding the bug itself. I believe that I've figured out more precisely the conditions under which the bug occurs and what might be occurring. Here are the preconditions:

• One LXCA, lxca1, is managing a particular server, server1.
• Another LXCA, lxca2, is managing the same server, server1.

Here is how to reproduce the problem:

1. Add a physical infrastructure provider for lxca1. This is provider1.
2. Add a physical infrastructure provider for lxca2. This is provider2.
3. Refresh the second provider, provider2.
4. Once the refresh is complete, navigate to the server summary page for server1 and notice that there are duplicate entries in the Network Devices table.

When the second provider, provider2, is added, a second entry for server1 is created in the physical_servers table in the database. Likewise, a second entry is created for server1's NIC in the guest_devices table. When the second provider, provider2, is refreshed, the entries for the NIC in the guest_devices table somehow become mangled.

[rodneyhbrown7]

I have a theory about the spec test failure. This is the only spec test where we call EmsRefresh. I think EmsRefresh is attempting to create an actual ems instance instead of using the factory instance. We have code in our provider that attempts to resolve any hostname given. This way we can convert IP addresses to hostnames.

manageiq-providers-lenovo/app/models/manageiq/providers/lenovo/physical_infra_manager/refresh_parser.rb

Line 96 in e615a3e

def resolve_hostname(ipaddress, ems)

In this case I think we are asking DNS to resolve the provided host name. This is going out to Amazon's hosted DNS service and returning a private host name for the given address of the form xx-xx-xx-xx.ec.internal. When we run internally, this IP actually resolves to a valid address so we don't run into this block.

See reference: https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html

@skovic Maybe you can disable the resolver temporarily and see if that enables the test to pass?

[skovic]

@rodneyhbrown7 Thanks. Temporarily disabling resolving of hostnames let the test pass.
@agrare How should we address this issue, so the tests pass? Rodney's theory was correct.

[agrare]

@skovic what if you set the ipaddress in the FactoryGirl ems? Looks like that will shortcut the resolve code

[skovic]

@agrare I thought we were already doing that:

:ipaddress => "https://10.243.9.123:443"

[agrare]

So it will only try to resolve if one of these is true, probably if you switched the full URL to the hostname or made up a dummy hostname it won't call to resolve

if @ems.ipaddress.blank?
  resolve_ip_address(hostname, @ems)
end
if @ems.hostname_ipaddress?(hostname)
  resolve_hostname(hostname, @ems)
end

[miq-bot]

Checked commits skovic/manageiq-providers-lenovo@1d00d59~...b6997d2 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
3 files checked, 1 offense detected

**

• 💣 💥 🔥 🚒 - Linter/Yaml - missing config files

[skovic]

@agrare Looks like a dummy hostname has fixed the problem. Please let me know if you would like me to make any other changes. Thanks

[skovic]

@miq-bot remove_label wip