at 6:57 AM, Bobby Evans ev...@yahoo-inc.com wrote:
But that does present a problem if you have to change the DNS address of
one of the HA namenodes.
Not sure what you mean by this? Do you mean hostname of one of the
namenode
changes?
If so, why is this is not a problem for single namenode
But that does present a problem if you have to change the DNS address of
one of the HA namenodes. It forces you to update the config on all other
clusters that want to talk to it. If you only have a few clusters that is
probably not a big deal, but it can be problematic if you have many
I ran some basic sanity tests and it seems OK to me.
+1
On 10/7/13 2:00 AM, Arun C Murthy a...@hortonworks.com wrote:
Folks,
I've created a release candidate (rc0) for hadoop-2.2.0 that I would like
to get released - this release fixes a small number of bugs and some
protocol/api issues which
I am not sure what you mean by some portion of source code of Hadoop.
Because you are running on a fully distributed environment you need to
make sure that eclipse is attached to the correct process. If you are
trying to debug the data upload pipeline then you need to be sure that
eclipse is
Putting all conspiracy theories aside :). Any way we decided to scale the
name node is going to have limitations. Federation currently has the
problem that we cannot easily move data between different name nodes. It
is a static partitioning. It is not a blocker, but it can be annoying. We
can
I think it would be awesome to make this happen. I am +1 for the general
direction. I am by no means an HDFS expert but I would like to see the
patches you have made. If you could file a JIRA that points to the
modifications on github or in patches and any design work you have
explaining it
