<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On Thursday 10 July 2014 01:48 AM,
Robie Basak wrote:<br>
</div>
<blockquote cite="mid:20140709201837.GE17765@mal.justgohome.co.uk"
type="cite">
<pre wrap="">On Thu, Jul 10, 2014 at 12:59:24AM +0530, Akhil Mohan wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> 1. Will purging the server package for each fork trigger removal of
data dir or purging mysql-defaults will remove data dir ?
</pre>
</blockquote>
<pre wrap="">
Each variant's server package owns it's corresponding directory. Purging
the package should purge the directory, since nothing else will do it
after it's gone.</pre>
</blockquote>
But then what else remains for mysql-defaults to handle ?<br>
<blockquote cite="mid:20140709201837.GE17765@mal.justgohome.co.uk"
type="cite">
<pre wrap="">
mysql-defaults exists only for common code and for coordination between
variants' packages where we think that would be useful. Variants'
packages still do all the work.
It would probably be useful for mysql-defaults to be aware of what is
present, in terms of installed variants, their data directory names and
their capabilities (in terms of migration fork capability and binary
compatibility). I don't know if this should be dynamic (registering with
mysql-defaults and deregistering on purge, etc), or static
(mysql-defaults just looks for data directories and has a static
database of what they mean).</pre>
</blockquote>
Need of dynamic meta-data is needed because of manual steps. If we
can make migration completely automatic then static meta-data would
be sufficient. <br>
<blockquote cite="mid:20140709201837.GE17765@mal.justgohome.co.uk"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap=""> 2. If the removal is associated with mysql-defaults, then in
co-installed setup will mysql-defaults remove all data dirs at once
or allow selection ?
</pre>
</blockquote>
<pre wrap="">
N/A - removal happens on purge of individual variant server package
removal.</pre>
</blockquote>
Yes, thanks for clarification.<br>
<blockquote cite="mid:20140709201837.GE17765@mal.justgohome.co.uk"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap=""> 3. If all data dirs will be removed together, then it is possible to
accidentally remove more than required. How will we control this ?
</pre>
</blockquote>
<pre wrap="">
Also N/A I think?</pre>
</blockquote>
Yes, thanks for clarification.
<blockquote cite="mid:20140709201837.GE17765@mal.justgohome.co.uk"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap=""> 4. Since user might do manual data dir creation and also add the
required entries in config manually so the mysql-defaults package
may always not know if data dir is present and might remove user
accounts owning the custom data dir leaving data inaccessible. Will
we check for only standard data dirs or read them from config files ?
</pre>
</blockquote>
<pre wrap="">
mysql-defaults is just some common ground so that variants' packages can
communicate, for read-only purposes only. mysql-defaults certainly
shouldn't be changing anything.</pre>
</blockquote>
But all variants by themselves can give read-only access to their
specific data dirs like we have for /var/lib/mysql currently.<br>
<blockquote cite="mid:20140709201837.GE17765@mal.justgohome.co.uk"
type="cite">
<pre wrap="">
The way I see it, that reduces your concern to what exists for any other
server package that handles persistent data, and the solutions should be
the same.
</pre>
<blockquote type="cite">
<pre wrap=""> 5. I see possibility of config files getting custom location during
manual setup ? Do we see this as trouble ?
</pre>
</blockquote>
<pre wrap="">
If a user repoints the data store to some other directory, then
mysql-defaults may become blind to this. That would rule out automatic
migration fork help, but I don't see that anything else would break. I
think this breakage could be handled gracefully - eg. by detecting that
the directory doesn't exist, and not presenting the option. In the case
of the user having left the original data files there, and running the
database live somewhere else, then the migration would appear to work,
but of course only migrate the files that were in the original
directory. I think this would be fine, and that we can't be expected to
do any better.</pre>
</blockquote>
It is okay for migration, but while removing a variant, if default
data dir is not present, then as per the current logic during post
removal the user account will be removed. Since same user would be
used for custom data dir, it will make that dir completely
inaccessible.<br>
<blockquote cite="mid:20140709201837.GE17765@mal.justgohome.co.uk"
type="cite">
<pre wrap="">
It does occur to me that there would be a need to temporarily stop
another variant's daemon during migration, and this breaks the read-only
ness. I don't think this is a showstopper though - we can figure out a
way to handle that.
Robie
</pre>
</blockquote>
If you agree then we can work on initial prototype to see how your
proposal works and then improve it further as needed. I can try to
setup a temp repo with the new set of packages for everyone to
review and comment. Initially we may delegate following
responsibilities to mysql-defaults:<br>
<ol>
<li>It will breaks/ replaces existing MySQL 5.5 and 5.6 packages.
(I am limiting to MySQL for POC)<br>
</li>
<li>IIUC, it will contain shared scripts to manage data dir, user
accounts, permissions etc that would be called from
mysql-server-5.x.postinst.</li>
<li>server packages will pre-depend on mysql-defaults.</li>
</ol>
<p>Please let me know if you agree for prototype implementation. I
apologise if I am burdening you by asking again but I want you to
review the list above and modify as per your proposal in mind so
that we are sure efforts would go in right direction.<br>
</p>
<p>Regards,<br>
Akhil<br>
<br>
</p>
</body>
</html>