Bug 1467557 - oc cluster up fails with --host-volumes-dir flag on Windows
oc cluster up fails with --host-volumes-dir flag on Windows
Product: OpenShift Container Platform
Classification: Red Hat
Component: Command Line Interface (Show other bugs)
Unspecified Unspecified
medium Severity low
: ---
: 3.8.0
Assigned To: Cesar Wong
Dongbo Yan
: Regression
Depends On:
  Show dependency treegraph
Reported: 2017-07-04 04:03 EDT by Dongbo Yan
Modified: 2018-03-28 10:06 EDT (History)
3 users (show)

See Also:
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:
Last Closed: 2018-03-28 10:06:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0489 None None None 2018-03-28 10:06 EDT

  None (edit)
Description Dongbo Yan 2017-07-04 04:03:22 EDT
Created attachment 1294109 [details]

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
 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

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

How reproducible:

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:
   Error: cannot create volumes dir share
   Caused By:
     Error: Docker run error rc=1
       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 13:28:27 EDT
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 18:34:09 EDT
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 10:16:14 EDT
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 03:59:55 EDT
$ ./oc version
oc v3.7.0-0.158.0
kubernetes v1.7.6+a08f5eeb62
Comment 7 errata-xmlrpc 2018-03-28 10:06:20 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.