Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Consul clients to join cluster #61

Closed
jrgarcia opened this issue Jan 9, 2015 · 3 comments
Closed

Allow Consul clients to join cluster #61

jrgarcia opened this issue Jan 9, 2015 · 3 comments

Comments

@jrgarcia
Copy link

jrgarcia commented Jan 9, 2015

It appears that consul agents running as clients are unable to join the cluster because of the check here. When I configure the agent as a client (server => false), consul info does not output num_peers so the linked check returns 1.

Example configuration:

class { 'consul':
  join_cluster => '172.16.78.100',
  config_hash => {
    'datacenter' => 'dc1',
    'data_dir'   => '/opt/consul',
    'server'     => false,
  }
}

Client output of consul info:

agent:
        check_monitors = 0
        check_ttls = 0
        checks = 0
        services = 0
build:
        prerelease =
        revision =
        version = 0.4.1
consul:
        known_servers = 0
        server = false
runtime:
        arch = amd64
        cpu_count = 1
        goroutines = 32
        max_procs = 2
        os = linux
        version = go1.3.1
serf_lan:
        event_queue = 0
        event_time = 1
        failed = 0
        intent_queue = 0
        left = 0
        member_time = 1
        members = 1
        query_queue = 0
        query_time = 1

Server output of consul info:

agent:
        check_monitors = 0
        check_ttls = 0
        checks = 0
        services = 1
build:
        prerelease =
        revision =
        version = 0.4.1
consul:
        bootstrap = false
        known_datacenters = 1
        leader = false
        server = true
raft:
        applied_index = 0
        commit_index = 0
        fsm_pending = 0
        last_contact = never
        last_log_index = 0
        last_log_term = 0
        last_snapshot_index = 0
        last_snapshot_term = 0
        num_peers = 0
        state = Follower
        term = 0
runtime:
        arch = amd64
        cpu_count = 1
        goroutines = 52
        max_procs = 2
        os = linux
        version = go1.3.1
serf_lan:
        event_queue = 0
        event_time = 1
        failed = 0
        intent_queue = 0
        left = 0
        member_time = 7
        members = 3
        query_queue = 0
        query_time = 1
serf_wan:
        event_queue = 0
        event_time = 1
        failed = 0
        intent_queue = 0
        left = 0
        member_time = 1
        members = 1
        query_queue = 0
        query_time = 1
@solarkennedy
Copy link
Contributor

Crap, this is the same as #31.

@EvanKrall didn't we agree that this is impossible and we should just leave this up to the admin to do?

@jrgarcia
Copy link
Author

@solarkennedy That would be my preference. It's obviously easy to workaround. I just wasn't sure if this was the desired behavior.

@solarkennedy
Copy link
Contributor

I don't know what happened. I swear I removed this functionality was removed. I am going to remove it for real to prevent future people from encountering this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants