Pascal, Thanks for the thoughts. This definitely gives me some further fodder for my investigation. Regarding the having an Engine that is used Server-side that relays to the client, I'm not sure how the current implementation would be used to accomplish that. Wouldn't the Engine need to be per-request in the case where a server is managing many systems? If so, the install and uninstall operations would need to be designated the corresponding Engine for the appropriate request. Or... Is there going to be a way to instantiate a different director per-request? If so, are we planning to expose an API for the "standard" Director that would allow specification of the corresponding Engine?
Tim On 8/14/07, Pascal Rapicault <[EMAIL PROTECTED]> wrote: > For the director / engine interaction here are some notes: > - The Engine is API and one could decide to directly invoke it. > - Currently the director is really simplistic and is far from being > complete. Also this implementation is not opened and it is normal that you > don't see what you are looking for. > - When Jeff says no change to the director, he refers to the fact that the > director could be reused on the server (maybe after some refactoring of > the > current code) but he does not exclude the presence of a "proxy director" > on > the client. For example one could imagine that on the server there would > be > a full blown director and an Engine. This Engine would be a proxy engine > whose responsibility would be to send back actual commands to the engine > running on the client. Therefore the flow would go as follow: > - the proxy director on the client is invoked for installation > - it contacts the director on the server which generates the list of > instructions, > - the list of instructions is given to the server engine which streams > those to the engine > - this client engine receives the instructions and executes them. In this > case the communication client / server is an implementation detail of your > client. > - In the previous description, the proxy director could be aware of a > local > director to fallback on when running in disconnected mode. > - Other pieces of the agent infrastructure are expected to be pluggable > such as local stores, registries, etc. > > HTH > > PaScaL > > > > > > "Tim Webb" > <[EMAIL PROTECTED]> > Sent by: To > equinox-dev-bounc "Equinox development mailing list" > [EMAIL PROTECTED] <[email protected]> > cc > Maya development mailing list > 08/14/2007 02:55 <[EMAIL PROTECTED]> > PM Subject > [equinox-dev] [prov] Ruminations on > IDirector vs. > Please respond to ProvisioningHelper-like entity > Equinox > development > mailing list > <[EMAIL PROTECTED] > pse.org> > > > > > > > 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_______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev >
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
