Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Drupal (and other) install setup

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: David Kowis <dkowis AT shlrm.org>
  • To: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] Drupal (and other) install setup
  • Date: Thu, 07 Jun 2007 08:02:19 -0500

Eric Sandall wrote:
I'd rather not add another queuing method to take care of this. Although
I'm biased, I believe my proposal above is the best approach. ;) There
should be only one queue method, otherwise people may "forget" (or never
learn about) this other method and never see the updates. Sometimes too
many options for similar functions become more of a nuisance than a help.

As for leaving the files around to be noticed eventually, if the admin
is using web apps and is aware of this proposed method, he/she may have
Sorcery send notification e-mails and so be aware that the new version
is now installed (in case they missed it when doing a queue (perhaps
automated)).

Leaving files around is similar to "adding another queuing method". People may "forget" or never know that you've left files laying around on their drive, and never actually update their drupal to the newer version. If the admin is aware that they've got apps that need help being upgraded and is aware of the "hold-my-hand" upgrade queue, he/she may have sorcery send notification emails and so be aware that there's some spells in this queue. This can easily be automated via cron.

As a secondary method, which requires absolutely no code changes, the admin could have a script checking sorcery queue for spells that they're interested in. It could send them an email letting them know that there's drupal in the queue and that they should pay attention to the update, or do it themselves.


<snip>
The idea I proposed above would also help prevent the horrendous
breakage. Of course, that admin gets around to updating the software
when they get around to it. Which may mean that they don't update the
spell in a long time. So another shorter term solution to the annoyance
is a sorcery hold. I don't think that gimping the package management to
leave files around is a good solution. I think that better management of
the upgrade path is a better solution.

The admin can remove the files when they are sure the upgrade has
worked. Having "everyone" hold a spell because it's a problem is a
problem itself, IMO, and I see this as a "needs fixing."

It's not so much that everyone has to hold the spell. It's more that the admin has to pay attention to what they're upgrading. If they want to have an automated "sorcery queue; cast --queue" running from cron, then it's their own fault if their production system goes down because they were running unattended updates. I is not our responsibility to prevent the admin from shooting themselves in the foot. Personally, I always look through my queue, because I don't want to fire off automated upgrades on things that I suspect could break things (postgresql, mysql, apache for example.) I remove those from the automated queue, and then start it off. Later I come back and update those myself while paying attention to the box. I don't believe it is too high of a bar to require the admin to pay attention to what they're upgrading on their systems.


Perhaps a way of cleaning out old files (this would apply to web apps as
well as kernel modules) would be handy. Another addition to `cleanse` to
do so might be handy, but a few issues I see with this approach as well:
1. How does cleanse know when files are no longer needed?
2. Will these files be permanently wiped or compressed and stored
somewhere?

If we don't leave old files laying around (in the case of web apps) then we don't have to come up with another solution to cleaning them out. Right now we only leave files laying around when dispelling them would cause the entire system to die. Mostly the kernel and it's modules, afaik. If we modify our spell installation stuff for web spells to leave files laying around, for one, we'd have to hack the install log, or add another directory (/usr/share/www) to the protected list. I don't really like either of those options. I suppose we could do the install in FINAL, as an alternative solution. However, that makes those spells different than every other spell we've got.

It seems to me that by helping an admin be lazy for spells that they simply need to watch for and be there right after the upgrade completes, we're creating far more work than we're helping to relieve. If that sentence didn't make sense, the cost-to-benefit ratio[0] is too high. It's going to require lots more work for us just to save a lazy admin's ass, IMHO.


1. For kernel modules, just check if the kernel image exists that they
were built against, and if not, they are no longer used. For web apps,
check the "$SPELL -> $SPELL-$VERSION" symlink to determine if the old
version may be removed (the symlink does not point to the old version)
or not.

I, personally, think this is a bit too much micromanagement. It's quite trivial for an admin to delete his kernel modules once he's sure he's finished with that kernel. I think it would be far worse for our logic to mistakenly delete kernel modules that were still in use. The risk is higher than the potential benefit.


2. Even with ARCHIVE="on" cleanse will remove the old archive, removing
any copy of the old files which may be around.

Mainly for #2, but also #1, I would prefer to let the admin clean up the
files. A `gaze aliens` will let him/her find files which are no longer
tracked and he/she may decide if they should be removed or not.

So i think we're in agreement on this secondary conversation. We don't want to delete "old files"; we'll leave it up to the admin.

[0] Sorry about the adaptive synergy.

--
David Kowis

Attachment: signature.asc
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.24.

Top of Page