[
https://issues.apache.org/jira/browse/AURORA-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14361533#comment-14361533
]
Steve Niemitz commented on AURORA-1192:
---------------------------------------
Correct, we still use the hostname override everywhere, and have never seen
this issue since I added the flag. I wonder if there's odd behavior using an
IP address instead of a real hostname with the flag?
> Announced aurora leader information does not respect -hostname flag
> -------------------------------------------------------------------
>
> Key: AURORA-1192
> URL: https://issues.apache.org/jira/browse/AURORA-1192
> Project: Aurora
> Issue Type: Bug
> Components: Scheduler
> Affects Versions: 0.7.0
> Environment: CentOS 7 x64, AWS
> Reporter: Will Farrington
>
> Our aurora-schedulers are configured to use the primary IP address of the
> host they run on with the {{-hostname}} flag.
> The announced serverset in zookeeper continues to use the local hostname.
> Here is an example of a {{get /aurora/scheduler/member_ID}} from ZK:
> {code}
> {"serviceEndpoint":{"host":"ip-172-18-60-156","port":8081},"additionalEndpoints":{"http":{"host":"ip-172-18-60-156","port":8081}},"status":"ALIVE"}
> {code}
> In this particular instance, the hostname doesn't resolve, resulting in the
> aurora-client being unable to talk to the aurora-scheduler, since the
> aurora-client is taking the host key out of the service endpoint.
> As best I can tell, this is the only spot where the supplied {{-hostname}}
> flag isn't utilized.
> The singleton candidate znodes in ZK however contain the hostname as supplied
> by the {{-hostname}} flag, as expected. Example {{get
> /aurora/scheduler/singleton_candidate_0000000018}}
> {code}
> 172.18.39.100
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
