Mailing-List: contact ambari-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ambari-dev@incubator.apache.org
Date: Fri, 6 Sep 2013 18:03:52 +0000 (UTC)
From: "Sumit Mohanty (JIRA)" <jira@apache.org>
To: ambari-dev@incubator.apache.org
Message-ID: <JIRA.12650938.1370366900538.93108.1378490632894@arcas>
In-Reply-To: <JIRA.12650938.1370366900538@arcas>
References: <JIRA.12650938.1370366900538@arcas>
Subject: [jira] [Updated] (AMBARI-2277) Improve host checking on
 registration
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/AMBARI-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sumit Mohanty updated AMBARI-2277:
----------------------------------

    Assignee: Sumit Mohanty
    
> Improve host checking on registration
> -------------------------------------
>
>                 Key: AMBARI-2277
>                 URL: https://issues.apache.org/jira/browse/AMBARI-2277
>             Project: Ambari
>          Issue Type: Bug
>          Components: controller
>    Affects Versions: 1.2.4
>            Reporter: Sumit Mohanty
>            Assignee: Sumit Mohanty
>             Fix For: 1.4.1
>
>
> Host registration commonly fails on two scenarios:
> 1) Agent machine can't make it back to Server (results in failed host register because Server never sees host register)
> 2) Agent machine registers with Server under a _different_ hostname than Server expected (results in failed register because Server thinks host never registered)
> Need to consider how to make these scenarios 1) easier to troubleshoot 2) more clear to the user 3) provide paths out of this situation (warn, retry, remove)
> One limiting factor we have during registration currently is that we are assuming a hostname matches up. One (possible) way to alleviate this can be to provide a context, which can be any random string, that we send to the host which is returned during the registration call. If we can somehow match the context with what the host provides, we can then offer some meaningful warnings if there is a hostname mismatch.
> We would have to do this BEFORE saving the hostname in the database.
> Such a mechanism cannot block registration because, for example, we offer custom host name scripts from the agent. In that case, either a) the hostnames will match up anyway because registration is manual at that point or b) the user knows what he's doing and can just skip past it.
> FE should consider reporting the unmatched host names along with hosts that failed to register. This will make it easy to debug the issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira