Incompatible upgrade - Is this workaround ok? (mysql-mmm)

[BJ Dierkes]

Hello all,

I maintain Multi-Master Replication Manager for MySQL in both Fedora and EPEL.  With
changes from 2.0.11 -> 2.1.0 there was an incompatible change in that the daemon
scripts were renamed:

mmmd_agent -> mmm_agentd
mmmd_mon -> mmm_mond


Upgrades obviously break because the INIT scripts and configuration files reference the
path to the files.  Would a sufficient work-around be a symlink to the old path, or would
that not be kosher for any reason?

Thank you for your feedback.

---
derks

[Stephen John Smoogen]

On Wed, Feb 24, 2010 at 11:36 AM, BJ Dierkes
<wdierkes(a)5dollarwhitebox.org&gt; wrote:
>  Hello all,
>
>  I maintain Multi-Master Replication Manager for MySQL in both Fedora and EPEL.  With
> changes from 2.0.11 -> 2.1.0 there was an incompatible change in that the daemon
> scripts were renamed:
>
>  mmmd_agent -> mmm_agentd
>  mmmd_mon -> mmm_mond
>  
I think this will need someone from Fedora packaging to comment versus
EPEL (as that would have precedence.) My un-educated opinion is that
there would not be a problem with symlinks if its for files. [Symlinks
for directories I think causes RPM heartburn somewhere but thats a
vague recollection.]

>  Upgrades obviously break because the INIT scripts and configuration
> files reference the path to the files.  Would a sufficient work-around be a symlink to the
> old path, or would that not be kosher for any reason?
>
>  Thank you for your feedback.
>
>  ---
>  derks
>
>
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  


-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning

[BJ Dierkes]

On Feb 24, 2010, at 9:41 PM, Chen Lei wrote:

>  It's not problem to update mysql-mmm to the latest version for
> F13 and devel soon.
>  For F11 F12 and EPEL5, you need write Scriptlet in the pre and check the startlevel of
> mmmd_agent and 
>  mmmd_mon, then you can adapt the startlevel mmmd_agent based on mmm_agentd  and  mmmd_mon
> based on 
>  mmm_mond. There may be some more hack to do for configuration files.
>  
>  I think symlink isn't a good idea. 
Thank you.  To clarify, mmmd_{agent,mon} are the names of the scripts in /usr/sbin and not
the name of the init scripts (mysql-mmm-agent, mysql-mmm-monitor).  However, the sbin
scripts are referenced inside the init scripts.

I suppose an alternative to creating a symlink in /usr/sbin would be to sed the
init/config files to reference the new paths in %post.  My issue with that however is that
I only want to make such changes if the previously installed version is < 2.1.  Is
there a fedora proper way of determining the version of a package before the upgrade and
only performing upgrade actions in that condition only.  Maybe something like:

%pre
# determine current version, > /tmp/somewhere

%post
# read previous version from /tmp/somewhere, if version < 2.1 then sed up init/config
files for new paths


Just a thought.. I've done something like this before, but not under Fedora/EPEL.  

Additionally, an option would be to rename the new sbin scripts to have the old name... 
but the old name is not standard, and it would be right to follow upstream where all their
documentation references the new paths.

Thanks.

---
derks

[Chen Lei]

It's not problem to update mysql-mmm to the latest version for F13 and devel soon.
For F11 F12 and EPEL5, you need write Scriptlet in the pre and check the startlevel of
mmmd_agent and 

mmmd_mon, then you can adapt the startlevel mmmd_agent based on mmm_agentd  and  mmmd_mon
based on 
mmm_mond. There may be some more hack to do for configuration?files.

I think symlink isn't a good idea.



在2010-02-25?02:36:31，"BJ?Dierkes"?<[e-mail]>?写道：
> Hello?all,
>
> I?maintain?Multi-Master?Replication?Manager?for?MySQL?in?both?Fedora?and?EPEL.??With?changes?from?2.0.11?->?2.1.0?there?was?an?incompatible?change?in?that?the?daemon?scripts?were?renamed:
>
> mmmd_agent?->?mmm_agentd
> mmmd_mon?->?mmm_mond
>
>
> Upgrades?obviously?break?because?the?INIT?scripts?and?configuration?files?reference?the?path?to?the?files.??Would?a?sufficient?work-around?be?a?symlink?to?the?old?path,?or?would?that?not?be?kosher?for?any?reason?
>
> Thank?you?for?your?feedback.
>
> ---
> derks
>
>
>
> --?
> devel?mailing?list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

[Kevin Fenzi]

On Wed, 24 Feb 2010 12:36:31 -0600
BJ Dierkes <wdierkes(a)5dollarwhitebox.org&gt; wrote:

>  Hello all,
>  
>  I maintain Multi-Master Replication Manager for MySQL in both Fedora
>  and EPEL.  With changes from 2.0.11 -> 2.1.0 there was an
>  incompatible change in that the daemon scripts were renamed:
>  
>  mmmd_agent -> mmm_agentd
>  mmmd_mon -> mmm_mond
>  
>  
>  Upgrades obviously break because the INIT scripts and configuration
>  files reference the path to the files.  Would a sufficient
>  work-around be a symlink to the old path, or would that not be kosher
>  for any reason?
>  
>  Thank you for your feedback. 
Well, I would suggest if you can get it setup so it continues to work
as expected on upgrade it should be fine. If thats a symlink or
whatever it should be ok. 

Perhaps make and test a version, then post the spec diff for
comment/feedback if you like?

kevin

[BJ Dierkes]

On Feb 26, 2010, at 11:11 AM, Kevin Fenzi wrote:

>  On Wed, 24 Feb 2010 12:36:31 -0600
>  BJ Dierkes <wdierkes(a)5dollarwhitebox.org&gt; wrote:
>  
> > Hello all,
> > 
> > I maintain Multi-Master Replication Manager for MySQL in both Fedora
> > and EPEL.  With changes from 2.0.11 -> 2.1.0 there was an
> > incompatible change in that the daemon scripts were renamed:
> > 
> > mmmd_agent -> mmm_agentd
> > mmmd_mon -> mmm_mond
> > 
> > 
> > Upgrades obviously break because the INIT scripts and configuration
> > files reference the path to the files.  Would a sufficient
> > work-around be a symlink to the old path, or would that not be kosher
> > for any reason?
> > 
> > Thank you for your feedback.
>  
>  Well, I would suggest if you can get it setup so it continues to work
>  as expected on upgrade it should be fine. If thats a symlink or
>  whatever it should be ok. 
>  
>  Perhaps make and test a version, then post the spec diff for
>  comment/feedback if you like?
>  
>  kevin 

I have a working upgrade from mysql-mmm-2.0.x -> mysql-mmm-2.1.  I verified that all
expected changes happen, and that the running processes are gracefully condrestart'd.


The changes are pretty straight forward.  Because this is the first release of mysql-mmm
>= 2.1 I am touching a file at '%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check'
in the install.  From %pre, if this file does *not* exist then the current install is <
2.1 (meaning modifications need to be done for 2.1 compatibility).  I then touch
'%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods' (in %pre) allowing
me to verify that modifications are needed in %post.  

The modifications are simple sed changes for pid/status file and sbin daemon paths.  I
suppose I'm looking for another set of eyes to point out anything that is not obvious
to me.  The following are the [snipped] spec changes:

# --------------------------------------------------
%install
# … snipped
# Specific for upgrading from 2.0.x -> 2.1
touch %{buildroot}%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check-do-not-delete


%pre
# This is to facilitate the upgradability of 2.0.x -> 2.1
DO_MOD_CHECK="%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check-do-not-delete"
DO_MOD_VERIFY="%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods"

rm -f $DO_MOD_VERIFY 2>/dev/null

if [ ! -f "$DO_MOD_CHECK" ]; then
    # the 'check' file does *not* exist (only installed as of 2.1.0)
    # modifications are necessary.
    touch $DO_MOD_VERIFY

    # copy paths for new configs (if replaced on upgrade)
    cp -a %{_localstatedir}/run/mysql-mmm/mmmd_mon.pid \
      %{_localstatedir}/run/mysql-mmm/mmm_mond.pid 2>/dev/null ||:
    cp -a %{_localstatedir}/lib/mysql-mmm/mmmd_mon.status \
      %{_localstatedir}/lib/mysql-mmm/mmm_mond.status 2>/dev/null ||:
    cp -a %{_localstatedir}/run/mysql-mmm/mmmd_agent.pid \
      %{_localstatedir}/run/mysql-mmm/mmm_agentd.pid 2>/dev/null ||:
fi


%post
# This is to facilitate the upgradability of 2.0.x -> 2.1
DO_MOD_VERIFY="%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods"

if [ -f "$DO_MOD_VERIFY" ]; then
    # system was upgraded from < 2.1, need to modify config files/paths
    if [ -f %{_sysconfdir}/mysql-mmm/mmm_mon.conf ]; then
        cp -a %{_sysconfdir}/mysql-mmm/mmm_mon.conf
%{_sysconfdir}/mysql-mmm/mmm_mon.conf-pre2.1
        sed -i
"s|/var/run/mysql-mmm/mmmd_mon.pid|/var/run/mysql-mmm/mmm_mond.pid|g" \
               %{_sysconfdir}/mysql-mmm/mmm_mon.conf
        sed -i
"s|/var/lib/mysql-mmm/mmmd_mon.status|/var/lib/mysql-mmm/mmm_mond.status|g" \
               %{_sysconfdir}/mysql-mmm/mmm_mon.conf
    fi
    if [ -f %{_sysconfdir}/mysql-mmm/mmm_common.conf ]; then
        cp -a %{_sysconfdir}/mysql-mmm/mmm_common.conf
%{_sysconfdir}/mysql-mmm/mmm_common.conf-pre2.1
        sed -i
"s|/var/run/mysql-mmm/mmmd_agent.pid|/var/run/mysql-mmm/mmm_agentd.pid|g" \
               %{_sysconfdir}/mysql-mmm/mmm_common.conf
    fi
fi


%post agent
# … snipped
# This is to facilitate the upgradability of 2.0.x -> 2.1
DO_MOD_VERIFY="%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods"
if [ -f "$DO_MOD_VERIFY" ]; then
    # remove old files
    rm -f %{_localstatedir}/run/mysql-mmm/mmmd_agent.pid 2>/dev/null ||:
fi


%post monitor
# … snipped
# This is to facilitate the upgradability of 2.0.x -> 2.1
DO_MOD_VERIFY="%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods"
if [ -f "$DO_MOD_VERIFY" ]; then
    # remove old files
    rm -f %{_localstatedir}/run/mysql-mmm/mmmd_mon.pid 2>/dev/null ||:
    rm -f %{_localstatedir}/lib/mysql-mmm/mmmd_mon.status 2>/dev/null ||:
fi
# --------------------------------------------------


Thanks.

---
derks