Scenario:
With SF 6.1.456, no issue, upgraded this morning to 6.2 and getting the following error:pub
FinishActivateContainer: replyBody.Error=FABRIC_E_INVALID_OPERATION, replyBody.ErrorMessage=System.Fabric.FabricException (-2147017731)
Container image download failed for ImageName=microsoft/dynamics-server:latest. DockerRequest returned StatusCode=NotFound with ResponseBody=.Please check if image is present in repository or repository credentials provided are correct..
A docker images shows:
PS C:\src\Nav\Platform\Fabric> docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
microsoft/dynamics-server latest 9865aaf0c1f5 29 minutes ago 15.5GB
Reverting to 6.1 fixed immediately the issue.
It seems that service fabric now always tries to do a "docker pull microsoft/dynamics-server", whereas 6.1 if the image was available locally was just using it.
@harahma @tugup do you know of any behaviour change ?
Can you share your ServiceManifest.xml
The behavior in 6.2 has been changed to require explicitly specifying container image tag. In ServiceManifest you need to explicitly specify a tag for container image. When no tag is specified, SF assumes latest and tries to pull from repository.
Just to add, you should do imageName:latest in ServiceManifest. Also, it is not recommended to use latest because then you don't know which version you are upgrading to.
In TIE and PROD we are always using specific build number, it's only for local devbox development that we don't really want to change version of container everytime we rebuild it (and update the parameter etc...).
So what should be the workaround? Should we create a "dev" tag or something like that to prevent SF 6.2 to try to pull the container image?
Please re-open if you are still facing this issue, but closing at this time.
Most helpful comment
In TIE and PROD we are always using specific build number, it's only for local devbox development that we don't really want to change version of container everytime we rebuild it (and update the parameter etc...).
So what should be the workaround? Should we create a "dev" tag or something like that to prevent SF 6.2 to try to pull the container image?