I upgraded to 1.0.1 recently and have been deploying new stacks and getting the new name format (r-stack_service_cintainer_count). But recently it started using the old UUID style names again. Why would that happen?
I’ve tried going to the Rancher server but it is really hard to find anything useful in logs with DEBUG level already enabled. The only thing I can think of that may have changed is the rancher-compose binary on one of the deployment nodes. Would rancher-compose be a dependency of the naming?
I’ve just done a manual upgrade of a service in the UI and the same behavior happened. So, it doesn’t appear to be related to rancher-compose at least. It seems that an upgrade goes back to the old naming convention.
I am seeing the same behavior and it appears to be a bit random. I have my hostname set to be the container name and when I do an upgrade about half the time the hostname picks up the container name and the other is the old style UUID. This creates a big issue for log management as I have filters set on hostnames. When I get the bad hostname I just keep running the upgrade and it will eventually fix itself.
I am also running rancher 1.0.1
I think what’s happening is that container names have to be unique, so if there is already one with that name on that host it gets assigned a UUID one.
Hello Vincent,
I looked into it a little more and that is exactly what is happening. The hostname within the container is being set correctly, but if the name is already set on the docker host then the UUID is assigned and that is what is being used in the logs. Just out of curiosity, why would rancher not increment the number so the name would work? For example, if I have a service called passenger it would go from r-myservice-passenger_1 to r-myservice-passenger_2? Does Rancher have any recommendations on how to get around this issue when doing an upgrade?
Is there a bug filed for this already? I’d love to get this fixed before 1.1. I’m trying to create logging queries for services based on container names and was hoping to be able to do this in 1.0.1 but can’t not that the names go away after a deploy.
@andyshinn I don’t believe there is an open bug for this.
Can you make one for it? Unfortunately, I can’t guarantee that it will make it into 1.1, but I can have engineering look at it.
I wonder if a workaround would be to stop the containers before upgrade instead of starting new ones then stopping old ones?
The linked GitHub issue is at https://github.com/rancher/rancher/issues/4993.