Juno Design Summit has ended
Back To Schedule
Thursday, May 15 • 3:10pm - 3:50pm
Datastore Versioning / One Impl to Rule them All

Sign up or log in to save this to your schedule, view media, leave feedback and see who's attending!

Let's spend some time discussion datastore versioning. Specifically let's discuss:

(1) if a datastore has distro packages, but the latest version isn't in the repo, is the accepted approach to use backports if possible? if it's not in backports then what?
(2) how do we indicate what datastore versions are supported in a particular manager impl?
(3) what is the line between "i'll slightly modify the manager to support this new version" vs. "make a new manager"?
(4) how to handle configuration-group changes across minor versions.
(5) how to handle non-distro packaging when it comes the 'packages' column, upgrades, etc.


Let's also talk about coalescing similar datastores, if we haven't already achieved consensus on this.

Currently we have percona and "mysql" (stock oracle). These values may have slightly different tweaks to some config values, as well as different /configurations, images, but other than that, the code is all the same.

Id like to propose that we limit ourselves, including our tests, to one mysql. The number of permutations for testing will rise dramatically as we add different versions and impls.

The differences can be in the form of best practices docs, rather than special options in cfg, /configurations, image, and elsewhere.

*** FWIW the same can be said about toku vs 10gen

(Session proposed by Michael Basnight)

Thursday May 15, 2014 3:10pm - 3:50pm EDT

Attendees (0)