More below...
On 8/15/07, Jeff McAffer <[EMAIL PROTECTED]> wrote:
>
> Some thoughts accumulated in reviewing this thread...
> - For clarity of discussion, we should ignore "proxy" objects unless they
> have some smarts, in which case they are not proxies. That is, if the
> Director is on the server and the Engine on the client, the fact that the
> server implementation may or may not need a local instance of Engine is
> immaterial. It may be an RMI proxy, something custom or the director may
> open a socket and stream commands directly to some port on the client.
> Doesn't matter. There is no Engine logic on the server. This is just
> distributed programming.
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.
- With that in mind, the hybrid case Tim raises is interesting. The real
> question is not around client/server but around "how many directors are
> there". Either you have only one (doesn't matter where) or you have
> multiple cooperating in a hierarchy or mesh like structure.
> 1) If you have one then it is driving the policies and choices but needs
> to take into account multiple inputs to the profile definition. this is
> somewhat like our shared configurations today. There is a config and a
> parent config. We have hardcoded rules about the relationship between them
> (precedence etc). The "director" that is integrated into the Framework
> knows how to read these configs, merge them and implement the result. One
> could see the same thing happening in the hybrid case Tim described.
> 2) If you have multiple then we need some CooperatingDirector structure
> that defers some decisions to others and/or asks questions of others and
> merges results. For example, rather than just reading the profile data, a
> CooperatingDirector might ask its friend Directors for what they think is in
> the profile. Ultimately someone has to be in charge and be responsible for
> merging and making the final decisions/choices. It feels like policy choice
> as to whether that is done on the client or the server (in the hybrid case).
> Tim, you seem to have described something along these lines right?
Perfect way to summarize the hybrid issue.
One thing to remember is our discussion at the workshop around Governors. I
> recall that we were looking to defer alot of these sorts of policy decisions
> to the Governor. Using this approach you can do #1 from above where the
> Director (wherever it is) reads information from wherever is needed and
> merges/processed it according to a single Governor. The Governor itself may
> be here or there but it is driven by a set of policy
> files/preferences/settings etc.
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...
- the goal of one round trip to figure out what to run is great. in the
> more cooperative hybrid cases though it is not clear how that is going to
> happen. If there are things to merge, someone has to do the merging. So
> either A has to tell B all things that might be needed to do the
> merging/computation or vice versa. Once the decisions are made, there will
> be further roundtrips to execute on the decisions.
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.
- Tim, you mentioned " To accomplish this, we will need a way of describing
> the operations to be performed and then have a way to encode / decode them."
> Currently we seem to tell the the Engine a set of operands (pairs of IUs in
> old/new state) and a set of phases to run through. I'm not particularly
> happy with the vagueness around the use of IAdaptable in the API but modulo
> that, do you see anything different needed?
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
> *"Tim Webb" <[EMAIL PROTECTED]>*
> Sent by: [EMAIL PROTECTED]
>
> 08/14/2007 05:35 PM Please respond to
> Equinox development mailing list <[email protected]>
>
> To
> "Equinox development mailing list" <[email protected]> cc
> Subject
> Re: [equinox-dev] [prov] Ruminations on IDirector vs.
> ProvisioningHelper-like entity
>
>
>
>
> 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]<[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] <[EMAIL PROTECTED]>>
> Sent by: To
> equinox-dev-bounc "Equinox development mailing list"
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> <[EMAIL
> PROTECTED]
> * <[email protected]>>
> cc
> Maya development mailing list
> 08/14/2007 02:55 <* [EMAIL PROTECTED]<[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* <http://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] <[email protected]>*
> **https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
>
>
> _______________________________________________
> equinox-dev mailing list*
> [EMAIL PROTECTED] <[email protected]>*
> **https://dev.eclipse.org/mailman/listinfo/equinox-dev*<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
>
>
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
