Re: [Bigdata-developers] NicUtil

[Brian M. <btm...@gm...>]

On Thu, Jul 15, 2010 at 6:22 PM, Bryan Thompson <br...@sy...> wrote:

Could you please update NicUtil and the build.xml file to parameterize them
> for the ethernet interface?  That value is currently a hardwired in NicUtil
> to "eth0".


Um, where do you see eth0 "hardwired" in NicUtil?

The only place where eht0 is mentioned in that class is
in one of the versions of the getInetAddress convenience
method; the version that allows one to pass in a Configuration,
and then defaults to eth0 if the given Configuration does
not specify an entry with the given entry name. Additionally,
as far as I can tell, that version of getInetAddress is never
called anywhere in the Bigdata code.

So it's not clear to me why you would characterize eth0 as
"hardwired".

 I would like to see if I can get the federation to stand up on on a Windows
> Server machine by specifying the appropriate Ethernet interface in
> build.properties (I finally tracked down which interface is used by the
> Windows 2008 Server (eth3 in this specific case)).
>

When you say "get the federation to stand up on a Windows Server machine",
do you mean "use bigdataCluser(16).config/bigdataStandalone.config in
combination with 'bigdata start' to start the appropriate services", or do
you
mean "run the tests on the Windows box using build.xml"?

Although I would generally have guessed that "stand up a federation"
refers to the former, the fact that you initially requested that "build.xml
be updated" makes me think that maybe you mean the latter.

If the former, I'm not sure what sort of "parameterization updates" you
think need to be made to NicUtil that would help you in that case;
especially given that bigdataCluser(16).config/bigdataStandalone.config
currently do not use NicUtil, but specify explicit IP addresses instead.

On the other hand, if it's the latter -- that is, if you want to run the
tests
on Windows -- then I'm still not sure what you mean by "parameterization
updates"
of either NicUtil or build.xml. Are you asking that a system property be
set when the junit target is executed that specifies the network interface
on which to export the services? Or something else?

If you are asking for a new system property in build.xml, then I'm still
not sure what this has to do with NicUtil. I believe such a system property
would affect only the test config files, not NicUtil. There are about five
test related config files that use eth0 as the network interface name, but
all but one of them fall back to local host if eth0 does not exist on the
system. The one config file that doen't fallback to local host may be
a bug; I'll have to look into it.


> I wonder if we could find an "appropriate" default interface by testing all
> interfaces reported by NicUtil.getNetworkInterfaceArray("all") until we find
> one for which an IP address is returned by NicUtil.getIPAddress.  Would that
> make any sense?
>

It might make sense, yes; especially in a development -- rather than
deployment
scenario. In a deployment scenario, although I could imagine that there may
be some deployment scenarios where one doesn't care what interface(s) their
network traffic is sent over, it's been my experience that that is typically
not
the case. So I would generally expect that one would want to explicitly
specify the network interface names in a real deployment, and fail fast if
one or more of the expected/specified interfaces are not available.

So I think your suggestion for adding a method that walks through
the network interfaces and returns an appropriate default IP may
be a useful convenience for development scenarios, but I'm still
not sure where the requested "parameterization" of NicUtil and
build.xml fits in with this suggestion.

With respect to deployment scenarios though, I caution anyone
who may be contemplating relaying on such a default mechanism
in their own real deployments; as I can assure you that we certainly
won't be deploying bigdata with default network interfaces.

Anyway, once I get a better sense of the problem, I'll start
investigating what sort of changes can/should be made.

BrianM