[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] [prov] Ruminations on IDirector vs. ProvisioningHelper-like entity

I am still working to get up to speed. I am still a little confused by the operations and phases so I may not be totally in sync on terms here.

One of the options should be:

We should be able to fetch and install (not configure) the new requirements in the background. The user does not necessarily need to know or care except as a general policy decision. If we have a broken download connection on a mobile device, we just restart on the artifact that did not finish. This scenario might not work for large downloads on a storage constrained device but even then should work for minor updates.

Once every requirement is met (installed) the user can be prompted for when to configure. The configure phase should not take long at this point. It seems to me that this is also an argument for treating configure and install as separate operations and not treating everything as a phase of install.

Inactive hide details for "Tim Webb" <tim@xxxxxxxxxx>"Tim Webb" <tim@xxxxxxxxxx>

          "Tim Webb" <tim@xxxxxxxxxx>
          Sent by: equinox-dev-bounces@xxxxxxxxxxx

          08/15/2007 08:51 AM

          Please respond to
          Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>



Re: [equinox-dev] [prov] Ruminations on IDirector vs. ProvisioningHelper-like entity

More below...

On 8/15/07, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
My reference to the Engine was specifically due to what I saw in the current implementation where the Director instantiates an Engine. I was concerned that structuring it like this would mean that that single engine would need to be able to determine which response corresponds to which client's request. Should Director-level install / uninstall requests be assigned an identifier to allow for this correspondence? Having an identifier may also help in logging when you have multiple changes being requested to a system in parallel. All that said, I completely agree that the Director shouldn't need to know that an Engine is remote, local, or some other relayed style Engine.

Perfect way to summarize the hybrid issue.

Is it fair that a Governer might be able to say "you must have software A, B and C with versions X, Y and Z respectively? Then the local director would be responsible for determining what modifications including potential software removal would be required to execute the constraints imposed by the Governer. In the Maya case, what the Governer states as the Profile's base requirements would be what we currently have in Maya as a Profile -- let's call it a Profile Template. Our data model in Maya also allows for software exclusion rules and again, this does seem to resonate better with the roles of a Governer than a Director. The Governer could tell the Director that software J can never be installed on a system.

Now from a UI point of view having a Governer raises some interesting concerns as well. For example, if the Governer will never allow software J to be installed, could we optimize the UI and not show this to the user? Similarly, if the Governer dictates a range of software that can be consumed, can we filter out other versions from view? Ideally when running with full or partial governance we will still be able to leverage the same Director and Update UI for consistency from the user's perspective.

More thoughts on the Governer below...

I should mention that one round trip to the governance? server would be preferred. There certainly may be many roundtrips to the distributed meta and artifact repositories in processing those operations. How optimized and how many requests are made may certainly be optimized by a custom meta repository but that's a second-level optimization at this point.

Yes, I'm happy with the sort of data being modeled in the operands I saw. I do believe we will need to leverage those operands for other functions such as indicating product configuration priorities (which product is the primary one), but yes, the general idea of the operands seems to address the needs.

While thinking through the Governer some more, here are some thoughts on what I could see us needing from this service.

interface IGoverner
public ProfileConstraint[] getConstraintsForProfile(Profile profile, IProgressMonitor monitor)
throws CoreException;
public IStatus validateInstall(Profile profile, InstallableUnits[] installRoots, IProgressMonitor monitor);
public IStatus validateUninstall(Profile profile, InstallableUnits[] uninstallRoots, IProgressMonitor monitor);
public IStatus validateOperands(Profile profile, EngineOperation operation, IAdaptable operands, IProgressMonitor monitor);

The definition of ProfileConstraint is still a bit vague in my mind, but I could imagine functions that validate if a Profile is currently meeting the requirement, a way to get back information from the specific requirement type, and a way to use the requirements as a way for the IDirector to seed the creation of a new Profile. My first thought was that this would need to be a new ProfileConstraint object; however, upon reflection it may be that the Governer is simply returning a set of RequiredCapabilities to be used by the Director / Engine. Doing this will require leveraging RequiredCapabilities to have exclusion rules in addition to the current uses.

One thought that comes to mind would be having the Governer's rules be installed as an InstallableUnit on the Profile. This would allow the Governer to be able to cache the rules applicable to a given Profile directly in the Profile, but more importantly, this would allow automatically injecting those rules into the Director / Engine flow without much (any) modification of the logic.

"Tim Webb" <tim@xxxxxxxxxx>
Sent by:

08/14/2007 05:35 PM

Please respond to
Equinox development mailing list <
"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx >
Re: [equinox-dev] [prov] Ruminations on IDirector vs. ProvisioningHelper-like entity

equinox-dev mailing list

GIF image

GIF image

GIF image