Cumulus Support

@mcrossley this is a very very minor bug but version 3 (build 3283) shows a version 4 build number at the bottom (Cumulus MX 4.1.1 b4025).

It's no biggie, I imagine many won't notice it, I'm just keeping v3 available as one of the Docker container builds and it confuses the heck out of me when I'm testing that container and think I've pushed the wrong update.

In addition to running current CMX v4, I also run one instance of v3.28.6 b3283 and it shows the correct version and build number at the bottom footer of all the local Dashboard pages. So I don't have the wrong version number in my v3.

Enjoy,
Paul

Are you looking at the public (blue pages) or the admin (black pages) side of things? I see the correct build on the public side but it's incorrect on the admin side.

Both public and admin use the same source for the version data. You've probably got some caching happening.

Caching is unlikely as these containers are destroyed and created from scratch during testing. If I spin up a new container on a new VM it’s still incorrect.

If no-one else is seeing this I’m happy to chalk it up to something in the container and troubleshoot that.

Do you know happen to know where the build number is pulled from?

Webtag #build or it is probably in the .json file.

The numbers are hardcoded in the executable, and made available via webtags which are accessed via the tag API. This is how the admin and public pages get the data. Are you possibly using the wrong executable?

Thanks. The executable shouldn’t be an issue. V3 uses mono to run the exe, v4 uses dotnet and a DLL. They wont run if you invoke the wrong executable.

It also wouldn’t explain why the public is correct and admin is not. I’m not quite sure how it’s managed to pull 2 different build numbers if it’s using the same source for the build number…

It is using the same source - single source of truth.
Yes you're definitely not using the wrong executable - I quite forgot the mono/dotnet change
It does sound like something specific to your environment.

It does sound like a browser caching issue.

Closing the loop, in case anyone is interested. It took a while, but I think I figured it out. As I mentioned earlier, it's not a browser caching issue.

The issue is to do with running both v3 and v4 side-by-side on one host. The test scripts I'm using spin up both v3 & v4 containers (which is why it also happened on a completely new host) and the problem appears to be with the way Docker maps ports from external networks to its internal networks.

Docker defines a port in the Dockerfile for each container, but you can map that to a different external port when you run the container. Effectively it's port forwarding between your local network and Docker's internal network. When the containers start I think the port mapping is pointing at the first container that spins up (usually v4 because it's smaller) rather than adhering to the mappings that were defined because they both share the same internal port.

I'll chalk it up to another Docker oddity and now I know for future testing.