Community
Participate
Working Groups
In discussing the implementation of iu profile-dependent properties in bug #204823, we wondered if there should be a explicit profile-delta that appears in a provisioning plan. In this way, the knowledge that an IU was a profile root could be applied to an update of that IU. We wonder if there are other cool use cases for such a concept. Characteristics of this approach are: - a provisioning plan not only describes the operands, but also any deltas that should happen to the profile - there is a "profile update" phase in the engine that applies this delta at the proper time during an update This eliminates the strange timing we have now where the profile registry applies profile-dependent properties for an IU before the IU is actually installed in the profile.
Another cool use case is the ability to change values in the profile in a batch'ed way whereas today the API to set or modify values is really awkward and to be done properly would require a notion of locking or sessions. Now with a ProvisioningPlan that would contain a profile delta, the changes to the profile could just be done against this object, and then be given to the engine for application. This would also streamline remote management scenarios where a complete profile description could be given to the engine. And the last nice thing is it would gives us more flexibility for future API evolution.
I've just had to hack a Profile.CHANGED event to inform listeners that a profile's IU property changed. This is needed so that listeners such as the "What's Installed" page get notification when a profile root is established. The trigger is currently in Profile.setInstallableUnitProfileProperty(...) which is not the ideal place, but I didn't want to permeate event sending right now. I think the right thing to do would be to send a Profile.CHANGED event whenever a Profile delta is applied.
See also bug #197701. These aren't duplicates, but if we do profile deltas, it would be a good time to address this one, also.
Do we want to do something about this. I noticed that the setInstallableUnitProfileProperty(...) will end up causing the install registry to persist these values directly. If at all possible I'd like to reserver the step of persisting to when we commit down in the engine. Could we do the setting of these IU/Profile properties in an action in either the configure or install phase? Likewise, does would it make sense to remove these properties during uninstall/unconfigure.
I would definitely like to see this fixed...it's a hack. I recently added the persist code on profile change because on initial install, the roots property isn't set until after the commit event. (On update, the root marker property gets transferred to the updated IU before the commit, so things persist properly). When I first prototyped different approaches for marking IU's as profile roots, I had a timing problem with the current phases. For example, during an update, the profile root should move from the removed IU (operand 1) to the new IU (operand 2). During the unconfigure phase of operand 1, operand 2 is not yet there so we can't transfer the property. We would need to store some temporary information so that by the time we configure operand 2, we know that we need to mark it. This seemed kind of weird to us, so we talked about there being a profile delta phase that occurred after all of the IU work was done. This could be the last thing done before a commit? The main issue is that knowledge of both operands is needed to do the work.
(From bug #205223) - One thing that might be nice in a profile delta is being able to have the client that performs a provisioning plan add a description of the change to the delta. This could be used by the revert UI to further describe the change to the user. I'd also like to see the install root markers included in a profile delta handed to the engine rather than having them set explicitly beforehand. So, for example, when installing "releng" (and all the IU's that it requires), the caller would include in the provisioning plan a profile delta that set a description to "Installed releng" and then instructed the engine to set a root marker on the "releng" IU.
For M4 we're doing our various property changes directly in a snapshot of the Profile. This still doesn't feel right and I agree that we want to separate property changes out into something like a ProfileDelta or at least providing someway to represent these property changes consistent with how we do iu changes. Moving to M5
I've taken a first stab at the following: - what a description of a profile delta (ProfileChangeRequest) looks like - definition of a ProvisioningContext, which is basically an object that holds the URL [] of metadata repos (allowing for future expansion of the context object) - definition of PropertyOperand and inclusion of these operands into the provisioning plan - changes required to IPlanner and IDirector as a result - rippling changes in the tests, director app, UI, etc. - what the format captured in FormerState looks like so that the profile properties can be saved/restored I've marked TODO in places where things are not ideal. My main concerns are: - knowledge of property reading/writing for snapshots is shared between FormerState and SimplePlanner. A proper reader/writer would be nicer. In addition, the method of storing the properties is pretty bogus, they are crammed into the properties of the snapshot IU, including some ugly pre/post fixing of IU properties. Pascal suggested using fragments may be a better way of storing things like IU profile properties. Also, I casually replaced IPlanner.getInstallPlan, getUninstallPlan, getReplacePlan with getProvisioningPlan by reusing the implementation of getReplacePlan. I didn't look for special cases that might have been in the old install and uninstall methods. Still to be done: - engine should honor the property operands - Profile API should be modified so that property setting is not done on profile instances - Review profile registry and profile API in light of these changes. For example, ProfileRegistry.updateProfile(profile) should probably go away. Simon, it's your turn now. Feel free to change the operands to anything that works for you. The code can be found in the branch "profile_deltas" of the following projects: p2.console p2.director p2.director.app p2.engine p2.tests p2.ui p2.ui.sdk
I've checked my bit into the branch and done a resynch with HEAD and made sure the automated tests work. We can look at bringing this code into HEAD tomorrow. There is still quite a bit of API tidy up to do however I think we no longer need a branch for that. The list of projects in the branch has now grown slightly so includes the following: console director director.app engine reconciler.dropins tests touchpoint.natives ui ui.sdk As an aside... I think the branch worked well for doing this sort of collab effort -- I'd use it again.
I've merged the branch into HEAD now and again run the regular test pass, did an install, ran the admin ui etc. There is still a lot of API work to force profile changes through the engine. For now I've renamed all the various setters in the profile to include internal. This is a strong hint not to use these methods as eventually they will go away. We can track the profile modification api changes in bug 212336. We have a ProfileChangeRequest to work with the planner. I'd like to leave this bug open to consider using a similar profile delta when talking to the engine.
Marking FIXED. The changes in the Engine API around Operands is done. The Engine.perform method has gone full circle and is back to where we started however Operands can now represent property changes as well as IU changes. There are still API changes related to passing ProvisioningContext in as well as the Profile/ProfileRegistry changes Susan mentioned however those are tracked in other bugs reports.
