Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: e2e tests which use RBD server image fail with What you expected to happen: These tests succeed. How to reproduce it (as minimally and precisely as possible): Run e2e tests which use RBD server image. Anything else we need to know?: /sig storage This issue is introduced by below commit: It change the base image from fedora 26 to fedora 28. In fedora 26, hostname command is installed as a dependency for  However, in fedora 28, it is not installed, as a result, this issue happens due to lack of hostname command. Environment: Kubernetes version (use ): k8s 1.12 alpha
Please see the difference of the behaviour between fedora 26 and 28. [Fedora26] [Fedora28]
Could you help solving this issue? I assume the fix for the code would be as below, but I'm not familiar with the build and push process for the test image. ( in doesn't work.) So, I need your help to make further progress.
(or) Both need to be run from directory
Thank you for letting me know it. It should be s/all-containers/all-container/, but it seems to work. I will test with above patch and above build commands, then make a PR, once I confirm that it works well.
sorry typing from memory :)
I need to ask you two more things: Do we need to increment the version for this image, like 1.0.1, even for this small change? (I guess that and test/images/volume/rbd/VERSION will need to be updated in this case.) How the image push process will be? Does it pushed by CI, if there are a change in the code or docker file, or do someone who have permission will push it manually?
creates below three docker images: Is my understanding right that to make each test access to each arch image, needs to be modified like below? (Without doing so, each test seems to keep trying to access to , without arch.)
For fedora28 image, just installing hostname doesn't seem to work well. Please see the log below and attached . I guess that this is due to the difference of ceph version, which will be beyond my beyond my expertise. So, could you help debugging this issue? Meanwhile, I will try testing with the image by using fedora26 for workaround.
I confirmed that below commit, which change the base image back to fedora 26, fix this issue. Please see the log . After I checked the image-, I come to think that by pushing the image, each image will be able to be pulled without -arch, so I guess the last parameter for ImageConfig should be false. (I couldn't test it in my environment.) I will fix the commit as so and make a PR once I confirm it. Also, if it will easy to fix with Fedora 28, I will wait for the actual fix and quit making a PR for the workaround.
thanks yes, a quick fix is welcome, looking forward
Thank you for your comment. I will continue with the workaround. I saw a commit for deleting multi arch consideration. I rebased the patch to the commit and made a PR. Please review it.

Discussion:
<del> amd64=fedora:28 arm64=arm64v8/fedora:28 ppc64le=ppc64le/fedora:28 </del> <ins> amd64=fedora:26 arm64=arm64v8/fedora:26 ppc64le=ppc64le/fedora:26 </ins>

<del> 1.0 </del> <ins> 1.0.1 </ins>

VolumeNFSServer     = ImageConfig{e2eRegistry, "volume/nfs", "1.0"} VolumeISCSIServer   = ImageConfig{e2eRegistry, "volume/iscsi", "1.0"} VolumeGlusterServer = ImageConfig{e2eRegistry, "volume/gluster", "1.0"} <del> VolumeRBDServer     = ImageConfig{e2eRegistry, "volume/rbd", "1.0"} </del> <ins> VolumeRBDServer     = ImageConfig{e2eRegistry, "volume/rbd", "1.0.1"} </ins> ) func GetE2EImage(image ImageConfig) string {