[
https://issues.apache.org/jira/browse/AMBARI-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumit Mohanty updated AMBARI-2277:
----------------------------------
Description:
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.
was:
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.
> 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
> Fix For: 1.2.5
>
>
> 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
