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

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

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.

- 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?

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.

- 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.

- 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?  

Jeff

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

08/14/2007 05:35 PM

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

To	"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
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 <Pascal_Rapicault@xxxxxxxxxx>
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"
             <tim@xxxxxxxxxx>
             Sent by:      
                     
                     
To 
             equinox-dev-bounc    
    "Equinox development mailing list"
             es@xxxxxxxxxxx
           <equinox-dev@xxxxxxxxxxx
>
                    
                     
                     
       cc
                    
                  Maya development
mailing list
             08/14/2007 02:55    
     <
maya-dev@xxxxxxxxxxx>
             PM        
                     
                     Subject
                    
                  [equinox-dev]
[prov] Ruminations on
                    
                  IDirector
vs. 
             Please respond to    
    ProvisioningHelper-like entity
                  Equinox
                development
               mailing list
             <equinox-dev@ecli
                 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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev