Default node name has changed between CouchDB 3.3.2 and 3.42

[doctor-claw]

I have recently attempted to upgrade an existing 3.3.2 installation to 3.4.2 on Windows 10.

The upgrade appeared successful, but Fauxton showed "database failed to load" for all my databases.

Upon inspecting etc/vm.args and comparing with another PC running 3.3.2, I noticed that 3.4.2 had changed the node name to

-name [email protected]

I changed it to couchdb@localhost and then could no longer log in to Fauxton (incorrect credentials, although I was definitely using the same username and password!).

Reinstalling 3.4.2 and setting my original admin user and password did not help as part of the installer did not help. Editing local.ini to set my admin password did not work either:

[admins]
admin = <my password>

I'm now in the process of rolling back to 3.3.2 and reinstating my databases, but I can confirm that a completely fresh install of 3.4.2 has -name [email protected] while a completely fresh install of 3.3.2 -name couchdb@localhost.

Having had no problems upgrading from 3.2.2 in the past, and also checking an older machine with 3.2.2 on it having localhost as the node name, I would suspect it has been localhost for some time on 3.x

I noted that the following wiki page indicated the change from localhost to 127.0.0.1 for 2.x to 2.1.1 but:

a) this is not mentioned when upgrading to 3.4.x
https://docs.couchdb.org/en/stable/whatsnew/3.4.html

b) why did it go from 127.0.0.1 in 2.1.1 back to localhost in 3.2.x/3.3.x and now back to 127.0.0.1 again in 3.4.x?

https://docs.couchdb.org/en/latest/whatsnew/2.1.html#upgrade-notes

[rnewson]

The default in configure.ps1 changed in #4678 but this should not have caused a change to any existing installation during an upgrade. I suspect this is an issue in the Windows packaging scripts. For contrast the Debian packages mark vm.args as a conffile and take care not to alter node_name and other parameters from their current values on an upgrade.

Thank you for your report.

[rnewson]

Did you happen to uninstall and then reinstall? We think this would cause vm.args to be removed and then replaced with the new settings.

[doctor-claw]

I did uninstall (through Windows control panel) and reinstall, yes.

The 3.4.2 installer would not let me install without uninstalling 3.3.2 first:

[big-r81]

So if you didn't changed something in vm.args, this file gets removed during uninstall. With the new version installed, you get the new vm.args file with to current settings for the node name.

[doctor-claw]

Thanks for the explanation!

I now understand why it's happened, what would be the correct mitigation?

Change something inconsequential in the vm.args file to prevent its removal on uninstall to preserve the default -name couchdb@localhost from 3.3.2 (and thus retain access to pre-existing databases)?

[big-r81]

Change something inconsequential in the vm.args file to prevent its removal on uninstall to preserve the default -name couchdb@localhost from 3.3.2 (and thus retain access to pre-existing databases)?

That should work, if the file is edited, then it shouldn't get removed during uninstall and it shouldn't get overwritten if you install the new CouchDB version. You then have to compare the settings between vm.args(your old file) and vm.args.dist(new defaults of this CouchDB version) by yourself, maybe some Erlang or other settings changed.

[doctor-claw]

May I also suggest the "what's new" documentation is updated to highlight the couchdb@localhost vs [email protected] change in 3.4.x? Might help someone else avoid upgrade issues! :-)