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

[Susan M Franklin <susan_franklin@xxxxxxxxxx>]

For M2, I'd like to see us support "Simple"
but also another user, "Curious, yet Afraid."  Maybe that's
just a nicer way of describing your 4-year-old.
To support this, I think we just need
to be able report estimated size/time and also a list of what else is coming
along because of the request (a little of the "why").

For the simple user, size/time is enough.
 The user was told to install Foo, maybe they got an email, or the
system told them they need to update.  They are going to do it because
they are supposed to, and just want to know if it's a big deal.  Should
they do it now or later.

A slightly more curious user may want
to get an inkling of "how heavyweight is this request" (size/time)
with a little bit of "why".  The use case I'm imagining
is that I heard my teammates talking about the cool Foo plug-in/feature/whatever.
 I want to know what they are talking about and I'm curious enough
to install it, but slightly afraid.  So I look for it and, gee, it
has a cute icon, it's relatively small, I think I'll install it.  But
once I find out that it's going to bring a bunch of stuff with it, I get
scared and decide that I probably don't want it. 

That's where the list of IU's may come
in handy, and we have to know it to report the other info.

susan

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx 08/15/2007 05:32 AM Please respond to Equinox development mailing list

To:        Equinox development mailing list <equinox-dev@xxxxxxxxxxx>         cc:                 Subject:        Re: [equinox-dev] [prov] Ruminations on IDirector vs.        ProvisioningHelper-like entity

Perhaps we should agree on some workflows/user types that can drive this
discussion. 

-  Simple: For simple users/flows there are not that many choices.
 They say they want to use Foo and the Director and friends determine
if all prereqs are available.  Either they are or they are not.  If
the request is possible, they'd probably like to know if it is time to:
a) take a bite of a donut, b) go get some coffee, c) have a bio break with
that, d) head out for lunch or e) go home.   If the request is not
possible, it can be suggested that the user go off and find another repo
that knows about the missing bits but beyond that they are SOL.  We
have searched the known universe and come up empty handed.  There
is also a conflict case where installing Foo is possible but only if Bar
is changed/removed.  This gets a bit advanced for these users.  A
very carefully worded simple question needs to be asked (e.g., "How
much do you want to use Foo?  Rank on a scale from life threatening
to I thought it might be interesting") 

- Moderate: In more advanced cases users say they want to use Foo and are
happy to have the system figure stuff out but once things are ready to
go, they want to snoop and have veto power.  They want to know "why".
 These are the "backseat Directors" or, for those of you
with kids, "Four-year-old Directors".  These are dangerous
people.  They want to know everything but at the same time, don't
want to have to know everything.  They are pissed off by known unknowns
and when they do know something they want to be able to change it.

- Advanced:  Like the moderate users, advanced users are curious and
somewhat controlling.  The difference is that they are more receptive
to button clicks and work.  They really do want to see exactly why
version X was choosen to when they know repo Y is so much more cool, why
artifact A is coming from repo W, ....  These people are like driving
instructors.  They are there with you in the car and have a duplicate
set of controls and that funky rear-view mirror.  They can take over
at the drop of a hat. 

- Extreme:  Then there are the extreme power users.  For them,
no amount of control is too much.  They want to BE the Director and
Engine.  We should just open an XML editor and let them craft the
messages that are sent back and forth ;-)   

So what does this all have to do with the current discussion.  Well,
IMHO the M2 user should be Simple.  They need a bit of feedback on
what's going on but for the most part no news is good news.  Computing
the size/time requirements seem like the most pressing matter.  I
wonder if this is something we can do with a sort of "dry run"
where the director and engine do their thing to figure out exactly what
"would" happen but stop short of actually doing it.  The
UI can then interrogate the results to see how much download there was,
time that would have been needed, ... and report that to the user.

This is not to say that the planning object discussed is not needed but
rather the information it provides is more useful in the moderate to advanced
usecases.  Other scenarios that will need this kind of function are
editing (validation, checking, ...), sys admin operations (simulate, validate
designs/jobs) etc.  I agree with Tim that we should look to separate
out the building blocks needed to implement these functions.  

Jeff 

p.s., not sure quite how useful any of this was but it was kinda fun to
write...

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

08/14/2007 09:00 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

Sounds good.  So if we can have an Oracle that returns a ProvisioningDeltaDescription
or whatnot that describes the various actions that would be performed.
 By having this as another object, we can provide additional services
to help describe in a human-readable format the operation as well as in
machine-understable styles to allow serialization.  What would the
input to such a function be?  Would you still use a full Profile or
would you use a ProfileDescription object that can be accessed off of a
Profile?  Having it as a separate object may also again further user-understandable
descriptions of the interface. 

Tim

On 8/14/07, Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
wrote: 
If only we could have a console as a UI... I'm really amazed by the
requirements the UI put ;-)
I agree that it is interesting / mandatory to be able to show disk space
and things like that, however ProvisioningOperand is wrong thing to base
a 
UI on since it contains the information to drive an engine and this will
likely be more detailed than what we have now (Simon is working on a new
API for the engine).

As for the code code, the oracle I have in mind will share code with the
director to ensure consistency.




            "Tim Webb"
            <tim@xxxxxxxxxx>
            Sent by:      
                     
                     
To 
            equinox-dev-bounc    
    "Equinox development mailing list"
            es@xxxxxxxxxxx
           <equinox-dev@xxxxxxxxxxx
>
                    
                     
                     
      cc

            08/14/2007 05:32    
                     
           Subject
            PM        
               Re: [equinox-dev]
[prov] 
                    
                 Ruminations
on IDirector vs.
                    
                 ProvisioningHelper-like
entity
            Please respond to
                 Equinox
               development 
              mailing list
            <equinox-dev@ecli
                pse.org>






Pascal,

I could see a benefit to knowing the full set of operations since some
users don't want their system changed without understanding the impact.
More importantly, it is interesting to be able to show users information
such as the amount of data that will be downloaded as a result of X, being
able to calculate needed disk space before performing the operation, and
letting the user know that selecting that one little feature caused 200mb
of extra stuff to be included.

The issue I see is that a lot of the interesting information ends up 
following many of the same paths that are currently used in the Director.
Instead of duplicating that code into another object called an Oracle,
might it make sense to pull some of that logic out of the Director into
a 
shared object?  Whether it's called an Oracle or not, I think there
should
be one set of code that determines the set of operations to be performed,
and I don't believe that we need to duplicate that logic. 

Thoughts?
Tim

On 8/14/07, Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx
> wrote:
 Susan,

 It seems to me that what you are after if some kind of "oracle"
who given 
 a
 profile, a bunch of IUs selected by the user, and repos would be able
to
 tell which IU can be added to the profile.
 Unfortunately the "oracle" is not implemented. but something
could
 probably 
 be done quickly based on the code available in the director.

 Also would you want to show to the end user what will happen?

 PaScaL





              Susan M Franklin
              < susan_franklin@u
              s.ibm.com
>
 To
              Sent by:    
             Equinox development mailing
list
              equinox-dev-bounc  
      < equinox-dev@xxxxxxxxxxx>
              es@xxxxxxxxxxx
 cc


 Subject
              08/14/2007 03:46  
       Re: [equinox-dev] [prov]
              PM      
                 Ruminations
on IDirector vs. 
                    
                   ProvisioningHelper-like
entity

              Please respond to
                   Equinox
                 development
                mailing list
              < equinox-dev@ecli
                  pse.org>







 Tim,
 I have the same concerns/questions as you pose here, you are just a day
 or
 so ahead of me....I am beginning to work on the UI that follows more of
 an
 update manager workflow in Eclipse.  The admin UI in M1 forced you
to
 locate the IU you wanted and then select a profile.  The more typical
use
 case, where you are looking to install/update from your profile, is my
 next
 task.  I've had the same low level concern (but had not yet investigated
 the code thoroughly) that you have to ask the code to do something before
 you can know what will be done.  I was wondering if the fact that
you get 
 pre and post notification events was going to help me, but I don't think
 it
 will.

 So I'm hoping Pascal or someone can elaborate on this issue, as I'm about
 to face it myself and will have more to contribute to this conversation
 in
 a day or so....

 >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

 susan_______________________________________________
 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
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev