I scheduled a resource group operation for 2 JBoss AS servers. I can view the scheduled operations in the Group's operation tab. However, I can NOT view the scheduled operations in an individual Resource's (who is part of the group) operation tab. I would expect that I can -- particularly because I can see an Alert Template-defined alert in an individual resource
templates are slightly different than groups. it was always the intention to allow people to change the alert definitions that create created from alert templates. however, i think it would be quite a bit more dangerous to allow the same for group operations. perhaps a nice middle ground here would be to show a ready-only copy of the schedule as defined by the group.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-432
Some background: When you look at schedule operations for a resource, you are only seeing operations that have been explicitly scheduled on that resource and are persisted against that resource in the database. In other words, you won't see operations that were scheduled at the group level. Possible fixes: 1) When creating a group-wise operation schedules, also create the resource schedule children. * the API for retrieving the operation schedules at the resource-level doesn't need to be updated, because the schedules persisted against that resource will come from both the explicit resource-level as well as the trickled-down group-level * the group-wise API implementation now requires managing the children schedules. so, again, during group schedule creation, the children schedules need to be created. during group schedule deletion, the children schedules need to be deleted. above and beyond that, we have to worry about whether we should allow a user to modify a resource schedule that was created via group-schedule trickle-down, as well as any finer points introduced by the allowance of such. * note: the group operation would no longer "control" the resource-level operations because the schedules would be independent. so additional logic would be added to reinforce this relationship, so that serialized semantics (execute operations in the order the resources were specified) could still be upheld. 2) When viewing the list of resource-wise operation schedules, compute the effective list of schedules on-the-fly. * the group-wise API implementation wouldn't have to change at all * the resource-wise API would have to be modified to, at the time of the request, look at all groups that resource is currently in and add to the result set any operation schedules also at the group-level. * since these "effective" scheduled operations don't actually exist at the resource-level yet, editing them is not possible, but users might think it's plausible (thus, this might be a usability issue) * note: if the resource is in a large number of groups, this on-the-fly calculation could be a performance penalty. also, because these "ghost" schedules (the ones trickled down from the group) are not actually persisted, pagination would be an increasingly complex thing to manage here (which could be mitigated if we changed the API to **always** return all schedules instead of a paginated set)
Closing as outdated