[equinox-dev] [prov] Ruminations on IDirector vs. ProvisioningHelper-lik

["Tim Webb" <tim@xxxxxxxxxx>]

Bare with me -- a few issues to get through...

Currently the IDirector interface has two methods : install and uninstall.  In looking through the code of ProvisioningHelper and IDirector (SimpleDirector) I'm not sure as to the right way to describe to the user the series of operations that would be performed in installing software X prior to actually initiating the installation.  I could duplicate similar code to what is found in SimpleDirector using the ProfileInstallRegistry and DependencyExpander to determine what would be required -- however, this seems to be duplicating a significant amount of logic.  Would it make sense to add to IDirector a call that would expand a given set of installRoots to the series of ProvisioningOperands that would be required?  Such as...

interface IDirector
{  
    ....
    public IStatus describeInstall(InstallableUnit[] installRoots, Profile profile, ProvisioningOperandCollection operands, IProgressMonitor monitor);
    public IStatus describeUninstall(InstallableUnit[] uninstallRoots, Profile profile, ProvisioningOperandCollection operands, IProgressMonitor monitor);
}

Separately, who would be responsible for determining an upgrade vs. install operation?  The current implementations of SimpleDirector and NewSimpleDirector seem to assume that the software is an install.  Is it safe to assume that with time the default IDirector implementation will be able to handle determining when an Update should be performed instead of an Install?  

As it turns out, in potentially using the Director server-side in Maya, we need to be able to return the operations that need to be performed back to the client.  In addition, we may wish to show to the user what the impact of performing a given operation would be prior to actually having the user perform it.  In discussions with Jeff I understand that it is preferred to leave the current director implementation in-tact without requiring each way it is consumed to implement a new director.  Given this desire, we're going to want to find a way to encode the operations to be performed into an XML description to deliver back to the client.  To accomplish this, we will need a way of describing the operations to be performed and then have a way to encode / decode them.

Approaching the issue another way, in the best case usage, the Maya provisioning client connects to the server exactly once.  It requests the instructions to be used in ensuring it has the right software.  If we were to attempt to switch the IDirector to be behind an RPC-type facade, we will need at least two connections to the server -- one to get the list of InstallRoots and a second to tell the Director to install.  Currently, we couldn't do this since the IDirector assumes it knows where the engine is -- passing the engine in as a parameter would help allowing the director to be remote from the executing engine.  Next, in some situations the user in a Maya installation may wish to install software locally.  Depending on the policy / governance configuration, I could imagine this operation being performed without contacting the server - requiring a functioning local director, however, for some deployments you may need to contact the server to determine if you are allowed to perform the requested task.  In this mode, having the IDirector as an RPC may be required.   The exact policy might even be based on what the requested install actually entails.

Assuming all of this is makes some sense, how would you avoid having to reimpement the IDirector implementation?  One option would be to have a GovernanceAwareProxyDirector (I know, horrible name), that would be able to decide if it just defers to the standard local Director implementation or leverages the server-side Director to determine the operations to be performed.  When it contacts the server-side director, it might receive back a serialized form of the provisioning operands.  Using this list of operands, it could then directly contact the local engine or potentially call the standard simple director assuming it had another function such as:

interface IDirector
{  
    ....
    public IStatus executeOperands(IAdaptable operands, IProgressMonitor monitor);
}

Now I don't suggest adding such an operation is an ideal solution -- but I am curious if we want to expose to someone other than the director direct access to the engine.  If not, then I'm struggling a bit in how to best balance the needs of a hybrid deployment where you sometimes use a local director and then occasionally have to call out to a remote director.  

As I write this all out, the more I feel that the entity running on the server is potentially not a standard Director but is Director-like.  I like the idea of keeping a local director always running even when deferring some operations to a server-side component to augment the processing.  The benefit to always having the client-side director is that it can ensure consistency of the local system for instance when there is software installed locally that is not tracked by the central server -- the server-side resolution would check software within it's domain are correctly configured for the client including executing various policy decisions but the client-side director would handle resolution to determine if the software not known to the central server is still valid.

Phew.

Tim