java/code/src/com/redhat/rhn/frontend/events/SsmUpgradePackagesAction.java | 24 +++++++++- 1 file changed, 22 insertions(+), 2 deletions(-)
New commits: commit 7e563acb0e8775e23d00d9a7464f165399452fd9 Author: Jason Dobies jason.dobies@redhat.com Date: Wed Aug 12 16:18:36 2009 -0400
517076 - Added association of servers in the SSM to the package upgrade task log. See comment in the code for more information.
diff --git a/java/code/src/com/redhat/rhn/frontend/events/SsmUpgradePackagesAction.java b/java/code/src/com/redhat/rhn/frontend/events/SsmUpgradePackagesAction.java index fc354bc..5647b81 100644 --- a/java/code/src/com/redhat/rhn/frontend/events/SsmUpgradePackagesAction.java +++ b/java/code/src/com/redhat/rhn/frontend/events/SsmUpgradePackagesAction.java @@ -29,6 +29,7 @@ import com.redhat.rhn.domain.user.User; import com.redhat.rhn.domain.user.UserFactory; import com.redhat.rhn.manager.action.ActionManager; import com.redhat.rhn.manager.ssm.SsmOperationManager; +import com.redhat.rhn.manager.rhnset.RhnSetDecl;
/** * Handles removing packages from servers in the SSM. @@ -46,9 +47,28 @@ public class SsmUpgradePackagesAction extends AbstractDatabaseAction { SsmUpgradePackagesEvent event = (SsmUpgradePackagesEvent) msg; User user = UserFactory.lookupById(event.getUserId());
+ /* The following isn't 100% accurate. All systems in the SSM are associated + with the operation, however only systems on which the package already exists + (since this is an upgrade) will actually have events scheduled. + + The problem is that the list of servers to which the package upgrades apply + is never stored in an RhnSet, which is used to make the impact of this call + minimal. The correct list is showed to the user before selecting confirm, + so the only potential issue is in viewing the SSM task log after the user + has confirmed the operation. Again, the events themselves are correctly + scheduled on only the systems to which they apply. + + For now, this small potential for logging inaccuracy is acceptable given the + proxmity of this fix to the Satellite 5.3 release (as opposed to omitting + the server association to the task entirely). + + jdobies, Aug 12, 2009 + */ + LocalizationService ls = LocalizationService.getInstance(); - long operationId = SsmOperationManager.createOperation(user, - ls.getMessage("ssm.package.upgrade.operationname"), null); + String operationMessage = ls.getMessage("ssm.package.upgrade.operationname"); + long operationId = SsmOperationManager.createOperation(user, operationMessage, + RhnSetDecl.SYSTEMS.getLabel());
// Explicitly call handle transactions here so the operation creation above // is persisted before the potentially long running logic below