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

Unexpected cluster state for single node config #2557

Closed
gesellix opened this issue Feb 15, 2020 · 7 comments · Fixed by #2581
Closed

Unexpected cluster state for single node config #2557

gesellix opened this issue Feb 15, 2020 · 7 comments · Fixed by #2581

Comments

@gesellix
Copy link

gesellix commented Feb 15, 2020

Description

With CouchDB 3.x (#2296) we have the option to setup a node as "single node" via config setting. I expected this to have the same effect like using the Fauxton cluster setup UI from CouchDB 2.x.

Using the new config setting we get the following cluster state at /_cluster_setup:

{"state":"cluster_finished"}

When using the Fauxton based single node setup, the /_cluster_setup endpoint returns:

{"state":"single_node_enabled"}

Steps to Reproduce

git clone https://github.com/apache/couchdb-docker
cd couchdb-docker/
echo -e "\n[couchdb]\nsingle_node = true\n" >> dev/local.ini 
docker build -t couchdb:3 dev
docker run --rm -it --env COUCHDB_USER=admin --env COUCHDB_PASSWORD=password -p 5984:5984 couchdb:3
curl --user admin:password -X GET "https://localhost:5984/_cluster_setup" 

Expected Behaviour

GET /_cluster_setup should return single_node_enabled when the new couchdb.single_node=true setting has been used.

Your Environment

  • CouchDB version used: CouchDB/3.0.0-8748310 (Erlang OTP/21)
  • Operating system and version: Docker image based on docker-couchdb (docker build -t couchdb:3 dev)
@janl
Copy link
Member

janl commented Feb 19, 2020

Good find! Agreed that this is a little confusing. CouchDB internals don’t really care about cluster vs. single node. A single node just happens to be a cluster of one, hence the confusion. The introduction of the new setting requires one more clause in this function:

handle_setup_req(#httpd{method='GET'}=Req) ->
ok = chttpd:verify_is_server_admin(Req),
Dbs = chttpd:qs_json_value(Req, "ensure_dbs_exist", setup:cluster_system_dbs()),
couch_log:notice("Dbs: ~p~n", [Dbs]),
case erlang:list_to_integer(config:get("cluster", "n", undefined)) of
1 ->
case setup:is_single_node_enabled(Dbs) of
false ->
chttpd:send_json(Req, 200, {[{state, single_node_disabled}]});
true ->
chttpd:send_json(Req, 200, {[{state, single_node_enabled}]})
end;
_ ->
case setup:is_cluster_enabled() of
false ->
chttpd:send_json(Req, 200, {[{state, cluster_disabled}]});
true ->
case setup:has_cluster_system_dbs(Dbs) of
false ->
chttpd:send_json(Req, 200, {[{state, cluster_enabled}]});
true ->
chttpd:send_json(Req, 200, {[{state, cluster_finished}]})
end
end
end;

It should be easy enough to add, using config:get_boolean() like here

case config:get_boolean("couchdb", "single_node", false) of

@gesellix wanna try a PR?

@gesellix
Copy link
Author

wanna try a PR?

Oh yes, the code pointers help a lot. I'll try!

@gesellix
Copy link
Author

Fixed with #2574 - thx @janl!

@gesellix gesellix reopened this Feb 19, 2020
@gesellix
Copy link
Author

Not sure if #2574 fixes this issue.

@janl can you confirm that is_single_node_enabled will be called in case of a single_node-configured instance?

I think that it won't be called, because GET /_node/_local/_config yields cluster.n = 3 for me. is_single_node_enabled will only be called in case of cluster.n = 1.

@janl
Copy link
Member

janl commented Feb 19, 2020

Ah shoot, you're right! Cc @wohali

This was referenced Feb 19, 2020
@janl
Copy link
Member

janl commented Feb 19, 2020

Thanks @gesellix

@gesellix
Copy link
Author

🙏 you're welcome

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment