Stitching slivers /etc/hosts entries incorrect for remote nodes

[lnevers@bbn.com]

Writing a ticket to track issue found in testing that will impact experimenters. The /etc/hosts entries for remote nodes may no longer be added. Also current entries are incorrect. Email exchange follows:

On 6/28/13 10:24 AM, Luisa Nevers wrote:

I am still seeing the problem in /etc/hosts where the host name for the remote is associated with the wrong IP address. This is gets in the way for me running some scripts. I just set up a sliver named "pg-utah-ig-utah" with 1 VM@ PG Utah and 1 VM @ IG Utah. The nodes allocated are:

• ​lnevers@pc5.utah.geniracks.net port 32058 - hostname client
• ​lnevers@pc403.emulab.net port 35386 - hostname server

The addresses requested are:

• 10.22.4.1 for node "server"
• 10.22.4.2 for node "client"

The /etc/hosts on the node "server":

 [lnevers@server ~]$ more /etc/hosts
 127.0.0.1    localhost loghost localhost.pg-utah-ig-utah.ch-geni-net.emulab.net
 10.22.4.1    server-link server-0 server
 10.10.1.2    client-link client-0 client 

The /etc/hosts on the node "client":

 [lnevers@client ~]$ more /etc/hosts
 127.0.0.1    localhost loghost localhost.pg-utah-ig-utah.ch-geni-net.utah.geniracks.net
 10.10.1.1    server-link server-0 server
 10.22.4.2    client-link client-0 client

On 6/28/13 10:34 AM, Jonathon Duerig wrote:

This may be a tweak we could make, but I'm not sure how far we should go in this direction. In general, where stitching is concerned, no AM will have a view of th entire experimental topology. Given that, they will not be able to generate a hosts file that is really reliable for anything but local nodes.

The real solution (which would take a good deal more effort) is to do what the actual Internet does for federation and set up a name service using the DNS protocol.

On 6/28/13 11:04 AM, Aaron Helsinger wrote:

It looks like your code determines the client_ids that are connected to the node? Is it that much of a step to also look at the definition of those nodes (if it is in the same request RSpec) and see if IP addresses are specified?

If you don't find IP addresses specified and can't find the right address, then I would think it would be better to not put incorrect entries in the /etc/hosts file. Wrong entries is worse than no entries.

[lnevers@bbn.com]

A fix for this problem was tested at PG Utah and it has corrected the host entries for the remote host.

Capturing email exchanges that lead to resolution of this ticket:

On 7/1/13 9:24 AM, Leigh Stoller wrote:

> It looks like your code determines the client_ids that are connected to
> the node? Is it that much of a step to also look at the definition of
> those nodes (if it is in the same request RSpec) and see if IP addresses
> are specified?

Right, we can do this pretty easily. I will add it today for you to test.

> If you don't find IP addresses specified and can't find the right
> address, then I would think it would be better to not put incorrect
> entries in the /etc/hosts file. Wrong entries is worse than no entries.

So if we don't find a local IP we can arrange for there to be nothing in
the hosts file. We can do that as a server side change, but not sure when
we can get to it.

The second case is a little trickier since the hosts file is generated on
the client side and I am not sure if the client side code will be okay with
a link definition that has just one side. 

On 7/1/13 12:18 PM, Leigh Stoller wrote:

>> It looks like your code determines the client_ids that are connected to 
>> the node? Is it that much of a step to also look at the definition of 
>> those nodes (if it is in the same request RSpec) and see if IP addresses 
>> are specified? 
>>
> Right, we can do this pretty easily. I will add it today for you to test. 

So I installed this change on Utah Emulab. Can you test it there or
would you like it installed on Utah IG instead?