Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Windows: upgrade from 3.5.4 -> 3.7.4 can fail due to computed node name case differences #1568
I do experience migration issues from 3.5.4 to 3.7.4 on windows environment.
How to reproduce
in the default case, rabbitmq will generate rabbit@COMPUTERNAME (all in uppercase)
And here rabbitmq generates rabbit@hostname where hostname has the same value as cmd hostname
How to reproduce with windows docker containers
DockerHub images are built from this repository: https://github.com/gsx-solutions/rmq-win
Then you can just use -h RMQ to make it working.
Thank you for your work and support.
Thank you for your time.
Team RabbitMQ uses GitHub issues for specific actionable items engineers can work on. GitHub issues are not used for questions, investigations, root cause analysis, discussions of potential issues, etc (as defined by this team).
We get at least a dozen of questions through various venues every single day, often light on details.
Please post this to rabbitmq-users.
Cluster upgrade from 3.5.x to 3.7.x will require a cluster-wide shutdown with an ordered restart, as the docs explain. Or you can do a Blue/Green deployment upgrade.
Sorry but there is no evidence of a bug. This is mailing list material at this point.
I now see you have a section about case sensitivity of node names. This is a never ending source of fun on Windows and keeping track what was done by default in what version from years ago is not realistic. Setting
I suspect that other operating systems which tend to use case-insensitive filesystems are not affected.
referenced this issue
Mar 29, 2018
@Bhaal22 we have Windows package tests but not upgrades on Windows. I filed a documentation guides issue and this will be covered. I'm not sure we can safely force a particular case assuming there are years worth of releases that do not do that.
Perhaps we can emit a warning of some kind when
Scenarios where hostnames have changed are operator's responsibility. Explicitly setting
the issue I see with this is:
then the file nodes_running_at_shutdown is updated like if it was a cluster with 2 members
Yeah I understand
We recognise that it is not ideal and can be very confusing. Thank you for getting to the bottom of it.
If @lukebakken has ideas about what kind of change would be reasonably safe here, we'd be happy to file another issue and consider it.
We can modify the list loaded from
This is a yet another argument for Blue/Green deployment upgrades, which our docs don't promote enough.