[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'm a 100% with you for those two scenarios!

The current implementation is silly 'cause the install and configure phases
are merged. As a goal of this milestone, we want to introduce a "configure"
phase (and maybe others based on what other provisioning story have
defined)
Do you want to take on this task (adding configure phase) to get yourself
wet with the code? It will touch on a little bit of everything with being
too crazy.

PaScaL



                                                                           
             James D Miles                                                 
             <jdmiles@xxxxxxxx                                             
             om>                                                        To 
             Sent by:                  Equinox development mailing list    
             equinox-dev-bounc         <equinox-dev@xxxxxxxxxxx>           
             es@xxxxxxxxxxx                                             cc 
                                                                           
                                                                   Subject 
             08/16/2007 04:50          Re: [equinox-dev] [prov]            
             PM                        Ruminations on IDirector    vs.     
                                       ProvisioningHelper-like entity      
                                                                           
             Please respond to                                             
                  Equinox                                                  
                development                                                
               mailing list                                                
             <equinox-dev@ecli                                             
                 pse.org>                                                  
                                                                           
                                                                           




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.

(Embedded image moved to file: pic12115.gif)Inactive hide details for "Tim
Webb" <tim@xxxxxxxxxx>"Tim Webb" <tim@xxxxxxxxxx>

                                                                           
                         "Tim                                              
                         Webb"                                             
                         <tim@trwe                                         
                         bb.com>   (Embedded image moved to file:          
                         Sent by:  pic21578.gif)                           
                         equinox-d                                      To 
                         ev-bounce            (Embedded image moved to     
                         s@eclipse            file: pic10629.gif)          
                         .org                 "Equinox development mailing 
                                              list"                        
                                              <equinox-dev@xxxxxxxxxxx>    
                         08/15/200 (Embedded image moved to file:          
                         7 08:51   pic29525.gif)                           
                         AM                                             cc 
                                              (Embedded image moved to     
                                              file: pic16769.gif)          
         Please respond to         (Embedded image moved to file:          
 Equinox development mailing list  pic10176.gif)                           
     <equinox-dev@xxxxxxxxxxx>                                     Subject 
                                              (Embedded image moved to     
                                              file: pic25365.gif)          
                                              Re: [equinox-dev] [prov]     
                                              Ruminations on IDirector vs. 
                                              ProvisioningHelper-like      
                                              entity                       
                                                                           
                                                                           
                                   (Embedded image moved to file:          
                                   pic27181.gif)                           
                                          (Embedded image moved to file:   
                                          pic30639.gif)                    
                                                                           
                                                                           



More below...

On 8/15/07, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> 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" <tim@xxxxxxxxxx>                                              ( 
 Sent by:                                                                 E 
 equinox-dev-bounces@xxxxxxxxx                                            m 
 rg                                                                    To b 
                                       "Equinox development mailing list" e 
                                       <equinox-dev@xxxxxxxxxxx >         d 
 08/14/2007 05:35 PM                                                   cc d 
                                       (Embedded image moved to file:     e 
                                       pic32347.gif)                      d 
                                                                  Subject i 
       Please respond to               Re: [equinox-dev] [prov]           m 
  Equinox development mailing          Ruminations on IDirector vs.       a 
            list <                     ProvisioningHelper-like entity     g 
   equinox-dev@xxxxxxxxxxx>                                               e 
                                                                          m 
                                                                          o 
                               (Embedded image moved to file:             v 
                               pic29224.gif)                              e 
                                       (Embedded image moved to file:     d 
                                       pic24976.gif)                      t 
                                                                          o 
                                                                          f 
                                                                          i 
                                                                          l 
                                                                          e 
                                                                          : 
                                                                          p 
                                                                          i 
                                                                          c 
                                                                          0 
                                                                          8 
                                                                          8 
                                                                          3 
                                                                          6 
                                                                          . 
                                                                          g 
                                                                          i 
                                                                          f 
                                                                          ) 
                                                                            




      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


      _______________________________________________
      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
(See attached file: pic10938.gif)
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Attachment: pic12115.gif
Description: GIF image

Attachment: pic21578.gif
Description: GIF image

Attachment: pic10629.gif
Description: GIF image

Attachment: pic29525.gif
Description: GIF image

Attachment: pic16769.gif
Description: GIF image

Attachment: pic10176.gif
Description: GIF image

Attachment: pic25365.gif
Description: GIF image

Attachment: pic27181.gif
Description: GIF image

Attachment: pic30639.gif
Description: GIF image

Attachment: pic32347.gif
Description: GIF image

Attachment: pic29224.gif
Description: GIF image

Attachment: pic24976.gif
Description: GIF image

Attachment: pic08836.gif
Description: GIF image

Attachment: pic10938.gif
Description: GIF image