Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to create volume with alternative driver #985

Closed
udalrich opened this issue Apr 5, 2018 · 4 comments
Closed

Unable to create volume with alternative driver #985

udalrich opened this issue Apr 5, 2018 · 4 comments

Comments

@udalrich
Copy link

udalrich commented Apr 5, 2018

Description

I am trying to create volumes using rexray as the driver, but the volume is created with the local driver.

I have rexray installed and can create volumes with the rexray command line. If I run

docker run -v foo:/foo --volume-driver rexray bash 

a rexray volume is created:

[vagrant@master ~]$ docker volume ls
DRIVER              VOLUME NAME
local               06d6887fb78b8537aaf0293c365dfc6766e130a1857538c54d1668fcfa5f101a
rexray              Docker.vdi
rexray              box-disk001.vmdk
rexray              centos-vm-disk1.vmdk
rexray              foo

I can also create a volume with

[vagrant@master ~]$ docker volume create --driver rexray --opt size=10 test
test
[vagrant@master ~]$ docker volume ls
DRIVER              VOLUME NAME
local               06d6887fb78b8537aaf0293c365dfc6766e130a1857538c54d1668fcfa5f101a
rexray              Docker.vdi
rexray              box-disk001.vmdk
rexray              centos-vm-disk1.vmdk
rexray              foo
rexray              test

However, when I use the plugin to create the volume, it is created with the local driver.

[vagrant@master ~]$ docker volume ls
DRIVER              VOLUME NAME
local               06d6887fb78b8537aaf0293c365dfc6766e130a1857538c54d1668fcfa5f101a
rexray              Docker.vdi
rexray              box-disk001.vmdk
rexray              centos-vm-disk1.vmdk
rexray              foo
local               sqlserver-backup-dev     <------ volume created by plugin
rexray              test

It looks like either the plugin is ignoring the driver, or the driver is failing to create the volume, but then the plugin is not failing but continuing on and effectively using the default driver.

Info

  • d-m-p version : 0.24.0
  • Maven version (mvn -v) :
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z)
Maven home: /opt/apache-maven-3.5.3
Java version: 1.8.0_161, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.10.0-514.2.2.el7.x86_64", arch: "amd64", family: "unix"
  • Docker version : Docker version 18.03.0-ce, build 0520e24
  • If it's a bug, how to reproduce :

I configured the plugin as below.

I was starting an images based on the SQL Server image, but any image would probably work.

      	<plugin>
        	<groupId>io.fabric8</groupId>
        	<artifactId>docker-maven-plugin</artifactId>
        	<version>0.24.0</version>

            <executions>
                <execution>
                    <phase>package</phase>
                    <goals><goal>start</goal></goals>
                    <!-- Consumers should define an additional execution that starts each container -->
                </execution>
             </executions>

            <configuration>
                <images>
                    <image>
                        <name>${fabric8.docker.image}</name>
                        <run>
                            <cmd>${fabric8.docker.cmd}</cmd>
                            <wait>
                                <exit>0</exit>
                            </wait>
                            <log>
                                <date>DEFAULT</date>
                                <file>${basedir}/target/fabric8.log</file>
                            </log>
                            <volumes>
                                <bind>
                                    <volume>sqlserver-backup-dev:/var/opt/mssql/data</volume>
                                </bind>
                            </volumes>
                        </run>
                    </image>
                </images>
                <volumes>
                    <volume>
                        <name>sqlserver-backup-dev</name>
                        <driver>rexray</driver>
                        <opts>
                            <!-- Volume size in GB -->
                            <size>50</size>
                        </opts>
                    </volume>
                </volumes>
            </configuration>
        </plugin>
@rhuss
Copy link
Collaborator

rhuss commented Apr 5, 2018

When you call "mvn -X docker:volume-create" could you please look out for log output with "Creating volume ..." and "Volume create config ..." ?

Please post them here as it seems that there is an issue to put the driver properly into the API call.

Thanks !

@rhuss
Copy link
Collaborator

rhuss commented Apr 5, 2018

Remember, you have to call docker:volume-create for creating the volumes, if you just call docker:start then I guess that Docker will create the volume implicitly with default options (same as with the Docker CLI)

@udalrich
Copy link
Author

udalrich commented Apr 6, 2018

I completely missed the need to run the docker:volume-create task. My apologies; I am used to using docker-compose to create volumes, where it automatically makes them as needed. After I added that execution, it does indeed create the volume with rexray.

@rhuss
Copy link
Collaborator

rhuss commented Apr 6, 2018

Cool ;-) However, I think it would be still a good addition to docker-maven-plugin that, if a volume is referred during startup and if this does not exist and a volume configuration exists, then this should be taken to create the volume upfront, not relying on Docker to create it implicitly during startup with default params.

The documentation needs also an update to reflect that you cannot only configure real host paths in bind mounts, but also volumes (this is also weak in the Docker documentation itself).

Let me close this issue if you don't mind and create a new one for this task.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants