Bug 1467557

Summary: oc cluster up fails with --host-volumes-dir flag on Windows
Product: OpenShift Container Platform Reporter: Dongbo Yan <dyan>
Component: ocAssignee: Cesar Wong <cewong>
Status: CLOSED ERRATA QA Contact: Dongbo Yan <dyan>
Severity: low Docs Contact:
Priority: medium    
Version: 3.6.0CC: aos-bugs, jokerman, mmccomas
Target Milestone: ---Keywords: Regression
Target Release: 3.8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Known Issue
Doc Text:
Cause: The --host-volumes-dir flag on 'oc cluster up' allows the end user to specify where to place transient secret and configmap volumes that openshift uses for running pods. Because cluster up runs a containerized node, the directory needs to be mounted on the origin container as a shared volume mount so that mounts created by the node inside the origin container are visible to pod containers run by the node. If using Docker for Windows or Docker for Mac, the Docker daemon runs inside a VM. For it to be able to create a shared mount for the volumes directory, the directory cannot be located on a file system mounted from the host Windows or Mac machine. Consequence: Specifying a --host-voumes-dir that points to a directory on the Mac or Windows machine will result in cluster up failing to start. Workaround (if any): Specify a directory that is not mounted from the Mac or Windows machine. The use of this flag is limited in usefulness in these systems, because the data contained in this directory is transient and does not need to be kept across restarts.
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-28 14:06:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dongbo Yan 2017-07-04 08:03:22 UTC
Created attachment 1294109 [details]
log

Description of problem:
oc cluster up fails with --host-volumes-dir flag on Windows

Version-Release number of selected component (if applicable):
oc v3.6.131
kubernetes v1.6.1+5115d708d7

docker@openshift3:~$ docker version
Client:
 Version:      1.13.1
 API version:  1.26
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 08:47:51 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.13.1
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.7.5

How reproducible:
Always

Steps to Reproduce:
1.Use docker-machine tool to create a docker-machine VM on Windows OS
2.Docker ssh docker-machine VM, create dir /tmp/volumes
3.Launch openshift cluster with --host-volumes-dir flag
 C:\Windows\system32>oc cluster up --image=brew-pulp.../openshift3/ose --version=v3.6 --host-volumes-dir=/tmp/volumes --docker-machine=openshift3.6


Actual results:
FAIL
   Error: cannot create volumes dir share
   Caused By:
     Error: Docker run error rc=1
     Details:
       Image: brew-pulp.../openshift3/ose:v3.6
       Entrypoint: [/bin/bash]
       Command: [-c grep /tmp/volumes /rootfs/proc/1/mountinfo | grep shared || nsenter --mount=/rootfs/proc/1/ns/mnt mount --make-shared /tmp/volumes]
       Error Output:
         mount: /tmp/volumes: Invalid argument

Expected results:
Launch openshift cluster successfully

Additional info:

Comment 1 Cesar Wong 2017-07-05 17:28:27 UTC
This is expected, given the /tmp directory is a mounted tmpfs file system. In general, it is not recommended to specify --host-volumes-dir argument when running on Windows or Mac, but if you do use it, you need to make sure that the directory resides in the Docker VM and that you can create a shared mount at that location. If some other filesystem is already mounted, then cluster up won't be able to create the shared mount.

I am lowering the severity of this bug. However, we do need to explain this better in the documentation.

Comment 2 Cesar Wong 2017-07-05 22:34:09 UTC
Took a closer look and it seems that this will happen even if you're pointing to a directory where you can create a shared mount. It happens both on Mac and Windows. It should be fixed, but still keep it as a low severity bug since there's not much benefit in using the option in either platform.

Comment 3 Cesar Wong 2017-10-09 14:16:14 UTC
This is no longer occurring in the latest origin master. An alternate volumes directory can be used. However, on Windows and the Mac this must be a directory inside the Docker vm and can't be a directory on the host machine, because creating a share for it will fail.

Comment 4 Dongbo Yan 2017-10-19 07:59:55 UTC
Verified
$ ./oc version
oc v3.7.0-0.158.0
kubernetes v1.7.6+a08f5eeb62

Comment 7 errata-xmlrpc 2018-03-28 14:06:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0489