Community
Participate
Working Groups
Currently the UI does nothing to prevent a user from initiating several provisioning operations at once (install A, update B, uninstall C, etc.) It just starts a job for each provisioning operation. Is this safe? Do we need scheduling rules to queue these up?
The engine has some basic locking to protect itself, but we should have scheduling rules to improve the end user experience. Currently the subsequent operations would start and then immediately be blocked. With a scheduling rule, the job wouldn't even be started until the profile rule was available. Simply making IProfile extend ISchedulingRule is likely sufficient.
Agree. The implementation of the scheduling rule in Profile would need to based on the profile id, since the profile instances themselves are just snapshots in time.
*** Bug 236493 has been marked as a duplicate of this bug. ***
status update: In 3.4, we ended up having the p2 UI prevent the user from performing simultaneous provisioning operations. It does this by registering all jobs that modify a profile with a utility class, and the various buttons in the UI consult this class to see if a job is already running. They will remain disabled if a job is already running. This is not ideal, as it's not clear to the user why they can't perform the operation. Note we would have to resolve a profile change request just before running the operation, rather than resolving it when the user first requests it.
(In reply to comment #4) > status update: > In 3.4, we ended up having the p2 UI prevent the user from performing > simultaneous > provisioning operations. It does this by registering all jobs that modify a > profile with a utility class, and the various buttons in the UI consult this > class to see if a job is already running. They will remain disabled if a job > is already running. This is not ideal, as it's not clear to the user why they > can't perform the operation. > > Note we would have to resolve a profile change request just before running the > operation, rather than resolving it when the user first requests it. > We are doing a bit better in 3.5 as of M4, per bug 258132. We now catch this case in the wizard and explain to the user that another install operation is already running. We also invalidate any precomputed plans so that if the operation were to finish while the user is in the wizard, the resolution would have to be performed again.
per discussion with Pascal, the UI stopping these cases is enough and we aren't planning any core work to address this feature.
By the core work you mention I'm guessing you mean the scheduling work. As John mentioned the engine will protect against parallel provisioning operations at that level. I think we can close this.
