Bug 6365 - need way to cut emergency rule updates with new update-generation system
Summary: need way to cut emergency rule updates with new update-generation system
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: sa-update (show other bugs)
Version: 3.3.0
Hardware: Other All
: P4 major
Target Milestone: ---
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-04 11:56 UTC by Justin Mason
Modified: 2015-04-13 21:49 UTC (History)
4 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Mason 2010-03-04 11:56:07 UTC
split off from bug 6363.

we urgently need to have a way to cut an update package from current SVN, without having to go through the full mass-check/score-generation daily cycle.  CUrrently it appears that the /export/home/updatesd/svn/mkupdates-with-scores/do-stable-update-with-scores script is oriented towards full generation and doesn't allow that.

this ticket is to track that work.
Comment 1 Mark Martinec 2010-03-04 13:24:09 UTC
> split off from bug 6363.
> we urgently need to have a way to cut an update package from current SVN,
> without having to go through the full mass-check/score-generation daily cycle. 

Kind'a duplicate for Bug 6281 too.
Comment 2 Justin Mason 2010-03-04 14:25:27 UTC
(In reply to comment #1)
> Kind'a duplicate for Bug 6281 too.

there's overlap, but it's not a dup.  Bug 6281 deals with speeding up the pipeline in the normal case -- this is for the emergency-change case, where the manually-made change needs to go out ASAP.
Comment 3 Daryl C. W. O'Shea 2010-03-05 01:22:25 UTC
I'm thinking about how'd I'd like to see this improved.

In the meantime, one easy way to do this is to just unpack the latest generated revision, apply your diff and repackage it by hand.  Update the zone file, wait 16 minutes (or until the update appears on mirrors) and tick the zone serial number.

Something in my head is screaming don't just use the current revision's rules.  I guess it's safe if you audit any changes in the rules from the previous 48+ hours.
Comment 4 Justin Mason 2010-03-05 11:32:49 UTC
there's another use-case for this script.  When a release is pushed, we need to simultaneously push a rule update package.  Currently there's no easy way to do that for 3.3.x.
Comment 5 Justin Mason 2010-03-12 14:13:38 UTC
(btw, I'm re-enabling the "nightly stable update from trunk" cron job at the moment.)
Comment 6 Justin Mason 2010-03-12 14:41:33 UTC
this is important, but doesn't need to block 3.3.1.
Comment 7 Justin Mason 2010-03-15 11:13:08 UTC
I think the script from bug 6311 ("build/mkupdates/update-rules-3.3") should be enough to fix this....
Comment 8 Justin Mason 2010-03-22 12:23:30 UTC
(In reply to comment #4)
> there's another use-case for this script.  When a release is pushed, we need to
> simultaneously push a rule update package.  Currently there's no easy way to do
> that for 3.3.x.

well, this part is fixed; I used the "update-rules-3.3" script to do that and updated the procedure during the 3.3.1 release, see bug 6311.

I'm pretty sure that script will work fine as an emergency-update-generation script.  I'd just like to verify that there's no major functionality in the mass-check/score-generation cron scripts that doesn't also need to be duplicated for this case.
Comment 9 Justin Mason 2010-03-23 16:33:53 UTC
moving all open 3.3.1 bugs to 3.3.2
Comment 10 Karsten Bräckelmann 2010-03-23 17:42:56 UTC
Moving back off of Security, which got changed by accident during the mass Target Milestone move.
Comment 11 Daryl C. W. O'Shea 2011-05-20 05:37:40 UTC
I've added a script to revert to an existing update version... build/mkupdates/revert-stable-update

It doesn't solve the problem of making a fast new update, but it does give us the option of easily rolling back (reverting) to a previous update version.

Reverting to an existing generally known to be good update should be our number one choice when trying to correct a rule update problem as were not rushing out a new update that could be broken in its own way.  This works in cases where a new update introduces a problem, such as a new really bad rule.

It doesn't help us in situation where an old rule turns bad for some reason, such as our little "Y2K10" rule issue from January 1 last year.  In cases such as those (which I expect to be much fewer in occurence then the "new bad update" described above) we'll need to create and release a new update.  I'll work on this case next.  I think one possible way I may do it is that you supply a patch to the revert script for it to apply to an existing update (the script would unpack the existing update, patch it, pack it back up and re-sign it).
Comment 12 Kevin A. McGrail 2011-05-28 10:28:36 UTC
(In reply to comment #11)
> I've added a script to revert to an existing update version...
> build/mkupdates/revert-stable-update
> 
> It doesn't solve the problem of making a fast new update, but it does give us
> the option of easily rolling back (reverting) to a previous update version.
> 
> Reverting to an existing generally known to be good update should be our number
> one choice when trying to correct a rule update problem as were not rushing out
> a new update that could be broken in its own way.  This works in cases where a
> new update introduces a problem, such as a new really bad rule.
> 
> It doesn't help us in situation where an old rule turns bad for some reason,
> such as our little "Y2K10" rule issue from January 1 last year.  In cases such
> as those (which I expect to be much fewer in occurence then the "new bad
> update" described above) we'll need to create and release a new update.  I'll
> work on this case next.  I think one possible way I may do it is that you
> supply a patch to the revert script for it to apply to an existing update (the
> script would unpack the existing update, patch it, pack it back up and re-sign
> it).

I consider this solution as a good interim measure suitable to move this bug to a target of 3.4.0.  Do you agree?
Comment 13 Daryl C. W. O'Shea 2011-05-28 17:40:28 UTC
Retargetting to 3.3.3 so it stays on my radar.
Comment 14 Mark Martinec 2011-09-23 23:44:44 UTC
Retargetting to 3.4.0, now that 3.3.3 is off the scope.
Comment 15 Kevin A. McGrail 2011-10-28 21:39:37 UTC
Retargeting to 3.4.1 to release 3.4.0.  However, this should get fixed before the next time when it's needed in a pinch.
Comment 16 Kevin A. McGrail 2015-04-13 21:49:12 UTC
Pushing off a specific release since this doesn't require a release for a rules update change.