Wednesday, September 21, 2016

MySQL team: make it easy to give you feedback!

There was a bold announcement during the MySQL Keynote at Oracle Open World. A new product that will mix up with the existing GA server, called MySQL InnoDB Cluster. This is an evolution of MySQL group replication, which has been in the labs for long time, and the MySQL shell, which was introduced as a side feature last April. The boldness I mentioned before is on account of wanting to add to a GA server something that was defined as release candidate despite never having been out of the labs. The product is interesting as it promises to be a quick and painless cluster deployment, with built-in high availability and scalability.

What surprised me most was a heartfelt and urgent request to test this new product and provide feedback, hinting that it would be GA soon.

Here are some thoughts on this matter:

  • A product in the labs is perceived as pre-release, i.e. less than beta quality. This is what happened with previous releases on labs: GTID, multi-source replication, and data dictionary were all released in labs before eventually being integrated in the main project.
  • Putting a product in labs again and declaring it release candidate feels odd.
  • The problem with labs is that the previews are distributed with a limited set of packages, and without documentation. The brave souls that test these packages need to find information about the new software in blog posts or dig in the source code, without any assurance that this package would ever become officially supported.

There is some confusion about which package is of which quality. From the keynote it looked like MySQL InnoDB Cluster (MIC) was the one being RC, but when I asked for clarifications it seems that group replication is RC (from its niche in the labs) while MIC is still of unknown quality. From what I saw in the demos it seems quite alpha to me.

Back to the main topic. MySQL want feedback, but provides software in the labs, in a way that is not easy to use. Specifically:

  • There is an OSX package that contains .dmg files, implying that I should install those in my main computer. Given that the perceived quality is low, I'd say "No, thanks," as I don't want to risk my laptop with alpha quality installed as root. Besides, this is cluster software, so I would need at least three nodes to make it work. There is a "sandbox mode" that allows you to simulate three nodes on a single server, but this still requires a main installation, with all the risks involved. No, thanks, again.
  • There are only .rpm files for Linux, which means that I need to have either servers or VMs where to install software as root. I have the same concerns as I have for the Mac: while VMs can be thrown away and remade, it is still a big investment in time and resources to test something new.
  • Missing are generic .tar.gz binaries, which would allow users to install in user space, without affecting the operating system or other MySQL servers.
  • Missing are also Docker packages, which would allow users to test quickly and painlessly without any risk.
  • Finally, and probably most importantly, there is no documentation. If this is RC software, there should be at least a couple of workloads that could be included in the labs packages for reference.

Summing up, I have a message for the MySQL team product managers and developers: if the software is meant to be usable, i.e. more than a proof of concept as other things in the labs, move it to the downloads section, same as it happened with the MySQL Shell and the document store early this year. Also, provide Docker images early on, so that people can test without many risks. This exercise alone would discover bugs just while you are doing it. And please add documentation for the feature you want feedback for. If the manual is not ready, don't limit the docs to a skinny blog post, but add the specifications used to create the feature (workloads) or even an alpha version of the docs. In short, if the software is worth giving feedback, it should be treated with more respect than it is shown right now. And the same respect goes for the users whom you are asking feedback from.


Unknown said...

I fully agree on the documentation - when I tested Group Replication all available information was just in scattered blog posts, this is not a good approach to test some software.

Anonymous said...

The documentation is available at:

InnoDB Cluster: beta draft version.

MySQL Shell:

MySQL Router:

James Day, MySQL Senior Principal Support Engineer, Oracle

Giuseppe Maxia said...

Thanks for the links.
I don't see in the list the documentation for MySQL Group Replication, the product that should be of Release Candidate quality. Surely, if it is at this stage, the documentation should be ready. If it is, it is not easy to find.

The docs for the MySQL InnoDB Cluster only talk about deployment with sandboxes in the same host, which makes me think that the product is not as advanced as it was depicted.

James Day said...

It's no surprise to have documentation lagging on new things, particularly non-GA ones. That's the way it usually happens. For now you might find Matt Lord's group replication quickstart guide of use though of course both you and Vadim are right that we need more and in more formal documentation rather than blog posts.

As a support engineer I want people to be using sandboxes for their initial work on things they haven't used before. Means we're less likely to see issues in production. Not much indication of maturity. Just what's sensible and what we want people to be starting to do on labs things initially even if they do more test and QA related work later.

James Day, MySQL Senior Principal Support Engineer, Oracle

Giuseppe Maxia said...

"It's no surprise to have documentation lagging on new things, particularly non-GA ones."

I am fully aware of the product not being GA.
I am raising the point because this same product (group replication) was called release candidate, and as such I expect to see documentation. Actually, I expect to see some documentation for any labs release. The minimal documentation that can be distributed is a copy of the related worklogs.