Supposedly simple command fails

[mike-lischke]

First time trying the new dbdeployer tool. I used MySQL sandbox before with success.

I downloaded a 5.6 server and unpacked it, which gives me a folder mysql-5.6.41-macos10.13-x86_64. Now I run deploy with this result:

mike$ ./dbdeployer deploy single --port 5600 -u root -p localRoot#123 sandbox-packages/mysql-5.6.41-macos10.13-x86_64
No version detected for directory /Users/mike/sandbox-packages/mysql-5.6.41-macos10.13-x86_64

No idea what the tool wanna tell me with that message, but the setup failed. I ran this in my homedir which contains the 2 folders sandbox-packages and sandboxes. Obviously, this is on macOS 10.13.

[datacharmer]

Thanks for trying dbdeployer.

dbdeployer has simplified the command structure of MySQL Sandbox. For this reasons, some of the assumptions that were valid for the old app don't hold anymore.

The easy way of running operations would be (instead of manually unpacking the tarball:)

dbdeployer unpack mysql-5.6.41-macos10.13-x86_64.tar.gz

This command will create $HOME/opt/mysql/5.6.41. You can change the destination directory using --sandbox-binary.

dbdeployer deploy single --port 5600 -p 'localRoot#123' 5.6.41

(notice that you don't need to indicate "-u root" as the root user will be assigned your given password regardless.)

Please read the chapter named Standard and non-standard basedir names in README.
In short, the directory must be named "x.x.xx" or end with "x.x.xx" to be recognized as containing a valid version. In all other cases, you should supplement the version with --binary-version.

Your command would work as follows:

dbdeployer deploy single --port 5600 -p 'localRoot#123' \
    sandbox-packages/mysql-5.6.41-macos10.13-x86_64 \
    --binary-version=5.6.41

But I would not call this one simple if compared to the recommended one.

[mike-lischke]

Thanks for your answer Giuseppe. I'm at a hospital atm. and don't have my equipment with me. I'll check when I'm back at home.

[mike-lischke]

When I add --binary-version the installation works. The README however says:

When the extracted tarball directory name that you want to use doesn't contain the full version number (such as /home/dbuser/build/path/5.7-extra) you need to provide the version using the option --binary-version.

It doesn't say it must end with the version number. A little glitch that made me scratch my head :-) Also, it might be worth to expect the name to be like what the MySQL downloads use, as this is what people get. On the other hand you expect that unpack is used normally (though that requires another study of parameters, especially when one doesn't use the default folder setup you expect). Would be nice if by default the current folder is used instead, not opt.

Anyway, the tool did the job and I'm very thankful for that.

[datacharmer]

Thanks for your feedback, Mike.
The README does not say exactly "it must end with the version number" but it says "you can differentiate them [the versions] using a prefix," which amounts to the same thing. Since this is not a grammar 101 class, though, I will amend the README to state this fact unequivocally.

I understand the default $HOME/opt/mysql may not be to everyone's liking. For that, you can customize either on-the fly (--sandbox-binary=/my/preferred/path) or permanently (dbdeployer defaults update sandbox-binary /my/preferred/path).
By personal experience I can tell you that using the default folder for the extracted tarball becomes messy quickly, but I put together enough flexibility in the package to allow you to do just that.

Finally, why I don't "expect the name to be like what the MySQL downloads use"?
The only place where this is recognized is during dbdeployer unpack, where the tool recognizes MySQL pattern and gets the version. For the normal cases, I decided to limit the acceptance to just one version at the end of the directory name to simplify the paradigm and to avoid thorny issues when users name their directories with lots of numbers. The ultimate goal of dbdeployer is to keep operations simple. To this end, you need to embrace its philosophy and go with the flow, sort of like using MySQL Workbench, or mysql config editor, or mysql shell: if you expect them to run like other tools that you are comfortable with, you will be disappointed. :-)

Thanks for using dbdeployer, and I hope you will find the right setup for your needs.

While I can't change the default behavior (on which other users depend) I am open to requests to add configuration options that I may have missed so far.

[mike-lischke]

Many thanks for your explanation - makes totally sense. I just shared what went through my brain when I tried the tool out the first time. Now that everything is clear and working, I'm glad such a tool exists. Especially on macOS it would be quite a pain to set up more than one server manually (which I need for testing MySQL Workbench with them).