[Dbconfig-common-devel] Questions about upgrading

[sean finney]

hi ross,

On Sat, Jul 08, 2006 at 07:17:53AM -0700, Ross Boylan wrote:
> bacula, specifically bacula-director-pgsql, uses dbconfig-common, and
> I recently attempted to upgrade from bacula 1.36 to 1.38, which
> involves a change in the database format.  The initial upgrade did not
> upgrade the database, and I'm wondering if there is a way to do so
> now.  I haven't had working backups for about a month :(

no fun :(

the short version of the answer you seem to have already figured out
below, i'll commend further there.

> Details on what needs to be done should most likely be provided in
> /usr/share/doc/bacula-director-pgsql.  [They aren't--RB]

then shame on him :)

> Configure database for bacula-director-pgsql with dbconfig-common? no

so you said no because you already had an existing bacula db setup.
i'm going from memory here, but i think that this also disables any
attempt at automatic upgrade support.  

i *think* you can safely say yes here if you're upgrading, without it
trying to install a new database on top of your own.  

> bacula-director-pgsql clearly has upgrade scripts, specifically
> /usr/share/dbconfig-common/data/bacula-director-pgsql/upgrade/pgsql/1.38.0.
> 
> Is there anything I can do that will invoke them?

yes... the contents of that file should be basic sql commands.  you can
probably do something like

psql -U bacula bacula < /usr/share/dbconfig-common/data/bacula-director-pgsql/upgrade/pgsql/1.38.0.

assuming user/database named bacula.  of course, you should make a
backup of the data first just in case :)

> Though I see the upgrade scripts, I do not see hooks for upgrading in
> the package postinst scripts (or other scripts I looked at).  The TODO

the upgrade is handled by dbconfig-common's hooks, and is indirectly
reached by calling dbc_go in the postinst script.  if you want to
see what's really happening, the file with all the action is
/usr/share/dbconfig-common/dpkg/postinst, though that's only
if you're curious.

> DBCONFIG's QUESTION
> ===================
> Was I supposed to answer the question I got with a "yes"?  If so, I
> think it would be good to reword it so that is clearer--for example,
> if the question is really just "use dbconfig or not?" then that's what
> it should say.

like i said earlier, i *think* you can answer yes to that safely, though
i wouldn't bet anything important that it's the case.  perhaps it would
be better to be asked a different question entirely--maybe the upgrade
question should be asked directly--but i'd have to think that over a
bit.

> However, dbconfig's templates clearly have an upgrade question.  Does
> the absence of such a question indicate that the bacula package is not
> set up quite right for upgrades?

no, i htink the upgrade question is asked only if the install question
had an affirmative answer.

> As far as I can tell, dbconfig couples the upgrade of the packages
> database with the upgrade of the package.  I wonder if that's the best
> choice.  Many packages can support multiple database instances, so it

yes, it's by design this way.  this way if something goes wrong,
the admin knows about it immediately, and has a chance to fix things
(there's also an option to ignore the problem and fix it later).

since dbconfig-common doesn't currently support multi-instance
databases, i'm not too concerned on how it handles an upgrade
for a multi-instance database.  that is, if someone's in that situation,
they've already >= some of the setup manually, so they can do >= some
of the upgrade manually too.

that said, one of the things on my TODO is multi-instance support...

> One note said that if the dbconfig operation failed the package
> installation failed, which is sort of not the case here.  I now have
> the bacula package at 1.38 but a database that still needs to be
> migrated from 1.36.

right, because you said "i don't want your help" :)

> DOCUMENTATION
> =============
> 
> dbconfig doesn't seem to have any user-level (really, admin-level)
> documentation; the existing documents are for developers of other
> packages.  Maybe that's OK, since it's supposed to "just work."
> However, these problems did have me hunting around for such
> documentation.

the thing is that dbconfig-common doesn't have tools that the admin
can use, thus there isn't much to document.  the primary goal of
this project wrt the "local admin" is to provide something that works
with the standard package installation process and that doesn't require
any knowledge about extra cmdline tools (or even the database foo)
besides the package management tools themselves.

that said, i'm not against abstracting out some of the code in question
to external scripts.  for example, 

	dbc-upgrade-package <package> <oldvers> <newvers>

seems like something that would be nice to have.  

anyway, thanks for the feedback.  lemme know what you end up doing,
what works/breaks etc with your bacula installation.


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/attachments/20060708/d1c8d2ad/attachment.pgp