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(a)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
Show replies by date